On Mon, Apr 5, 2010 at 9:08 AM, Scott Henson
<shenson@redhat.com> wrote:
Excerpts from Thomas S Hatch's message of Fri Apr 02 17:27:36 -0400 2010:
> I just updated a test system running fedora 11 from cobbler 1.6.6 to cobbler
> 2.0.3.1 and came across something rather unsettling, I hope it can
> be repaired by updating my understanding of cobbler.
>
> One of my distro configurations points to a kernel image which is now
> unavailable, I can replace the kernel image, but what unsettles me is that
> cobbler won't start, and if I wanted to alter the configuration I would need
> to communicate with a running cobbler server.
This isn't new with cobbler 2.0. The new part of cobbler 2.0 though
is that the cli now goes through cobblerd, which probably makes this
harder to fix than it once was.
> I while I am going to agree that a mis-configured server should not start,
> my problem is that cobbler is configured through access to the running
> server. Now I need to repair the paths manually or remove all of the json
> files which referenced my distro while crossing my fingers that I don't
> disturb the cobbler internals somehow.
>
> I am going to recommend that the behavior be such that
> a mis-configured element would raise a warning or log message rather than
> preventing the service from being reconfigured. From a design perspective,
> since the decision has been made to ensure a working configuration through
> the api, then the api should not prevent repairing a configuration. This
> is especially true because of the disparate external circumstances in which
> the configuration can be compromised.
We have wanted to do this for quite some time, but we haven't been
able to agree on the proper action to take. Should the bad object be
marked as bad and then all downstream objects simply not show up until
it is fixed? Or should we throw an error and refuse to do any
kickstarting till everything is fixed. One could make the argument
that cobbler should just let things go along even if it knows that an
error will be generated later on in the process. I'm not sure what
the right behavior is here. Does anyone else have ideas on what the
right behavior is? I'm a fan of marking the object bad and not
showing any downstream stuff.
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME
_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
I will heartily agree that this is an in depth problem. For what it is worth, I would think that the system should start, that error messages should be logged, and that kickstarts should not be made available on broken systems.
This would allow for easy debugging of what could be a complicated issue and avoid the problem of installs failing halfway.
My other suggestion would be that the service not start but that an external facility to edit the configuration would exist.
I would also request that distros/profiles/systems could be temporarily disabled by the admin, this should simplify if an old package tree is removed, or if company policy changes to stop deploying a system of a certain type but the configuration should be preserved. Disabling would also allow mis-configured components to be safely placed on the back burner until ample time to repair the problem without disabling cobbler altogether.
Perhaps someday I can break from my hectic schedule to throw some code your way, although I think it may never happen :)