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

Lior Vernia lvernia at redhat.com
Sun Aug 17 09:15:23 UTC 2014



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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 



More information about the Devel mailing list