On 11 November 2013 22:12, Joe Gordon <joe.gord...@gmail.com> wrote: > On Nov 11, 2013 9:53 AM, "Russell Bryant" <rbry...@redhat.com> wrote: >> On 11/11/2013 07:38 AM, Nikola Đipanov wrote: >> > On 11/11/13 12:55, John Garbutt wrote: >> >> I like the idea of a more general config validation phase to help >> >> people when first starting out. >> >> >> >> My worry is that it would slow down the starting back up of servers >> >> for people deploying their code using CI, where the have already >> >> verified their configuration. But maybe its so fast I don't care, but >> >> I just felt I should raise that. >> >> >> > >> > Thanks John, >> > >> > This is a valid point that makes me think that there might be some >> > upgrade implications to such an approach that we might want to consider >> > also. >> >> I like the idea of doing it during service startup. I'd like to >> actually see that it's painfully slow and must be separate before >> assuming that's the answer. I really can't image it taking that long. >> It's not a complex algorithm. It's some sanity checks on combinations >> of config values.
+1 this is what I meant really. > > ++ to doing it in service startup. Taking a step back I can see a user > making two types of mistakes: > > * Set duplicate or nonexistent options. > * set an invalid mix of settings. > > The first category should be a generic standalone tool, in fact there is a > proof of concept in nova/tools > The second category, the type being discussed here, should be done at > service startup. I think Joe has it here, there are two categories: * the quick stuff, that we might be able to encode in the flag definition * the slow stuff, that we will want as a standalone thing, maybe something like "nova-manage config-check" By slow stuff I mean things like ping glance, check its version, ping vCenter, etc. John _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev