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 cobbler@lists.fedorahosted.org 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