On Tue, Sep 22, 2009 at 10:25 AM, Guido Trotter <[email protected]> wrote: > 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).
== all the nics are in "routed" mode... Isn't this safer? Thanks, Guido
