Jeff Schroeder wrote:
On Thu, May 28, 2009 at 10:08 AM, Scott Henson
<shenson(a)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