Added pillar option to redirect profile and map folders. #117
Conversation
These aren't intended to function; they're here to allow the use of file.recurse on the provider folder, without requiring the user to provide pillar data for templates they're not using.
This obsoletes the salt:cloud:folders and salt:cloud:providers pillar entries. Provider keys have been moved to /etc/salt/pki/cloud.
|
Okay, I lied, I went and implemented all of the above. I think this makes the salt.cloud state more flexible, shorter, and cleaner; and the provider and folders options are no longer required. I'm not entirely sure if or how this would break existing configurations. |
As mentioned in issue saltstack-formulas#118, provider files may contain passwords or API keys and should be restricted. Profiles/maps are probably OK with the defaults.
|
Updated PR to account for security issue noted in #118. |
|
Could someone have a look at this? I'll understand if it won't fly, but feedback would be good. |
|
It breaks backward compatibility and doesn't document that fact at all, much less how to convert the pillar data (aside from changing pillar.example values). In general I'd like to see a lot more documentation about how this stuff works, some examples of actual use cases, etc. |
| template_sources: | ||
| providers: salt://templates/cloud.providers.d | ||
| profiles: salt://templates/cloud.profiles.d | ||
| maps: salt://templates/cloud.maps.d |
There was a problem hiding this comment.
pillar.example generally follows the default. You should prefix these or something (salt://salt/files/cloud.maps.d would match what minion.sls and master.sls already do).
There was a problem hiding this comment.
Agreed, I'll update it so these point to salt://salt/files/cloud.maps.d.
Added pillar option to redirect profile and map folders.
|
Thanks for the work. Looking forward to any further PRs you have. |
The default profile and map templates are neither terribly useful nor easy to add to without having to maintain your own fork or extension state. This patch makes the state use file.recurse for those folders (instead of assuming one file per provider) and allows the source property to be set. I don't think it can break existing salt trees.
I didn't include providers.d because the templates in there don't gracefully handle missing pillar data.
...but I'm not certain this is actually the best way to do this. I'm looking at the salt.cloud sls, and thinking that with a bit of refactoring the providers, profiles, maps, and file.directory section could all be collapsed into a single loop like the one in this commit -- and be both more flexible and require less pillar configuration afterward. That would be a breaking change, though, so I thought I'd ask if it's feasible before going to more effort.
Thoughts?