On Sun, Aug 17, 2014 at 03:11:51PM +0300, Yevgeny Zaspitsky wrote: > > On 17/08/14 12:15, Lior Vernia wrote: > > > >On 15/08/14 12:55, Dan Kenigsberg wrote: > >>On Thu, Aug 14, 2014 at 11:52:41AM -0400, Yevgeny Zaspitsky wrote: > >>>Hi All, > >>> > >>>The proposed feature will allow defining an arbitrary network in the DC as > >>>the management network for the cluster, which in its turn will allow > >>>assigning different VLANs for the management networks in the same DC. > >>> > >>>Feature page can be found here - > >>>http://www.ovirt.org/Features/Management_Network_As_A_Role . > >>> > >>>Please take a look into the page especially into "Open issues" section. > >>>I'd like to have your opinions on that. > >>May I ask why you change the default management network from ovirtmgmt > >>to "Management"? (And why the upercase M?) > >I think what Yevgeny meant to write was that this MIGHT be an > >interesting opportunity to eliminate the difference in mgmt network > >naming between oVirt and RHEV, which will facilitate moving between them > >(if users either find that they require or no longer require Red Hat > >support). > > > >Assuming that it's possible to make this change without affecting > >existing deployments, which I think it is, this sounds good to me > >(although not necessarily "Management"). > Lior, thank you for making my things clearer. > Uniforming is a "nice to have" part of the feature, certainly isn't its core > part.
In that case, I prefer to have "ovirtmgmt" everywhere, or alternatively move to "default". As Lior aluded, it would be quite confusing to have a host with a "management" network defined, but has another network serving as the management netwotk. > > > >Keep in mind that once the management network is just a role, the > >default network appearing in oVirt is potentially just that - a default > >network, like the default DC and cluster, aimed at making a first setup > >easier. It is no longer (necessarily) the management network that has to > >be present due to business logic constraints. > > > >>Regarding your open question: "Creating new cluster would have to > >>receive the new parameter (management network)" This new parameter > >>should be kept optional, with a default value of ovirtmgmt. This way, a > >>user that is unaware of the new feature, would see no change in > >>functionality. > >I agree that this parameter should probably not be mandatory, in fact > >I'm not sure that it should exist at all. There are definitely other > >alternatives and I would expect a more thorough discussion of this and > >of other flows. > > > >Let's imagine a new cluster is created, and nothing happens by default. > >Maybe the right thing to do would just be to endow all special roles > >upon the first network assigned to the cluster, and allow users to > >change it later as they see fit? > > > >Or maybe it's okay to have a cluster without any management network, and > >just have all hosts added to it non-operational until users choose one? > >Installation should still technically succeed because a host is added by > >supplying an IP address or FQDN (oVirt might still say that the > >installation failed in this case as the management network wasn't > >configured - in which case maybe we should change this behavior). > >Successive Setup Networks operations will fail while no management > >network is attached to the host. > > > IMHO having additional parameter in "create new cluster" is the smallest API > break. The new parameter could be optional (with "ovirtmgmt" as the default > value) and in case that the network does not exist, it will be created upon > creating the cluster. That way we'll keep the API compatibility in tact. > Allowing creating cluster with no management network will have much wider > impact (which is also API backward compatibility break). > >>The feature page should discuss the possibility of chaning the > >>management role. Is it supported after there are hosts in the cluster? > >>If we allow that, there's a bit of complexity. The management network's > >>gateway is used as the default route of each host. If you change the > >>role, all hosts should be notified (with a new setupNetwork command). > >> > >>I think that the cleanest solution would be to allow editing, but report > >>the hosts as out-of-sync. This approach requires a Vdsm-side change - it > >>would need to report which of its network is the default route. > >> > >I'm not a fan of sending out batch host operations on the basis of a > >network cluster role change - this isn't something that is currently > >associated with role changes. > > > >The easiest thing would be to block the action if any hosts are active > >in the cluster - I'm not sure this is a bad idea, as I don't think the > >management network will be changed often. > Blocking will reduce the feature usability even though it happens rarely. > >The second easiest thing to do would be nothing - let the hosts move to > >non-operational if they don't have the new management network > >configured, or stay active if they do, but that will still leave their > >default route the way it was (this added complexity is why it's only the > >second easiest). That was my suggestion - just mark these hosts as unsync'ed. Let the user decide when and where to re-sync default routing. > > > >What is the rationale behind the coupling between management network and > >default routing? That it is the one network that is guaranteed to work? Indeed. And backward compatibility, too - before we had source routing we had all routing done via ovirtmgmt, not only default one. > >Maybe it would be a good idea to decouple them and allow to supply a > >default route for a host independently? Usually I love to supply users with knobs to play with, but I find it a bit hard to find the usefulness of this one. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
