Luke Kanies <[email protected]> writes:
> On Jun 7, 2010, at 6:16 AM, Daniel Pittman wrote:
>> [...] *nod* For what it is worth, aside the complexities that can come
>> creeping out of the woodwork, these also scare me a bit:
>>
>> concat works reasonably well, but depends no multiple fragments scattered
>> over multiple systems, and storeconfigs, which makes for two problems:
>>
>> One, we now have anything up to two hours for an update to propagate, as
>> puppet needs to run on the "source" node /and/ the "target" node. That
>> hurts a bit, although tools like mcollective promise to make it easier.
>>
>> Two, there is no one place to see the configuration structure. This makes
>> it much harder to visualize the effect of changes and the overall
>> structure.
>
> Both of these are actually solveable and fit within our plans.
>
> Because the whole system is modeled, it's not a large change for Puppet (or
> some aspect of Puppet) to be able to tell you whether a given machine
> includes configurations from another machine.
*nod* That makes quite a lot of sense; one of the things floating at the back
of my mind for a while has been that there is actually a lot of cross-over
between mcollective and puppet in what I want them to do — which, more or
less, comes right on down to exactly that bit of information.
[...]
> 1) Easy way to force updates when a required catalog has been changed.
> (This doesn't automatically fix the problem of new data showing up, only
> changed data.)
>
> 2) With good graph viewing, a straightforward way to view the whole
> architecture, with cross-host dependencies visible.
>
> This is why I'm so focused on getting export/collect to work - when you're
> sharing rich data, this kind of information is possible, but if you're just
> doing db queries, it's all invisible.
*nod* I think my conceptualization is that the "db queries" bit is an
implementation detail of the actual solution you have in mind; you could
transparently let your graph of cross-machine relationships handle that.
(OTOH, I also think that the whole "storeconfigs" thing is probably a proxy
for an mcollective "live query" type operation across the infrastructure, so
my ideas may be completely crazy :)
> [...]
>> On which topic: I can see I might be wrong about this approach, and maybe
>> these tools are better than just asking for the facts I need, when I need
>> them, from the authoritative source of that data.
>>
>> I just ... don't think so. In fifteen years of wrangling systems and
>> building
>> software it has *never* been the right answer to proxy data through a
>> secondary source if you can get it from the master source, and these other
>> tools feel very much like doing that.
>
> IMO, we're redefining primary source here - the primary source is still the
> client's configuration, we're just retrieving data from that primary source
> in a different (and more structured) way.
OK. I think I need to think about that more, but I think I can see why you
would say that. It could be I need to adjust my thinking about it all.
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
