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.