Would this also allow for doing crazy arbitrary things such as storing
most of the data in a custom rdbms / ldap if the user chose? It seems
like a change this drastic with a few example scripts would warrant a
3.0.

  

Possibly.   It would require that the required data lived in cobbler... so for a distro, it's name and kernel/initrd need to be there to make an object.  (Now, I'm not sure whether the blender_filter would be allowed to override those... it might, TBD).   The number of required fields are pretty minimal.   It wouldn't allow for making new objects.   The blended/overridden new fields wouldn't in any way show up in the web app or the cobbler CLI either.   It would mostly affect how cobbler acted when generating kickstart files, when generating TFTP trees, and when instructing koan.   But could it mean that you could store virt ram info (or something else arbitrary) in LDAP?  Or ksmeta items in LDAP?   Or write a filter that if you specify an even number in cobbler it always gets rendered out odd (ok, I'm kidding here).  Yes, absolutely.   All that should be possible.

Note -- I'm not sure how far you were thinking of taking this, so I'll be explicit -- There's a whole other line of theory to whether we could inject objects not even represented in cobbler -- which is /possible/, but this becomes complicated because then we have to tell cobbler that some objects cannot be saved, etc... and we go down some interesting (and by interesting I mean crazy complicated) paths to make that clear to the user.    I'd rather not go down that second line of inquiry.  

(Thinking aloud again) I should also add that the performance implications of any of these approaches is still unforseen.   I would suspect in extreme usage cases, it would be best if the blender filter was written in C, as you would be otherwise running a /ton/ of operations if it were in Python.  But wait!   Why couldn't this be a cobbler module and you could pick it in cobbler/modules.conf.   Actually, yeah you could.  Scratch that.    We could ship a module that implements external nodes via shelling out, and also one that is effectively a no-op which could be on by default, and if someone wanted to do a more high-performance one they could.

BTW, did you mean "drastic" or perhaps something closer to "perhaps really useful to me" ?   It should be very easy to insert -- 5-15 lines of change in cobbler, maybe.   I don't think it would be a drastic change at all.  Something that I think we'd just insert into 2.0.X, even, as if off by default, it couldn't really do any damage, so no reason I can see to hold it up.   Numbers are just numbers, and in some sense, 2.0 represents 2.0 just because it has some major code cleanups, and is more different than most of the previous releases.  This feature would be more akin to the same car, now with a factory option of having leather seats.

--Michael