[ovirt-devel] Management network as a role - design proposal

[Dan Kenigsberg]

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.