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. 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-...)? Thanks, Guido
