On Mon, May 14, 2012 at 10:21 AM, Luke Kanies <[email protected]> wrote: > On May 14, 2012, at 9:53 AM, Daniel Pittman wrote: >> On Mon, May 14, 2012 at 9:49 AM, Luke Kanies <[email protected]> wrote: >>> On May 14, 2012, at 9:46 AM, Daniel Pittman wrote: >>>> On Mon, May 14, 2012 at 2:11 AM, Emile MOREL <[email protected]> wrote: >>>>> Daniel Pittman a écrit : >>>>> >>>>>> It would be great to improve that, from our point of view, but I >>>>>> wonder a bit: when is this a killer problem for everyone? >>>>>> >>>>>> Also, someone commented about using marshall to speed this up - sadly, >>>>>> that isn't an acceptable solution. We have had problems with Marshall >>>>>> data being impossible to transport between Ruby versions, and worse, >>>>>> causing segfaults. That means we can't use it to persist data where >>>>>> it might be read by a different version Ruby later. >>>>> >>>>> Caching catalog may not be used as a cache. We are using puppet only in >>>>> interactive mode and we use the cache to extract some data (like a kind of >>>>> report). >>>> >>>> That is an interesting use-case, and not one I had expected - I am >>>> surprised someone is using the "cached" catalog as an API like that. >>>> What report style data do you extract? >>> >>> This is actually really common - we've actually built reports like this for >>> customers, even. >>> It's the only "database" available when storeconfigs is too slow to use in >>> production. >> >> Hah. I must have missed that. Obviously, I do need to better >> understand that particular use. > > Are you making changes to this area right now? Not that I have a complete > picture, but I'm happy to do a brain-dump on this. Basically, think local > access to a single-node PuppetDB instance.
No, our immediate roadmap doesn't touch on improving the space. With Telly on the verge of going out the door, though, we are going to be refocusing on what that list *should* be. >>> I'd like to see the 'catalog' face extended to provide the operations >>> people want, so they're a bit more isolated from the storage format. >> >> That would allow greater abstraction here - regardless of our internal >> format, that could perform transformations into whatever consumption >> format people want. > > Yep. I've been wanting a 'puppet catalog select' action to do all kinds of > subgraph selection and presentation, with optional piping that to 'puppet > apply', for instance. *nod* That sounds like an awesome demonstration that we have delivered useful access to that catalog data. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ 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.
