On 08/28/2009 02:45 PM, Jeff Schroeder wrote:
On Fri, Aug 28, 2009 at 11:41 AM, Michael DeHaan<mdehaan@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