On Tue, Sep 22, 2009 at 10:31 AM, Iustin Pop <[email protected]> wrote: > On Tue, Sep 22, 2009 at 10:26:10AM +0100, Guido Trotter wrote: >> 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? > > We're back at square one, circa May 2009 :) >
Wow! Like playing stairs and snakes! :) > I still argue that explicit (yes, I need bridging) is better than > implicit. Otherwise, right after a cluster creation, with no instances, > your proposal would make the cluster verify say everything's OK Not if a default bridge is set up > whereas > it's not. And I like more if gnt-instance add rejects my misguided > attempts to create a bridged network when the cluster config doesn't > allow it. > But why not allowing it? We already support more than one bridge, so if there is no default, and no instance has a bridge, no need to check, if there is no defualt and some instance has some bridge, need to check all bridges specified by instances, if there is a default, that should exist everywhere! And at instance creation time, if you specify a bridge, we check anyway! (of course if no default one is there, default nic mode is routed) :) > Now if this is done via empty default bridge or a boolean flag it's > irrelevant. > Well, it depends on the semantics we want to give :) Thanks, Guido
