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 :-)