Generic way to save data to the pillar sources

[Mircea Ulinic]

In the very first place, this might not be the happiest approach, waiting for corrections.

Let's suppose you have a triggered configuration change (as a reaction to an event). Requirements: the system to be configured as the triggered job dictates and the pillar to be updated.

I would firstly update the pillar data, then execute the state that manages the configuration.

But the pillar data can originate from various places, either external pillars, either even from the localfs where you may have multiple roots so you can't know for sure where to save the contents.

I suspect my approach would imply a "save" function for the pillar modules, as a reverse of the "ext_pillar", e.g. the `ext_pillar` function from https://github.com/saltstack/salt/blob/develop/salt/pillar/consul_pillar.py#L156 retrieves data from Consul, while another function "save_ext" would save the data back to Consul when invoked, However, the multiple pillar_roots problem still stands.

I am sure I'm not the first one having this need, I'd love to hear how people approached this use case.

Is there any generic way, or depends very much on the environment?

Thanks,

-Mircea

[Seth House]

Writing to ext_pillar sources is always a custom workflow currently.

Your proposal looks very reasonable to me and has a read/write analog in both sdb modules and returner modules. Since each ext_pillar module needs configuration params to read, it would be a fine place to also store write params too. You could expose that functionality via the existing 'pillar' Runner module. The function could take the name of the ext_pillar module and accept **kwargs that would be passed through to the `save_ext` function which would know how to interpret them. E.g.:

salt-run pillar.write consul conf=my_consul_config dc=prod data='{foo: Foo!}'

Runners support eauth and arg matching nowadays so you could allow only certain users to write, or only certain users to write to certain data. The loader currently only looks for the `ext_pillar` function so it would need to be modified to support this new function, or perhaps a new loader type added?

I'd suggest opening an issue in the Salt repo to start a discussion with the core team. Please tag me there too.

[Mircea Ulinic]

Thanks Seth.

I submitted https://github.com/saltstack/salt/issues/43135, which is basically an RFC, so I will be welcoming anyone’s ideas.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/9c640050-9e51-42fd-abe1-164f1abf555b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.