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. |
|
@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.
3 participants
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.