merge data

[martin f krafft]

also sprach Matthew Williams <mgwilliams at gmail.com> [2013.10.10.1845 +0200]:
> > It shouldn't be hard to implement. First, it needs to be decided
> > whether the data should be integrated into the dict top-class (and
> > thus be overrideable by yaml_fs data), or added to the dict under
> > a subkey, e.g. __pillar__. I suggest the latter.
>
> Putting it in __pillar__ would be a bit strange for the end user using the
> data in, say, a jinja template: {{ pillar.__pillar__.foo }}. What would be
> the disadvantages of making it overridable?

Oh, I am sorry, I got confused and was thinking about grains. Those
could be made available to reclass too and then referenced from
pillar data.

But obviously: other pillars' data would just pre-populate the
reclass pillar dict.

> > Then, it needs to be walked once to identify those keys that
> > contain references.
> 
> So you could use reclass style references within the data provided
> to reclass? That would be pretty neat.

Yes. There is also https://github.com/saltstack/salt/issues/5992.

> > Also, we must decide what to do wrt. Ansible and Puppet and the
> > others, where the data are currently not made available.
> 
> Is there anything to do? The storage engine(s) could support the
> feature, but the connectors could use or not use the feature as
> appropriate.

Yes, that is true. But I would like to maintain interoperability,
i.e. be able to use reclass with Ansible and Salt at the same time,
so the data must not really make any assumptions that cannot be
fulfilled.

I appreciate your ventures in this domain, and I think the ideas are
good and should be followed up on! I have been unable to spend time
on reclass for a few weeks, and I hope that this changes soon!

Indeed, if the adapters don't get any data from the CMS, then they
should instantiate an empty dictionary and pass it into reclass.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"writing a book is like washing an elephant: there no good place to
 begin or end, and it's hard to keep track of what you've already
 covered."
                                                        -- anonymous
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.pantsfullofunix.net/pipermail/reclass/attachments/20131011/36248086/attachment.pgp>