cobbler-devel-bounces@lists.fedorahosted.org wrote on 05/28/2009 03:14:42 PM:

> Jeff Schroeder wrote:
> > On Thu, May 28, 2009 at 10:08 AM, Scott Henson <shenson@redhat.com> wrote:
> >  
> >> This morning I had a quick idea that I thought I might throw out and see
> >> if anyone else could use it.  Basically the idea is having cobbler
> >> provision storage for hosts based upon management classes or some other
> >> configuration management construct.  Cobbler would need to be taught
> >> about accessing SAN and NAS devices to construct volumes and SAN luns,
> >> and then have those volumes mounted and/or formatted during the
> >> provisioning process of the host.  Anyone think it is a good idea or
> >> have any comments on it?
> >>    
> >
> > Sounds like something you should wrap around cobbler and not put
> > inside it. At Ticketmaster, we used a tool for this aptly named
> > provision[1]. For virtual machines, libvirtd should do the storage
> > stuff for you. Perhaps someone should rewrite provision in python or
> > just add in hooks to use non-netapp (generic linux) storage. It also
> > seems like the kind of thing Satellite or the open source project it
> > sits ontop of should implement. What do you think?
> >
> > [1] http://code.ticketmaster.com/index.php?page=provision-overview
> >
> >  
>
> To me, Scott's idea is interesting and gets us out of a rut (that being,
> where does Cobbler go from here).  I'm interested more in finding out
> who /does/ like it, since silence on a list implies the No.   We're
> likely to try this out  and then see who uses it.   Namely I'm
> interested in ideas on where we can take similar ideas.
>
> If we limited ourselves to the conventional view of how things are
> managed today, we are very unlikely to /change/ the way things are managed.
> If we stopped at just kickstart, we wouldn't be where we are today.  
> Our goal is simply -- how much can we automate within a very simple
> framework.  
> Messaging wise, Cobbler is a bunch of glue that makes setting up new
> systems easier.     Usage of lots of parts of it are optional, and not
> required to be understood
> for newcomers, or used in all setups... so I think it's fine (and highly
> beneficial) to experiment and see where we can take things.
>
> As for what should sit where, I can't agree with you.  
>
> Libvirt doing storage is done at the wrong level, because we also care
> about providing storage to hosts.    It's also persuing networking
> configuration, which in many ways is not correct either, as we also care
> about networking for hosts.   Further, while cobbler is consumed by
> Satellite, we do not limit what deployment/setup/systems-management
> tasks we can do.   We want to do things at a level which are abstracted
> for both physical and virtual machines.
>
> So, what about Satellite?   Satellite is a great app... but one easy
> reason there -- it's much harder to implement things in
> Spacewalk/Satellite, it's not a good codebase for rapid prototyping (not
> the fault of folks that work on it, it just does a LOT).    Since we are
> already doing things like DHCP, DNS, power, puppet-integration, and so
> forth (resources needed for the machine before it exists) and moving
> towards Network objects, modelling storage setup also seems useful to
> me.    Things we do for Cobbler /do/ make it into Satellite, as we
> expose those in the Satellite GUIs and so forth, and make them
> supportable.  
>
> So this "do one thing" thing...
>
> Ultimately our goal is to automate what we can automate, and gather
> information from people wherever we can find it.   In this sense,
> Cobbler is a snowball for any sort of automating
> annoying repeated tasks that  you need to do to get systems up and
> running, and makes it especially nice when folks are starting from
> scratch and needing OSS tools to do this.
> We want to prevent building custom automation infrastructure by
> providing a community where we can all share in that development.
>
> If Cobbler's definition expands over time, I see that as progress.
>
> I don't think we want another competing management tool (and adding a
> subproject adds overhead) when you can use Cobbler without using all of
> it's features.  For instance, DHCP/DNS management today are totally
> optional.  I do think possibly incorporating some of those ideas from
> your TicketMaster app could be excellent though, and I definitely
> welcome all of that.   We do want to absorb all of the good (Free) ideas
> wherever they lie and accumulate all that knowledge together.
>
> --Michael
>
>
>
>
>
>
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel

+1 from here for Scott's idea. I happen to be knee-deep in cobblering 64 HP blades with Emulex FC mezzanine cards connecting multiple volumes triple-multipath to an IBM XIV :-)