On Mon, Apr 5, 2010 at 9:08 AM, Scott Henson <[email protected]> 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 > [email protected] > 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 :) -Tom Hatch
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
