Gavin Romig-Koch wrote:
Michael DeHaan wrote:
I'm not sure we should add this. Discussion is welcome.
Thanks for the chance to discuss this. In re-reading this before
sending it, I realize that it is longer and "preachy-er" than I had
hoped. Please forgive my weak writing skills.
Within Red Hat Support we have a need for a single tool that can do
kickstart based installs, of either actual hardware or virtual
machines. For each issue that comes in (that isn't solvable by just
looking at the case), we need to do some sort of local reproduction of
the issue, if that's possible. This happens several times a week, if
not more, for each engineer working cases within support. As you
know, we support three major releases, multiple sub-configurations
within that, and our customers are often reluctant and sometimes
unable to upgrade to the latest update within a release without
assurances from us that it will solve their problem. All this is my
way of emphasizing that we can't reduce our set of possible installs
to a countable, nameable, predefined set of profiles. Each case is a
new profile, and often we must tweak that profile several times to
find out exactly what combination is needed to reproduce the problem.
While reproducablity is important, it is almost never necessary to
reproduce the customers exact hardware or virtual machine
parameters. On the other hand, it is almost always necessary to
reproduce (at least part of) the software enviroment they have.
It would be possible to use a Cobbler server in this environment.
Each engineer could manage his own Cobbler server, or we could create
a central Cobbler server, and build some tools that allowed engineers
to check in new profiles/systems, delete profile/systems, and
implement some nameing convention for profiles. But this would just
be extra work to make our environment fit the model of the typical
data center environment.
This doesn't seem to be hard to establish to me, there's work sure, but
it may lead to time savings in the end as Cobbler has ways of inheriting
profiles from one another and doing some other interesting things.
There's also a pretty powerful templating system for building kickstarts
based on, well, templates. Plus, since you're local, I'd be glad to
offer assistance :)
It would also be possible to use koan hardware re-installs, and
virt-install for virt installs, but it seemed useful to me to have a
single tool (with a single set of options) that did what I see as a
single function - a kickstart based install.
With Cobbler, the idea is that there are things you are going to need
for a baremetal install server -- hosting of the content, TFTP (in some
cases), DHCP (in some cases), etc. It takes care of all of these,
while also offering centralized management. Given you probably only
want to host trees once (and Cobbler can import from NFS very easily),
this seems to be a good fit still. Depending on your scenario, you may
want to grant accounts to the WebUI, or more likely just grant su access
to cobbler for users that need to add entries. It depends on your
configuration and I'd like to hear more about it, but it's not different
from how Cobbler would be used in development setups (which is one of
the things it's useful for...).
We could also build such a tool. We have a tool that does largely the
same thing as koan --no-cobbler --replace-self does, but does not do
--virt installs.
If you're worried about koan --replace-self and virt-install mismatch,
the tool you're talking about is a small shell script :)
I was looking at how to extend it to also do virt installs, when I
discovered Koan. At the time I knew that Koan was really just an
extension of Cobbler, but I was hopeing that Koan was willing to grow
into a more general kickstart-over-a-network tool, able to use
Cobbler, but not entirely dependent on it.
Koan is basically the client piece that allows Cobbler to do things
Cobbler can't do strictly from a network perspective.
I understand any reluctance, or objection, to growing the purpose of
Koan -- do one thing, do it well -- is a good maxim for programs and
libraries and maybe even people, but I believe Koan can grow outside
of it's current roll of Cobbler-helper, and still be following this
maxim.
It could, but I'm not sure where this leaves virt-install... which does
basically the same thing. Virt-install seems to handle this niche,
and if you outgrow virt-install, you pick up Cobbler...
While RH's support's needs are perhaps unique in the volume of
re-installs we do, I don't believe we are unique in our need for a
single tool to do kickstart based installs of either virtual or actual
hardware. Does Koan want to be that tool, to stay within it's
current role?
Koan does, but it wants Cobbler to go with it, and I believe with
Cobbler the advantages are worth it if you want a deployment server,
rather than building it yourself. If there's something you need in
Cobbler, we can definitely work to improve that just as easily as we can
make koan work without Cobbler.
-gavin....
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
