On Apr 5, 2010, at 11:08 AM, Scott Henson 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
My opinion is that if there is any problem parsing the configs, then we should not assume that the operator knows what he/she is doing. Fail to start with a descriptive error: Could not find resource X referenced in Y. I recently screwed up our configs and left a stray file laying around. Cobbler didn't know what to do with this. The 'check' command failed ungracefully since it couldn't parse the configs. -jesse _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
