On 08/28/2009 02:45 PM, Jeff Schroeder wrote:
On Fri, Aug 28, 2009 at 11:41 AM, Michael
DeHaan<mdehaan(a)redhat.com> wrote:
> 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.
>
My use case is fairly straightforeward. We have internal tools that
are going to be authoritative for a large set of internal data. One of
those datasets happens to be cobbler. So I can query this tool (django
and cli tools that read the django db) and get the exact command to
re-create system
x1.ourdomain.com as it was 1 day ago, or 3 weeks ago.
It gets the data from cobbler currently over xmlrpc.
If you need to create systems and such, I think you'd probably still go
down the current road Cobbler XMLRPC.
(For the benefit of others -- Cobbler doesn't actually use Django for a
database, Jeff is talking about his stuff. We hold all our information
in cobblerd, which is a level below Django if you're using cobbler-web,
which is also optional)
--Michael