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"). 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. > > 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. 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). What is the rationale behind the coupling between management network and default routing? That it is the one network that is guaranteed to work? Maybe it would be a good idea to decouple them and allow to supply a default route for a host independently? Other flows that aren't covered: * What happens when a host is moved between clusters? * What happens when a cluster is moved between DCs? I would expect some sort of reference to these. > Dan. > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel