allow overrides of objects #232

Closed
opened 2021-11-20 15:22:05 +00:00 by ungleich-gitea · 6 comments

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* 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
Author
Owner

Created by: dheule

This issue is fixed, so I close it.

Thx to Nico and Steven for the teamwork ;-)

*Created by: dheule* This issue is fixed, so I close it. Thx to Nico and Steven for the teamwork ;-)
Author
Owner

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

dheule wrote on 01/26/2014 08:31 PM:

Hello,

Hi Daniel

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.

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.


Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/274#issuecomment-33350692
.

*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 > dheule wrote on 01/26/2014 08:31 PM: > > > Hello, > > Hi Daniel > > > 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. > > 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. > > — > Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/274#issuecomment-33350692 > .
Author
Owner

Created by: asteven

dheule wrote on 01/26/2014 08:31 PM:

Hello,

Hi Daniel

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.

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: asteven* dheule wrote on 01/26/2014 08:31 PM: > Hello, Hi Daniel > 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. 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.
Author
Owner

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: 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.
Author
Owner

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:

cluster-node-*)
  __my_magic_doit_all_type_which_uses_a_nested_armada_of_types
;;

These days, my manifests look more like this:

cluster-node-*)
      __cbrg_install_default --root 10G --swap 2G
      __network_interface eth0
      __cbrg_common
      export require="__cbrg_common"
      __cbrg_compute_node
      __cbrg_users
      __cbrg_admins
      __cbrg_cronjobs
      __cbrg_smtp_local
;;

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: 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: ``` cluster-node-*) __my_magic_doit_all_type_which_uses_a_nested_armada_of_types ;; ``` These days, my manifests look more like this: ``` cluster-node-*) __cbrg_install_default --root 10G --swap 2G __network_interface eth0 __cbrg_common export require="__cbrg_common" __cbrg_compute_node __cbrg_users __cbrg_admins __cbrg_cronjobs __cbrg_smtp_local ;; ``` 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.
Author
Owner

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]:

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


Reply to this email directly or view it on GitHub:
https://github.com/telmich/cdist/issues/274

PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0

*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]: > 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 > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/telmich/cdist/issues/274 ## PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#232
No description provided.