-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try with the latest version of Puppet or the latest interface code?
That trace was with the latest interface code unless you haven't pushed past b43555a. I tried moving my catalog out of the way and still have >3s runtimes. CentOS 5 system with stock Ruby (upgraded from their repos). Trevor On 02/23/2011 02:05 PM, Luke Kanies wrote: > On Feb 23, 2011, at 7:08 AM, Trevor Vaughan wrote: > > Dan's follow up e-mail made the programmatic interface usage a bit clearer. > > The rest inline.... > > On 02/22/2011 08:22 PM, Luke Kanies wrote: >>>> On Feb 22, 2011, at 1:44 PM, Trevor Vaughan wrote: >>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> > <snip/> >>>>> 2) puppet catalog - doesn't seem to do anything gives the message "Could >>>>> not prepare for execution: Action select already defined for >>>>> Puppet::Interface::Catalog" >>>> >>>> >>>> Hmm. I definitely don't get this behavior. I either get a failure >>>> describing what I should be doing (if I've passed no args) or I get the >>>> expected results. Can you send a stack trace. > > - Attached. The same result happened via irb. > >> Can you try it again with the current code? I did a bunch of refactoring it >> yesterday, and I think I quashed a lot of these. > >>>>> 3) Overall, this interface is too slow. I'm thinking this is due to >>>>> having it run the entire puppet codebase startup before delving into >>>>> things. >>>>> Perhaps this can't be avoided. >>>> >>>> What target should we be shooting for? I was expecting that as long as >>>> simple things ran in ~ 1s it'd be fine, which is about what I'm seeing. > > I think that ~1s would be OK. Here's what I'm getting: > > $ time ./puppet --version > 2.6.5 > > real 0m3.369s > user 0m0.881s > sys 0m0.839s > > It's on a "small" system with only 1G RAM and a 2.3GHz processor, but still, > 3 seconds just for the version is a bit much. This seems to be consistent > with anything that doesn't load facts. Those, of course, take longer. This > may be directly related to the size of my catalog, of course. > >> Urgh: > >> luke@syringe $ time puppet --version >> 2.6.5 > >> real 0m0.849s >> user 0m0.389s >> sys 0m0.259s >> luke@syringe $ time puppet facts find localhost > /dev/null > >> real 0m1.292s >> user 0m0.598s >> sys 0m0.514s >> luke@syringe $ > >>>>> One of the things that I would like to see is a fast way of digging into >>>>> the catalog and running system configuration. I'm thinking that fact >>>>> parsing >>>>> could be avoided for many of these calls and this may provide the >>>>> reaction time that I'm looking for. >>>> >>>> What kinds of digging do you want to do? > > - Well, one thing is to be able to see what services are running on the > system that are not defined in my catalog. I know you've been working on some > audit functionality, and this is information that almost all of the major > system security guides seem to want to know. > >>>> >>>>> I think that the tool does have potential but, for now, the wait time to >>>>> get information out of it is just too high compared with hacking something >>>>> together that can run multiple commands in the same instance and >>>>> manipulate the results. >>>> >>>> One of the specific goals of this is to make it easy to hack something >>>> together in an instance. Note that we're not just providing CLI >>>> applications, we're also providing ruby Interfaces that provide their >>>> back-end. >>>> >>>> E.g., the goal is to be able to replace the current Agent class with >>>> something that looks more like this: >>>> >>>> # Set our constant search path >>>> class Puppet::Interface >>>> Agent.action :run do >>>> Plugin.download >>>> Facts.upload >>>> catalog = Catalog.download >>>> report = Catalog.apply(catalog) >>>> Report.upload(report) >>>> end >>>> end >>>> >>>> This kind of thing is already possible, it's just not that not all of the >>>> methods exist, nor does this actually fully capture the complexity of the >>>> current Agent's behavior (for better or worse). >>>> >>>> In other words, even if your goals are to hack something up in a single >>>> process, this should make that much, much easier. > > - I'm seeing this now and definitely understand the potential. > >>>> > <puppet_catalog.trace><puppet_catalog.trace.sig><tvaughan.vcf> - -- Trevor Vaughan Vice President, Onyx Point, Inc. email: [email protected] phone: 410-541-ONYX (6699) pgp: 0x6C701E94 - -- This account not approved for unencrypted sensitive information -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNZV22AAoJECNCGV1OLcypjjcH/AtF6VcoZzlbCi41jHLjoAI2 VZk2Ct1KCfcARjCTZ2m8vvMdol6AqVsw4RN59B9xCUqJ6ZW67ugEQ7BsoI0Y8ob/ Qj8j3R68oONtt+gWykb/vMgSzXiiRDY5/rhuQreaw8IFQadhrEVxKEUq7LBs0oKx DLF8J/nN5mdnkc3w/de+K43z4rX+qipwQ0aoPpCoSNThO8Hmt6V0Ftij6Kz/cjcs F8rOTkohcX8igBpe2n09LtRlP8Hg3t28xy6WrhombCGDgfGqqVa7O5ikeUr9By43 rG4M/r86LcVf+0vuMARaJ0BFugfe5NoYL+wGnJfs/kEWpKdshQbOJSTg3rxvUII= =snUg -----END PGP SIGNATURE----- -- 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.
<<attachment: tvaughan.vcf>>
