cobbler-devel-bounces@lists.fedorahosted.org wrote
on 05/28/2009 04:08:22 PM:
> Owen.Mann@interactivedata.com wrote:
> >
> > 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 :-)
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > cobbler-devel mailing list
> > cobbler-devel@lists.fedorahosted.org
> > https://fedorahosted.org/mailman/listinfo/cobbler-devel
> >
>
> You may be a perfect one to ask about this then.
>
> Assuming we added options to cobbler system objects to make this easier
> (and possibly profiles), what would you envision this looking like?
>
> (Perhaps we could add cobbler "noun" objects to model the
devices
> themselves like we're going to do for networks, I don't know if that
> would be required -- it could end up being somewhat simpler like how
we
> handle power)
>
>
> _______________________________________________
> cobbler-devel mailing list
> cobbler-devel@lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler-devel
Hmm, I'm not the "storage guy",
but from what I gather, provisioning the volumes requires the two main
steps of 1) allocating the space on the SAN, and 2) setting up the SAN
switch ports (similar to setting a VLAN). The main pieces of info needed
seem to be the card's WWN (similar to a MAC) and the volume size. I understand
that different brands need varying other info, such as RAID groups, etc.
On the surface, the actual provisioning
could be done similar to cman's "fence_xxx" stuff, but would
need some way of keeping track of the volume after it's been created.
One hurdle I've come across is that
it seems that the only practical way to acquire the WWN's is from the running
kernel, so it would seem that the provisioning would have to be done in
the %pre section once the WWN's are known. Thus, to keep track of the volume
in the cobbler system object, the volume ID (and perhaps also the WWN)
would need to get from the %pre section into a cobbler system variable
somehow.
I'm obviously far from an expert on
this, and have a modest programming background (though I did kludge in
a "PXE this machine" for HP blades-button into the power control
menu - anyone interested?), so anyone please feel free to add to or correct
anything I've said. I'll do my best to try or figure out any ideas towards
this.
Owen Mann, Interactive Data Real Time
Services