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. iustin
