Hi, Sorry for the late answer, tough day at work today (with some new regressions in every corners, arghhh).
On 30/09/08 18:39, Luke Kanies wrote: > On Sep 29, 2008, at 4:26 PM, Brice Figureau wrote: >>>> And then, I'll have to find something else to work on :-) >>>> If there are some things on which I can help, let me know. >>> >>> There are *tons* of things you could help with, at this point. >>> >>> You want more language work, RAL, or what? >> I'm quite open, but I don't have tons of spare time (a few hours per >> week-end: my day to day job is taking most of my development time). >> I can do some small things like I already did. Note that there are >> large >> parts of puppet internals I still don't even know about :-) >> Since I know the parser quite well now, I can continue working on the >> language part if that's related. From the various debugging I already >> did, I know a little bit of the resources, compilation and >> storeconfigs. >> And I know service providers too. > > There are 26 open tickets for the language; my guess is you could > solve quite a few of them pretty quickly, with your newfound parser > experience. I'll have a look to those. If I find something I think I can fix, I'll try. > Quite a few of them require design decisions -- such as a relationship > syntax, class dependencies, and class 'confine's -- but many of them > are relatively simple bugs. > > In addition, the language could really use a clean-up refactor and a > performance refactor. > > I've never revisited the design, and I think it could stand some > redoing. For instance, the 'each' methods are never actually used (as > you could tell, since you didn't bother to write tests for the methods > you created), and I expect there's a much better design available for > how the AST is built up and evaluated. Somewhat obviously, this was > one of the first designs to coalesce, and I've never had time to > revisit it. How do you see it? I plead guilty about the each method. Honestly I didn't bother to test it because I didn't even understood what it was doing :-) If you want a patch to get rid of them, let me know. If you want a patch to use them, you'll have to explain me what's their intended use. > I've also never done performance analysis on the parser, and my > understanding is that for complex parsing jobs, things get a bit > expensive. If you slapped this under profiling or (even better) > DTrace, I expect just a few hours would yield really good results > quickly. Profiling is something I'm usually good for. My testings back when I was looking for the performance issues with storeconfigs show that parsing and compiling where the second performance hit (on the puppetmaster) after storeconfigs, with (on my servers) compilation time of about 2 to 4s for an 800 resources node. I'm pretty sure there are room for improvements here. I'll run a few profiling sessions to see if I can find some hotspots. I have no knowledge of DTrace, though, and I don't have access to a solaris machine, but I vaguely remember that macosx was running a version (or did I dream it). Anyway, I can setup a virtual machine, if needed. > If we step outside of the language, I'd say the next biggest > priorities are testing and the REST/Indirector work for 0.25. > > There are quite a few tickets pointing to failing tests, and those all > need to be fixed, most likely by rewriting the tests in rspec. We > also want to get rid of all of the existing tests in test/, and doing > so is likely to require a decent bit of refactoring in some places > because a lot of the original code isn't written to be all that > testable. I'm ok to contribute tests (even though that's not my cup of tea yet), but I fear I don't really have enough puppet internal knowledge to perform the said refactorings without breaking more things :-) I ordered a couple of TDD books just to be in the mood :-P > There are also quite a few tickets opened with a High priority for > 0.25, pointing to the classes that still need to be converted. There > are yet other classes that don't use any xmlrpc but should use the > indirector/REST, like StoreConfigs -- I'd like to create a Resource > class that can speak to ActiveRecord but also support other back-ends, > for instance. This would make the language's query syntax much more > flexible, because you could connect it to any arbitrary resource store. I'm waiting eagerly for this part ;-) That'll open many new perspectives for storeconfigs. Someone mentionned a CouchDB implementation on this list. That's really interesting stuff. I still don't see how you'll decouple the resources from the implementation, but I'm pretty sure you have an idea. > Obviously most of this isn't quite enough to actually get you started, > but if any of them stand out as something you want to work on, then we > can work out the details of how to actually do it. > > Sound good? Yes I have plenty to look at. I think I'll start by looking to the language tickets, see if I can fix a few easily, then move to the language profiling things. Meanwhile, I'll try to contribute tests for parts I already know (providers, more parser tests...), if that's OK with you. Many thanks, -- Brice Figureau Days of Wonder http://www.daysofwonder.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
