-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
salt-cloud: allow map nodes to override provider #47648
Conversation
If you have a second to look at this too, that would be greatly appreciated Thanks, |
@gtmanfred I'm pretty sure that bug is caused by https://github.com/bloomberg/salt/blob/4b8707054a8986899bc4530c843ad1f9e8fb8150/salt/cloud/__init__.py#L1951 not using salt.utils.dictupdate.update. I'll try to confirm/test tomorrow if I can find some spare cycles. |
That would be greatly appreciated! @wes-novack if you had a change to test matt's comment above and see if that fixes the bug for you, feedback would be greatly appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
@gtmanfred my hunch was correct, updated to deepcopy and found a bug in the process. #45125 should be fixed with this PR now as well (with tests). |
I will say though.. im not super familiar with salt-cloud. I'm unsure if there are any unintended consequences in just recursve-merging from provider->profile->map, but it works as described in #45125 now. |
That is what we want, we want the map to override the pillar, to override the provider. |
due to the way salt-cloud was previously pulling provider from only the profile, it made it impossible to use map node overrides to override a provider. This patch makes that possible. The main usecase for this is having profiles that model your node type (db, webapp, etc), without having to duplicate across providers. Your map can then specify provider specific overrides whilst keeping profiles unique and DRY: webapp: - node1: provider: ny:openstack - node2: provider: nj:openstack - node3: provider: toronto:openstack etc.
shallow copy was blasting things like minion_master in provider when grains were provided in map and profile. additionally noticed a bug while adding tests that map_data() is destructive on self.rendered_map; we now deepcopy before map_data does its thing.
What does this PR do?
due to the way salt-cloud was previously pulling provider from only the profile,
it made it impossible to use map node overrides to override a provider. This
patch makes that possible.
The main usecase for this is having profiles that model your node type (db,
webapp, etc), without having to duplicate across providers. Your map can then
specify provider specific overrides whilst keeping profiles unique and DRY:
etc.
What issues does this PR fix or reference?
fixes #45125
although not a direct solution, this could be used to solve the problems described in #40897 in a different way.
Previous Behavior
provider in map files were ignored
New Behavior
provider override in map file works as expected
Tests written?
Yes
Commits signed with GPG?
No
Please review Salt's Contributing Guide for best practices.
See GitHub's page on GPG signing for more information about signing commits with GPG.