On Tue, Sep 22, 2009 at 10:24 AM, Iustin Pop <[email protected]> wrote: > On Tue, Sep 22, 2009 at 10:09:43AM +0100, Guido Trotter wrote: >> On Tue, Sep 22, 2009 at 9:41 AM, Iustin Pop <[email protected]> wrote: >> > >> > I was going to add another flag to the cluster settings, and to me it >> > seems that it's not really good to have N flags directly int the cluster >> > object. For example, we have today “modify_etc_hosts”, and I want to add >> > now “enable_bridging”, we'll also need “modify_root_ssh”, etc. >> > >> > I think we should either name them all flag_$blah (not so nice for >> > cmdline) or move them to a sub-object cluster.flags (this is not good as >> > then gnt-cluster modify is harder to work, or maybe not). >> > >> > Is it a non-issue actually? Or is it, but I should just ignore it and >> > add my flag for now? >> >> Why making the interface to them more complicated by hiding them in a >> "flags" object? >> In the end what problem is there if they stay in the main cluster one? >> They're settings for a cluster. > > Yes, true, which is why I said maybe it's a non-issue. > > It just seems to me that if we have 8-10 boolean flags it is better if > we separate those, as just from the name it's not clear what they mean. > I'm happy to leave things as they are if you think it's fine. > >> Also, for the bridge, should we have an explicit enable/disable >> bridging, or just not populate the default bridge, if --no-bridging is >> passed (same as we do for --no-lvm-...)? > > We need explicit disable, in which case we won't run the cluster verify > checks for the dependencies of bridging.
Which we could not run anyway, if there is not default bridge set (and no instance needs a bridge). Thanks, Guido
