allow overrides of objects #232
Labels
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ungleich-public/cdist#232
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Created by: dheule
Hello,
we have the following case:
we set user parameters (password hash) for root on all systems,
but in later included manifests, if a special application is installed (in rare cases..),
we need to set the password to an ohter hash (meens owerwriting a allready definded object.)
Example Error:
ERROR: cdist: Object __user/root already exists with conflicting parameters:
/tmp/tmperpuee/conf/manifest/init: {'password': 'hashplaceholder1', 'state': 'present'}
/tmp/tmperpuee/conf/manifest/init: {'password': 'hashplaceholder2', 'state': 'present'}
What about a env variable for example "overwrite=true" on object creation which switches the behaivor to allow a redef of an object ?
@telmich if the idea is ok for you, i will try to implemnt it and submit a merge request ... but i ask first bevor i do the work ;-)
Greats Daniel
Created by: dheule
This issue is fixed, so I close it.
Thx to Nico and Steven for the teamwork ;-)
Created by: dheule
Hello Steven,
Sorry for my takeout ,,,
I like to work with you and nico,
since its a cool tool cdist and
a good spirit in the project.
I have done some testing and
have made the patch ready that
you can look over it.
I have searched long time
for a good opensource project
where my contributions are
welcome and with cdist i have found it.
I hope i can help with some
minor fixes and so ..
Cheers,
Daniel
2014-01-27 Steven Armstrong notifications@github.com
Created by: asteven
dheule wrote on 01/26/2014 08:31 PM:
Hi Daniel
You are right. The user should be in charge.
And I was wrong to make any assumptions of how you organize your types.
The reason I'm reluctant to this feature is that I fear it makes sharing
types more complicated. But then in reality, this does not happen that
much anyhow. Pity actually, what makes cdist fly is them types ...
As you say it's a minimal change, so could you please share your patch?
If telmich is willing to accept it I will add a note in the docs that
this feature should be used sparingly and preferably only in in-house types.
Cheers,
Steven
BTW: Your contributions to cdist are highly appreciated. Sorry if my
comment came over a bit harsh.
Created by: dheule
Hello,
i don't have a __my_magic_doit_all_type_which_uses_a_nested_armada_of_types ;-)...
all my types do only 1 thing.
and i have exactly the same usecase as you, 99% of all cases use the __user type with one parameter,
1% some others, but called later in the manifest tree.
For me it's ok if this feature isn't popular ;-),
since i have it allready in production, it's only a single line hack in emulator.py.
If sometime in the feature this is requested,
you can write to me. I close this issue now and leave it unfixed in upstream ...
In my opinion, the user (admin) should have the choice to select whats ok,
not the tool which say how to work.
Created by: asteven
You have no control over the order in which the objects are created. If you introduce a setting like CDIST_ALLOW_OVERWRITE or whatever, what does this mean? Who is allowed to overwrite who? And when, and what about requirements and auto-requirements and ...
In all the years I've used/wrote cdist I sometimes also thought I need this feature. But you don't.
If you bump into this, chances are that your types are to deeply nested. Which for me turned out to be a unflexible pain in the arse anyway.
I used to have manifests like:
These days, my manifests look more like this:
Need a different root pw for a node, just add another host entry and use __special_case_admins instead of __cbrg_admins.
I have a pretty strong opinion against implementing this feature.
Created by: telmich
Hey Daniel,
hehe, seen this many times already, maybe the workaround should
be better (at all?) documented:
I usually make the password hash a parameter to my default type
(__company_root_password) and use default values in the parameter and
supply it to the type, if I want to change it.
I am a bit reluctant against allowing object overwriting / recreation,
as it makes cdist runs more dependent on the order and less predictable.
On the other hand, if you find good arguments against my proposal above,
I will definitely have a look at a pull request (though I suggest to
stay in line with the other changes and use CDIST_ALLOW_OVERWRITE=...)
Cheers from the train,
Nico
dheule [Thu, Jan 23, 2014 at 02:49:24AM -0800]:
PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0