----- Original Message ----- > From: "Daniel Pittman" <dan...@puppetlabs.com> > To: puppet-dev@googlegroups.com > Sent: Monday, May 14, 2012 5:53:29 PM > Subject: Re: [Puppet-dev] Trying to isolate performance issues with config > retrieval. > > On Mon, May 14, 2012 at 9:49 AM, Luke Kanies <l...@puppetlabs.com> > wrote: > > On May 14, 2012, at 9:46 AM, Daniel Pittman wrote: > >> On Mon, May 14, 2012 at 2:11 AM, Emile MOREL <mor...@ocre.cea.fr> > >> 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.
I've built a few things around the catalogs - diff to help with upgrades you can compare compiled catalogs with different versions of puppet to see if there's any changes due to parser behaviour etc that will bite you also just little things to dump out all files or all packages etc for a given catalog which is great to help people discover what is and isnt managed on a machine. Others have built things for vim that would warn soon as you edit a managed file etc > > > 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. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
