Hi All,

The proposed feature will allow defining an arbitrary network in the D= C as the management network for the cluster, which in its turn will allow a= ssigning different VLANs for the management networks in the same DC.

Feature page can be found here - htt= p://www.ovirt.org/Features/Management_Network_As_A_Role.

Please take a look into the page especially into "Open issue= s" section. I'd like to have your opinions on that.

Best regards,
Yevgeny Zaspitsky

------=3D_Part_21030313_114145744.1408031561755-- --===============9187722141636086302== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" LS0tLS0tPV9QYXJ0XzIxMDMwMzEzXzExNDE0NTc0NC4xNDA4MDMxNTYxNzU1CkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD11dGYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3 Yml0CgpIaSBBbGwsIAoKVGhlIHByb3Bvc2VkIGZlYXR1cmUgd2lsbCBhbGxvdyBkZWZpbmluZyBh biBhcmJpdHJhcnkgbmV0d29yayBpbiB0aGUgREMgYXMgdGhlIG1hbmFnZW1lbnQgbmV0d29yayBm b3IgdGhlIGNsdXN0ZXIsIHdoaWNoIGluIGl0cyB0dXJuIHdpbGwgYWxsb3cgYXNzaWduaW5nIGRp ZmZlcmVudCBWTEFOcyBmb3IgdGhlIG1hbmFnZW1lbnQgbmV0d29ya3MgaW4gdGhlIHNhbWUgREMu IAoKRmVhdHVyZSBwYWdlIGNhbiBiZSBmb3VuZCBoZXJlIC0gaHR0cDovL3d3dy5vdmlydC5vcmcv RmVhdHVyZXMvTWFuYWdlbWVudF9OZXR3b3JrX0FzX0FfUm9sZSAuIAoKUGxlYXNlIHRha2UgYSBs b29rIGludG8gdGhlIHBhZ2UgZXNwZWNpYWxseSBpbnRvICJPcGVuIGlzc3VlcyIgc2VjdGlvbi4g SSdkIGxpa2UgdG8gaGF2ZSB5b3VyIG9waW5pb25zIG9uIHRoYXQuIAoKCkJlc3QgcmVnYXJkcywg CllldmdlbnkgWmFzcGl0c2t5IAoKCi0tLS0tLT1fUGFydF8yMTAzMDMxM18xMTQxNDU3NDQuMTQw ODAzMTU2MTc1NQpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD11dGYtOApDb250ZW50 LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0Cgo8aHRtbD48Ym9keT48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmOyBmb250LXNpemU6 IDEycHQ7IGNvbG9yOiAjMDAwMDAwIj48ZGl2PkhpIEFsbCw8YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGUgcHJvcG9zZWQgZmVhdHVyZSB3aWxsIGFsbG93IGRlZmluaW5nIGFuIGFyYml0 cmFyeSBuZXR3b3JrIGluIHRoZSBEQyBhcyB0aGUgbWFuYWdlbWVudCBuZXR3b3JrIGZvciB0aGUg Y2x1c3Rlciwgd2hpY2ggaW4gaXRzIHR1cm4gd2lsbCBhbGxvdyBhc3NpZ25pbmcgZGlmZmVyZW50 IFZMQU5zIGZvciB0aGUgbWFuYWdlbWVudCBuZXR3b3JrcyBpbiB0aGUgc2FtZSBEQy48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5GZWF0dXJlIHBhZ2UgY2FuIGJlIGZvdW5kIGhlcmUgLSA8 YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0cDovL3d3dy5vdmlydC5vcmcvRmVhdHVyZXMvTWFu YWdlbWVudF9OZXR3b3JrX0FzX0FfUm9sZSIgZGF0YS1tY2UtaHJlZj0iaHR0cDovL3d3dy5vdmly dC5vcmcvRmVhdHVyZXMvTWFuYWdlbWVudF9OZXR3b3JrX0FzX0FfUm9sZSI+aHR0cDovL3d3dy5v dmlydC5vcmcvRmVhdHVyZXMvTWFuYWdlbWVudF9OZXR3b3JrX0FzX0FfUm9sZTwvYT4uPGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+UGxlYXNlIHRha2UgYSBsb29rIGludG8gdGhlIHBhZ2Ug ZXNwZWNpYWxseSBpbnRvICJPcGVuIGlzc3VlcyIgc2VjdGlvbi4gSSdkIGxpa2UgdG8gaGF2ZSB5 b3VyIG9waW5pb25zIG9uIHRoYXQuPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPkJl c3QgcmVnYXJkcywgPGJyPllldmdlbnkgWmFzcGl0c2t5IDxicj48YnI+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4KLS0tLS0tPV9QYXJ0XzIxMDMwMzEzXzExNDE0NTc0NC4xNDA4MDMxNTYxNzU1 LS0K --===============9187722141636086302==-- From yzaslavs at redhat.com Thu Aug 14 22:02:14 2014 Content-Type: multipart/mixed; boundary="===============5846212414473602070==" MIME-Version: 1.0 From: Yair Zaslavsky To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Thu, 14 Aug 2014 22:02:13 -0400 Message-ID: <1689303199.43348221.1408068133449.JavaMail.zimbra@redhat.com> In-Reply-To: 1443778555.21030314.1408031561756.JavaMail.zimbra@redhat.com --===============5846212414473602070== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Yevgeny Zaspitsky" > To: devel(a)ovirt.org > Cc: rhevm-network-staff(a)redhat.com > Sent: Thursday, August 14, 2014 6:52:41 PM > Subject: [ovirt-devel] Management network as a role - design proposal > = > 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. Hi, is there no way on getting some default value in case you do not pass t= he network at RESTFul API? > = > = > Best regards, > Yevgeny Zaspitsky > = > = > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel --===============5846212414473602070==-- From danken at redhat.com Fri Aug 15 05:55:26 2014 Content-Type: multipart/mixed; boundary="===============3836237521858556738==" MIME-Version: 1.0 From: Dan Kenigsberg To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Fri, 15 Aug 2014 10:55:23 +0100 Message-ID: <20140815095523.GA6805@redhat.com> In-Reply-To: 1443778555.21030314.1408031561756.JavaMail.zimbra@redhat.com --===============3836237521858556738== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 a= s the management network for the cluster, which in its turn will allow assi= gning 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?) 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. 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. Dan. --===============3836237521858556738==-- From lvernia at redhat.com Sun Aug 17 05:13:05 2014 Content-Type: multipart/mixed; boundary="===============6804340297788064110==" MIME-Version: 1.0 From: Lior Vernia To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Sun, 17 Aug 2014 12:15:23 +0300 Message-ID: <53F072AB.5030800@redhat.com> In-Reply-To: 20140815095523.GA6805@redhat.com --===============6804340297788064110== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 ass= igning different VLANs for the management networks in the same DC. = >> >> Feature page can be found here - http://www.ovirt.org/Features/Managemen= t_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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >=20 --===============6804340297788064110==-- From yzaspits at redhat.com Sun Aug 17 06:44:01 2014 Content-Type: multipart/mixed; boundary="===============3330679172897207909==" MIME-Version: 1.0 From: Yevgeny Zaspitsky To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Sun, 17 Aug 2014 13:43:59 +0300 Message-ID: <53F0876F.6030801@redhat.com> In-Reply-To: 20140815095523.GA6805@redhat.com --===============3330679172897207909== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------050009080408030600070300 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit 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 ass= igning different VLANs for the management networks in the same DC. >> >> Feature page can be found here - http://www.ovirt.org/Features/Managemen= t_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?) We'd like to get rid of that difference between oVirt and REVM. IMHO = there's no good reason for having product name in the network/bridge name. If you do not like capital letters in the network name I'm OK with = changing it to the lower one. > > 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. Using a specific network name seems isn't possible, as that network = might be not existent at the time of issuing the command. Doing so could reduce the number cases where backward compatibility is = broken, but can not eliminate it totally. In those broken cases we might = return an error to a RESTful API user. > 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. Thank you for turning my attention to this scenario, I'll update the = wiki page. > > Dan. --------------050009080408030600070300 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit

On 15/08/14 12:55, Dan Kenigsberg wrote:

On Thu, Aug 14, 2014 at 11:52:41AM -0400, Yevgeny Zasp=
itsky 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 assign=
ing different VLANs for the management networks in the same DC. =


Feature page can be found here - http://www.ovi=
rt.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?)

We'd like to get rid of that difference between oVirt and REVM. IMHO there's no good reason for having product name in the network/bridge name.
If you do not like capital letters in the network name I'm OK with changing it to the lower one.


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.

Using a specific network name seems isn't possible, as that network might be not existent at the time of issuing the command.
Doing so could reduce the number cases where backward compatibility is broken, but can not eliminate it totally. In those broken cases we might return an error to a RESTful API user.

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.

Thank you for turning my attention to this scenario, I'll update the wiki page.


Dan.

--------------050009080408030600070300-- --===============3330679172897207909== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNTAwMDkwODA0MDgwMzA2MDAwNzAzMDAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKCk9uIDE1LzA4LzE0IDEyOjU1LCBEYW4gS2VuaWdzYmVyZyB3cm90ZToKPiBPbiBUaHUs IEF1ZyAxNCwgMjAxNCBhdCAxMTo1Mjo0MUFNIC0wNDAwLCBZZXZnZW55IFphc3BpdHNreSB3cm90 ZToKPj4gSGkgQWxsLAo+Pgo+PiBUaGUgcHJvcG9zZWQgZmVhdHVyZSB3aWxsIGFsbG93IGRlZmlu aW5nIGFuIGFyYml0cmFyeSBuZXR3b3JrIGluIHRoZSBEQyBhcyB0aGUgbWFuYWdlbWVudCBuZXR3 b3JrIGZvciB0aGUgY2x1c3Rlciwgd2hpY2ggaW4gaXRzIHR1cm4gd2lsbCBhbGxvdyBhc3NpZ25p bmcgZGlmZmVyZW50IFZMQU5zIGZvciB0aGUgbWFuYWdlbWVudCBuZXR3b3JrcyBpbiB0aGUgc2Ft ZSBEQy4KPj4KPj4gRmVhdHVyZSBwYWdlIGNhbiBiZSBmb3VuZCBoZXJlIC0gaHR0cDovL3d3dy5v dmlydC5vcmcvRmVhdHVyZXMvTWFuYWdlbWVudF9OZXR3b3JrX0FzX0FfUm9sZSAuCj4+Cj4+IFBs ZWFzZSB0YWtlIGEgbG9vayBpbnRvIHRoZSBwYWdlIGVzcGVjaWFsbHkgaW50byAiT3BlbiBpc3N1 ZXMiIHNlY3Rpb24uIEknZCBsaWtlIHRvIGhhdmUgeW91ciBvcGluaW9ucyBvbiB0aGF0Lgo+IE1h eSBJIGFzayB3aHkgeW91IGNoYW5nZSB0aGUgZGVmYXVsdCBtYW5hZ2VtZW50IG5ldHdvcmsgZnJv bSBvdmlydG1nbXQKPiB0byAiTWFuYWdlbWVudCI/IChBbmQgd2h5IHRoZSB1cGVyY2FzZSBNPykK V2UnZCBsaWtlIHRvIGdldCByaWQgb2YgdGhhdCBkaWZmZXJlbmNlIGJldHdlZW4gb1ZpcnQgYW5k IFJFVk0uIElNSE8gCnRoZXJlJ3Mgbm8gZ29vZCByZWFzb24gZm9yIGhhdmluZyBwcm9kdWN0IG5h bWUgaW4gdGhlIG5ldHdvcmsvYnJpZGdlIG5hbWUuCklmIHlvdSBkbyBub3QgbGlrZSBjYXBpdGFs IGxldHRlcnMgaW4gdGhlIG5ldHdvcmsgbmFtZSBJJ20gT0sgd2l0aCAKY2hhbmdpbmcgaXQgdG8g dGhlIGxvd2VyIG9uZS4KPgo+IFJlZ2FyZGluZyB5b3VyIG9wZW4gcXVlc3Rpb246ICJDcmVhdGlu ZyBuZXcgY2x1c3RlciB3b3VsZCBoYXZlIHRvCj4gcmVjZWl2ZSB0aGUgbmV3IHBhcmFtZXRlciAo bWFuYWdlbWVudCBuZXR3b3JrKSIgVGhpcyBuZXcgcGFyYW1ldGVyCj4gc2hvdWxkIGJlIGtlcHQg b3B0aW9uYWwsIHdpdGggYSBkZWZhdWx0IHZhbHVlIG9mIG92aXJ0bWdtdC4gVGhpcyB3YXksIGEK PiB1c2VyIHRoYXQgaXMgdW5hd2FyZSBvZiB0aGUgbmV3IGZlYXR1cmUsIHdvdWxkIHNlZSBubyBj aGFuZ2UgaW4KPiBmdW5jdGlvbmFsaXR5LgpVc2luZyBhIHNwZWNpZmljIG5ldHdvcmsgbmFtZSBz ZWVtcyBpc24ndCBwb3NzaWJsZSwgYXMgdGhhdCBuZXR3b3JrIAptaWdodCBiZSBub3QgZXhpc3Rl bnQgYXQgdGhlIHRpbWUgb2YgaXNzdWluZyB0aGUgY29tbWFuZC4KRG9pbmcgc28gY291bGQgcmVk dWNlIHRoZSBudW1iZXIgY2FzZXMgd2hlcmUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyAKYnJv a2VuLCBidXQgY2FuIG5vdCBlbGltaW5hdGUgaXQgdG90YWxseS4gSW4gdGhvc2UgYnJva2VuIGNh c2VzIHdlIG1pZ2h0IApyZXR1cm4gYW4gZXJyb3IgdG8gYSBSRVNUZnVsIEFQSSB1c2VyLgo+IFRo ZSBmZWF0dXJlIHBhZ2Ugc2hvdWxkIGRpc2N1c3MgdGhlIHBvc3NpYmlsaXR5IG9mIGNoYW5pbmcg dGhlCj4gbWFuYWdlbWVudCByb2xlLiBJcyBpdCBzdXBwb3J0ZWQgYWZ0ZXIgdGhlcmUgYXJlIGhv c3RzIGluIHRoZSBjbHVzdGVyPwo+IElmIHdlIGFsbG93IHRoYXQsIHRoZXJlJ3MgYSBiaXQgb2Yg Y29tcGxleGl0eS4gVGhlIG1hbmFnZW1lbnQgbmV0d29yaydzCj4gZ2F0ZXdheSBpcyB1c2VkIGFz IHRoZSBkZWZhdWx0IHJvdXRlIG9mIGVhY2ggaG9zdC4gSWYgeW91IGNoYW5nZSB0aGUKPiByb2xl LCBhbGwgaG9zdHMgc2hvdWxkIGJlIG5vdGlmaWVkICh3aXRoIGEgbmV3IHNldHVwTmV0d29yayBj b21tYW5kKS4KPgo+IEkgdGhpbmsgdGhhdCB0aGUgY2xlYW5lc3Qgc29sdXRpb24gd291bGQgYmUg dG8gYWxsb3cgZWRpdGluZywgYnV0IHJlcG9ydAo+IHRoZSBob3N0cyBhcyBvdXQtb2Ytc3luYy4g VGhpcyBhcHByb2FjaCByZXF1aXJlcyBhIFZkc20tc2lkZSBjaGFuZ2UgLSBpdAo+IHdvdWxkIG5l ZWQgdG8gcmVwb3J0IHdoaWNoIG9mIGl0cyBuZXR3b3JrIGlzIHRoZSBkZWZhdWx0IHJvdXRlLgpU aGFuayB5b3UgZm9yIHR1cm5pbmcgbXkgYXR0ZW50aW9uIHRvIHRoaXMgc2NlbmFyaW8sIEknbGwg dXBkYXRlIHRoZSAKd2lraSBwYWdlLgo+Cj4gRGFuLgoKCi0tLS0tLS0tLS0tLS0tMDUwMDA5MDgw NDA4MDMwNjAwMDcwMzAwCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5 LTEKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogN2JpdAoKPGh0bWw+CiAgPGhlYWQ+CiAgICA8 bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSIKICAgICAgaHR0cC1l cXVpdj0iQ29udGVudC1UeXBlIj4KICAgIDxsaW5rIGhyZWY9ImNocm9tZTovL3RyYW5zbGF0b3Iv c2tpbi9mbG9hdGluZ1BhbmVsLmNzcyIKICAgICAgdHlwZT0idGV4dC9jc3MiIHJlbD0ic3R5bGVz aGVldCI+CiAgPC9oZWFkPgogIDxib2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYi PgogICAgPGJyPgogICAgPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNS8wOC8xNCAx Mjo1NSwgRGFuIEtlbmlnc2JlcmcKICAgICAgd3JvdGU6PGJyPgogICAgPC9kaXY+CiAgICA8Ymxv Y2txdW90ZSBjaXRlPSJtaWQ6MjAxNDA4MTUwOTU1MjMuR0E2ODA1QHJlZGhhdC5jb20iIHR5cGU9 ImNpdGUiPgogICAgICA8cHJlIHdyYXA9IiI+T24gVGh1LCBBdWcgMTQsIDIwMTQgYXQgMTE6NTI6 NDFBTSAtMDQwMCwgWWV2Z2VueSBaYXNwaXRza3kgd3JvdGU6CjwvcHJlPgogICAgICA8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4KICAgICAgICA8cHJlIHdyYXA9IiI+SGkgQWxsLCAKClRoZSBwcm9w b3NlZCBmZWF0dXJlIHdpbGwgYWxsb3cgZGVmaW5pbmcgYW4gYXJiaXRyYXJ5IG5ldHdvcmsgaW4g dGhlIERDIGFzIHRoZSBtYW5hZ2VtZW50IG5ldHdvcmsgZm9yIHRoZSBjbHVzdGVyLCB3aGljaCBp biBpdHMgdHVybiB3aWxsIGFsbG93IGFzc2lnbmluZyBkaWZmZXJlbnQgVkxBTnMgZm9yIHRoZSBt YW5hZ2VtZW50IG5ldHdvcmtzIGluIHRoZSBzYW1lIERDLiAKCkZlYXR1cmUgcGFnZSBjYW4gYmUg Zm91bmQgaGVyZSAtIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHA6 Ly93d3cub3ZpcnQub3JnL0ZlYXR1cmVzL01hbmFnZW1lbnRfTmV0d29ya19Bc19BX1JvbGUiPmh0 dHA6Ly93d3cub3ZpcnQub3JnL0ZlYXR1cmVzL01hbmFnZW1lbnRfTmV0d29ya19Bc19BX1JvbGU8 L2E+IC4gCgpQbGVhc2UgdGFrZSBhIGxvb2sgaW50byB0aGUgcGFnZSBlc3BlY2lhbGx5IGludG8g Ik9wZW4gaXNzdWVzIiBzZWN0aW9uLiBJJ2QgbGlrZSB0byBoYXZlIHlvdXIgb3BpbmlvbnMgb24g dGhhdC4gCjwvcHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0iIj4KTWF5 IEkgYXNrIHdoeSB5b3UgY2hhbmdlIHRoZSBkZWZhdWx0IG1hbmFnZW1lbnQgbmV0d29yayBmcm9t IG92aXJ0bWdtdAp0byAiTWFuYWdlbWVudCI/IChBbmQgd2h5IHRoZSB1cGVyY2FzZSBNPyk8L3By ZT4KICAgIDwvYmxvY2txdW90ZT4KICAgIFdlJ2QgbGlrZSB0byBnZXQgcmlkIG9mIHRoYXQgZGlm ZmVyZW5jZSBiZXR3ZWVuIG9WaXJ0IGFuZCBSRVZNLiBJTUhPCiAgICB0aGVyZSdzIG5vIGdvb2Qg cmVhc29uIGZvciBoYXZpbmcgcHJvZHVjdCBuYW1lIGluIHRoZSBuZXR3b3JrL2JyaWRnZQogICAg bmFtZS48YnI+CiAgICBJZiB5b3UgZG8gbm90IGxpa2UgY2FwaXRhbCBsZXR0ZXJzIGluIHRoZSBu ZXR3b3JrIG5hbWUgSSdtIE9LIHdpdGgKICAgIGNoYW5naW5nIGl0IHRvIHRoZSBsb3dlciBvbmUu PGJyPgogICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjIwMTQwODE1MDk1NTIzLkdBNjgwNUByZWRo YXQuY29tIiB0eXBlPSJjaXRlIj4KICAgICAgPHByZSB3cmFwPSIiPgoKUmVnYXJkaW5nIHlvdXIg b3BlbiBxdWVzdGlvbjogIkNyZWF0aW5nIG5ldyBjbHVzdGVyIHdvdWxkIGhhdmUgdG8KcmVjZWl2 ZSB0aGUgbmV3IHBhcmFtZXRlciAobWFuYWdlbWVudCBuZXR3b3JrKSIgVGhpcyBuZXcgcGFyYW1l dGVyCnNob3VsZCBiZSBrZXB0IG9wdGlvbmFsLCB3aXRoIGEgZGVmYXVsdCB2YWx1ZSBvZiBvdmly dG1nbXQuIFRoaXMgd2F5LCBhCnVzZXIgdGhhdCBpcyB1bmF3YXJlIG9mIHRoZSBuZXcgZmVhdHVy ZSwgd291bGQgc2VlIG5vIGNoYW5nZSBpbgpmdW5jdGlvbmFsaXR5Lgo8L3ByZT4KICAgIDwvYmxv Y2txdW90ZT4KICAgIFVzaW5nIGEgc3BlY2lmaWMgbmV0d29yayBuYW1lIHNlZW1zIGlzbid0IHBv c3NpYmxlLCBhcyB0aGF0IG5ldHdvcmsKICAgIG1pZ2h0IGJlIG5vdCBleGlzdGVudCBhdCB0aGUg dGltZSBvZiBpc3N1aW5nIHRoZSBjb21tYW5kLjxicj4KICAgIERvaW5nIHNvIGNvdWxkIHJlZHVj ZSB0aGUgbnVtYmVyIGNhc2VzIHdoZXJlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkKICAgIGlzIGJy b2tlbiwgYnV0IGNhbiBub3QgZWxpbWluYXRlIGl0IHRvdGFsbHkuIEluIHRob3NlIGJyb2tlbiBj YXNlcwogICAgd2UgbWlnaHQgcmV0dXJuIGFuIGVycm9yIHRvIGEgUkVTVGZ1bCBBUEkgdXNlci48 YnI+CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MjAxNDA4MTUwOTU1MjMuR0E2ODA1QHJlZGhh dC5jb20iIHR5cGU9ImNpdGUiPgogICAgICA8cHJlIHdyYXA9IiI+ClRoZSBmZWF0dXJlIHBhZ2Ug c2hvdWxkIGRpc2N1c3MgdGhlIHBvc3NpYmlsaXR5IG9mIGNoYW5pbmcgdGhlCm1hbmFnZW1lbnQg cm9sZS4gSXMgaXQgc3VwcG9ydGVkIGFmdGVyIHRoZXJlIGFyZSBob3N0cyBpbiB0aGUgY2x1c3Rl cj8KSWYgd2UgYWxsb3cgdGhhdCwgdGhlcmUncyBhIGJpdCBvZiBjb21wbGV4aXR5LiBUaGUgbWFu YWdlbWVudCBuZXR3b3JrJ3MKZ2F0ZXdheSBpcyB1c2VkIGFzIHRoZSBkZWZhdWx0IHJvdXRlIG9m IGVhY2ggaG9zdC4gSWYgeW91IGNoYW5nZSB0aGUKcm9sZSwgYWxsIGhvc3RzIHNob3VsZCBiZSBu b3RpZmllZCAod2l0aCBhIG5ldyBzZXR1cE5ldHdvcmsgY29tbWFuZCkuCgpJIHRoaW5rIHRoYXQg dGhlIGNsZWFuZXN0IHNvbHV0aW9uIHdvdWxkIGJlIHRvIGFsbG93IGVkaXRpbmcsIGJ1dCByZXBv cnQKdGhlIGhvc3RzIGFzIG91dC1vZi1zeW5jLiBUaGlzIGFwcHJvYWNoIHJlcXVpcmVzIGEgVmRz bS1zaWRlIGNoYW5nZSAtIGl0CndvdWxkIG5lZWQgdG8gcmVwb3J0IHdoaWNoIG9mIGl0cyBuZXR3 b3JrIGlzIHRoZSBkZWZhdWx0IHJvdXRlLjwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgVGhh bmsgeW91IGZvciB0dXJuaW5nIG15IGF0dGVudGlvbiB0byB0aGlzIHNjZW5hcmlvLCBJJ2xsIHVw ZGF0ZSB0aGUKICAgIHdpa2kgcGFnZS48YnI+CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MjAx NDA4MTUwOTU1MjMuR0E2ODA1QHJlZGhhdC5jb20iIHR5cGU9ImNpdGUiPgogICAgICA8cHJlIHdy YXA9IiI+CgpEYW4uCjwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogICAgPGRpdiBz dHlsZT0iYm90dG9tOiBhdXRvOyBsZWZ0OiAzMTFweDsgcmlnaHQ6IGF1dG87IHRvcDogMzcxcHg7 CiAgICAgIGRpc3BsYXk6IG5vbmU7IiBjbGFzcz0idHJhbnNsYXRvci10aGVtZS1kZWZhdWx0Igog ICAgICBpZD0idHJhbnNsYXRvci1mbG9hdGluZy1wYW5lbCI+CiAgICAgIDxkaXYgdGl0bGU9IkNs aWNrIHRvIHRyYW5zbGF0ZSIKICAgICAgICBpZD0idHJhbnNsYXRvci1mbG9hdGluZy1wYW5lbC1i dXR0b24iPjwvZGl2PgogICAgPC9kaXY+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0t LTA1MDAwOTA4MDQwODAzMDYwMDA3MDMwMC0tCg== --===============3330679172897207909==-- From lpeer at redhat.com Sun Aug 17 07:31:48 2014 Content-Type: multipart/mixed; boundary="===============3589863649030549642==" MIME-Version: 1.0 From: Livnat Peer To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Sun, 17 Aug 2014 14:31:43 +0300 Message-ID: <53F0929F.6010605@redhat.com> In-Reply-To: 1443778555.21030314.1408031561756.JavaMail.zimbra@redhat.com --===============3589863649030549642== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 08/14/2014 06:52 PM, 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. > = > = > Best regards, > Yevgeny Zaspitsky > = Hi Yevgeny, a few comments: 1. I'm missing mockups for the UI changes. 2. I'm missing description of the changes in the system behaviour - - A new cluster is added to the DC, what happens? ovirtmgmt used to be attached to it by default, now each cluster can have a different network as management network.... - Why do we create a new network by default? Is it still needed? - What happens when the management network becomes unavailable on a host? currently we loose connectivity with the host, can we do better? - What limitations come with the role of management network? For example currently the management network can not be deleted, now it can't be detached, network must be mandatory (vs optional) etc. - User should not be able adding a host to the cluster before there is a network with the mgmt role. 3. The high level feature page should be used for describing the system behaviour and the detailed user page for implementation changes. Thanks, Livnat Livnat --===============3589863649030549642==-- From yzaspits at redhat.com Sun Aug 17 08:11:54 2014 Content-Type: multipart/mixed; boundary="===============5647779199825347381==" MIME-Version: 1.0 From: Yevgeny Zaspitsky To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Sun, 17 Aug 2014 15:11:51 +0300 Message-ID: <53F09C07.7090801@redhat.com> In-Reply-To: 53F072AB.5030800@redhat.com --===============5647779199825347381== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 as= signing different VLANs for the management networks in the same DC. >>> >>> Feature page can be found here - http://www.ovirt.org/Features/Manageme= nt_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. > > 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). > > 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'll add those scenarios to the page. > > I would expect some sort of reference to these. > >> Dan. >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> --===============5647779199825347381==-- From masayag at redhat.com Sun Aug 17 14:12:26 2014 Content-Type: multipart/mixed; boundary="===============1853804734043143591==" MIME-Version: 1.0 From: Moti Asayag To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Sun, 17 Aug 2014 14:12:25 -0400 Message-ID: <1647449014.8074055.1408299145393.JavaMail.zimbra@redhat.com> In-Reply-To: 1443778555.21030314.1408031561756.JavaMail.zimbra@redhat.com --===============1853804734043143591== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, * The mockups/UI is missing the "Cluster --> Manage networks" screen which = should present the selection of a network as a management network. That abi= lity should probably be behave as migration and display role (i.e. radio bu= tton). A network has a status field in the context a cluster: A new required netwo= rk is added as 'non-operational', and will change its status to 'operationa= l' when it is configured on all of the cluster's hosts. If the network is added as 'not required', it will automatically be set as = 'operational'. = Setting the network status on cluster level as 'operational' is determined = and not reversal. * The introduction is aimed to the first user-flow: "* Appointing a network as the management network will make the network req= uired in the given cluster. " - should block 'non-operational' networks or = 'non required' networks from being selected as a management network, and al= so block any attempt to mark a management network as non-required. * network labels aspect: ** if a labelled network is marked as a management network, removing the la= bel should not remove that network from the hosts (if labelled). ** "Moving a host from a cluster to another one." - if a management network= on cluster A is configured on host, but not attached to cluster B, and tha= t network is management on the host by label, changing the cluster will rem= ove it from the host, which will targeted in a host without a management cl= uster. This should be blocked to avoid loosing connectivity. Regards, Moti ----- Original Message ----- > From: "Yevgeny Zaspitsky" > To: devel(a)ovirt.org > Cc: rhevm-network-staff(a)redhat.com > Sent: Thursday, August 14, 2014 6:52:41 PM > Subject: Management network as a role - design proposal > = > 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. > = > = > Best regards, > Yevgeny Zaspitsky > = >=20 --===============1853804734043143591==-- From masayag at redhat.com Mon Aug 18 03:54:37 2014 Content-Type: multipart/mixed; boundary="===============4889819965271825061==" MIME-Version: 1.0 From: Moti Asayag To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Mon, 18 Aug 2014 03:54:35 -0400 Message-ID: <2018607072.8303047.1408348475832.JavaMail.zimbra@redhat.com> In-Reply-To: 1647449014.8074055.1408299145393.JavaMail.zimbra@redhat.com --===============4889819965271825061== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Additional note: If the new management network is already configured on the= hosts, it should be verified it is configured either with DHCP or static boot prot= ocol. What about the case in which a host was added and installed via a static IP= and not by FQDN ? Currently, we block changing the IP address. Either we block chan= ging the management network in such clusters, or we suggest a method to update the h= ost address and its certificate. ----- Original Message ----- > From: "Moti Asayag" > To: "Yevgeny Zaspitsky" > Cc: devel(a)ovirt.org > Sent: Sunday, August 17, 2014 9:12:25 PM > Subject: Re: Management network as a role - design proposal > = > Hi, > = > * The mockups/UI is missing the "Cluster --> Manage networks" screen which > should present the selection of a network as a management network. That > ability should probably be behave as migration and display role (i.e. rad= io > button). > = > A network has a status field in the context a cluster: A new required net= work > is added as 'non-operational', and will change its status to 'operational' > when it is configured on all of the cluster's hosts. > If the network is added as 'not required', it will automatically be set as > 'operational'. > Setting the network status on cluster level as 'operational' is determined > and not reversal. > = > * The introduction is aimed to the first user-flow: > "* Appointing a network as the management network will make the network > required in the given cluster. " - should block 'non-operational' networks > or 'non required' networks from being selected as a management network, a= nd > also block any attempt to mark a management network as non-required. > = > * network labels aspect: > ** if a labelled network is marked as a management network, removing the > label should not remove that network from the hosts (if labelled). > ** "Moving a host from a cluster to another one." - if a management netwo= rk > on cluster A is configured on host, but not attached to cluster B, and th= at > network is management on the host by label, changing the cluster will rem= ove > it from the host, which will targeted in a host without a management > cluster. This should be blocked to avoid loosing connectivity. > = > Regards, > Moti > = > ----- Original Message ----- > > From: "Yevgeny Zaspitsky" > > To: devel(a)ovirt.org > > Cc: rhevm-network-staff(a)redhat.com > > Sent: Thursday, August 14, 2014 6:52:41 PM > > Subject: Management network as a role - design proposal > > = > > 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. > > = > > = > > Best regards, > > Yevgeny Zaspitsky > > = > > = >=20 --===============4889819965271825061==-- From danken at redhat.com Mon Aug 18 11:10:06 2014 Content-Type: multipart/mixed; boundary="===============4036312977820947390==" MIME-Version: 1.0 From: Dan Kenigsberg To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Mon, 18 Aug 2014 16:10:03 +0100 Message-ID: <20140818151003.GC25590@redhat.com> In-Reply-To: 53F09C07.7090801@redhat.com --===============4036312977820947390== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 D= C as the management network for the cluster, which in its turn will allow a= ssigning different VLANs for the management networks in the same DC. > >>> > >>>Feature page can be found here - http://www.ovirt.org/Features/Managem= ent_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 c= ore > 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 defau= lt > value) and in case that the network does not exist, it will be created up= on > 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. --===============4036312977820947390==-- From danken at redhat.com Mon Aug 18 11:13:27 2014 Content-Type: multipart/mixed; boundary="===============0524984883955472766==" MIME-Version: 1.0 From: Dan Kenigsberg To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Mon, 18 Aug 2014 16:13:23 +0100 Message-ID: <20140818151323.GD25590@redhat.com> In-Reply-To: 53F0876F.6030801@redhat.com --===============0524984883955472766== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun, Aug 17, 2014 at 01:43:59PM +0300, Yevgeny Zaspitsky 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 as= signing different VLANs for the management networks in the same DC. > >> > >>Feature page can be found here - http://www.ovirt.org/Features/Manageme= nt_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?) > We'd like to get rid of that difference between oVirt and REVM. IMHO ther= e's > no good reason for having product name in the network/bridge name. > If you do not like capital letters in the network name I'm OK with changi= ng > it to the lower one. > > > >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. > Using a specific network name seems isn't possible, as that network might= be > not existent at the time of issuing the command. > Doing so could reduce the number cases where backward compatibility is > broken, but can not eliminate it totally. In those broken cases we might > return an error to a RESTful API user. Excuse me, I did not understand break of backward compat. Does the current suggestion at http://www.ovirt.org/Features/Management_Network_As_A_Role#RESTful_API suffer from it? If so, it should be clearly marked and explained. --===============0524984883955472766==-- From ecohen at redhat.com Mon Aug 18 13:00:31 2014 Content-Type: multipart/mixed; boundary="===============4621953804274002664==" MIME-Version: 1.0 From: Einav Cohen To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Mon, 18 Aug 2014 13:00:30 -0400 Message-ID: <1335668119.33280826.1408381230749.JavaMail.zimbra@redhat.com> In-Reply-To: 1647449014.8074055.1408299145393.JavaMail.zimbra@redhat.com --===============4621953804274002664== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > * The mockups/UI is missing the "Cluster --> Manage networks" screen which > should present the selection of a network as a management network. That > ability should probably be behave as migration and display role (i.e. rad= io > button). +1 on that; pointing out that currently, it looks like the columns that = behave like radio-button (i.e. selection of a cell in one row deselects = the cell of the same column in another row) actually contain check check- boxes. would be nice to change that to actual radio-buttons, if possible. = another comment on the New/Edit Cluster dialog: = I am not sure if the location of the Management Network field (at the top = gray area of the dialog) is proper; I am not sure how popular the "use = something other than 'ovirtmgmt' as the management network" use-case will = be. If it is not expected to be that popular, maybe even worth putting = that in a section other than 'General'; maybe even something similar to = the "Manage Network" dialog can be put within the "New Cluster" dialog = in a (new) "Network" side-section? ---- Thanks, Einav ----- Original Message ----- > From: "Moti Asayag" > To: "Yevgeny Zaspitsky" > Cc: devel(a)ovirt.org > Sent: Sunday, August 17, 2014 2:12:25 PM > Subject: Re: [ovirt-devel] Management network as a role - design proposal > = > Hi, > = > * The mockups/UI is missing the "Cluster --> Manage networks" screen which > should present the selection of a network as a management network. That > ability should probably be behave as migration and display role (i.e. rad= io > button). > = > A network has a status field in the context a cluster: A new required net= work > is added as 'non-operational', and will change its status to 'operational' > when it is configured on all of the cluster's hosts. > If the network is added as 'not required', it will automatically be set as > 'operational'. > Setting the network status on cluster level as 'operational' is determined > and not reversal. > = > * The introduction is aimed to the first user-flow: > "* Appointing a network as the management network will make the network > required in the given cluster. " - should block 'non-operational' networks > or 'non required' networks from being selected as a management network, a= nd > also block any attempt to mark a management network as non-required. > = > * network labels aspect: > ** if a labelled network is marked as a management network, removing the > label should not remove that network from the hosts (if labelled). > ** "Moving a host from a cluster to another one." - if a management netwo= rk > on cluster A is configured on host, but not attached to cluster B, and th= at > network is management on the host by label, changing the cluster will rem= ove > it from the host, which will targeted in a host without a management > cluster. This should be blocked to avoid loosing connectivity. > = > Regards, > Moti > = > ----- Original Message ----- > > From: "Yevgeny Zaspitsky" > > To: devel(a)ovirt.org > > Cc: rhevm-network-staff(a)redhat.com > > Sent: Thursday, August 14, 2014 6:52:41 PM > > Subject: Management network as a role - design proposal > > = > > 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. > > = > > = > > Best regards, > > Yevgeny Zaspitsky > > = > > = > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >=20 --===============4621953804274002664==-- From yzaspits at redhat.com Thu Aug 21 10:43:04 2014 Content-Type: multipart/mixed; boundary="===============5300981563075123728==" MIME-Version: 1.0 From: Yevgeny Zaspitsky To: devel at ovirt.org Subject: Re: [ovirt-devel] Management network as a role - design proposal Date: Thu, 21 Aug 2014 17:43:01 +0300 Message-ID: <53F60575.6040401@redhat.com> In-Reply-To: 1335668119.33280826.1408381230749.JavaMail.zimbra@redhat.com --===============5300981563075123728== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Thank you All for your comments. I've updated the page with those and other thoughts. Please have a look at the updated and more mature version of the page. Again, you're more than welcome to send your comments. Regards, Yevgeny On 18/08/14 20:00, Einav Cohen wrote: >> * The mockups/UI is missing the "Cluster --> Manage networks" screen whi= ch >> should present the selection of a network as a management network. That >> ability should probably be behave as migration and display role (i.e. ra= dio >> button). > +1 on that; pointing out that currently, it looks like the columns that > behave like radio-button (i.e. selection of a cell in one row deselects > the cell of the same column in another row) actually contain check check- > boxes. would be nice to change that to actual radio-buttons, if possible. > > another comment on the New/Edit Cluster dialog: > I am not sure if the location of the Management Network field (at the top > gray area of the dialog) is proper; I am not sure how popular the "use > something other than 'ovirtmgmt' as the management network" use-case will > be. If it is not expected to be that popular, maybe even worth putting > that in a section other than 'General'; maybe even something similar to > the "Manage Network" dialog can be put within the "New Cluster" dialog > in a (new) "Network" side-section? > > ---- > Thanks, > Einav > > > ----- Original Message ----- >> From: "Moti Asayag" >> To: "Yevgeny Zaspitsky" >> Cc: devel(a)ovirt.org >> Sent: Sunday, August 17, 2014 2:12:25 PM >> Subject: Re: [ovirt-devel] Management network as a role - design proposal >> >> Hi, >> >> * The mockups/UI is missing the "Cluster --> Manage networks" screen whi= ch >> should present the selection of a network as a management network. That >> ability should probably be behave as migration and display role (i.e. ra= dio >> button). >> >> A network has a status field in the context a cluster: A new required ne= twork >> is added as 'non-operational', and will change its status to 'operationa= l' >> when it is configured on all of the cluster's hosts. >> If the network is added as 'not required', it will automatically be set = as >> 'operational'. >> Setting the network status on cluster level as 'operational' is determin= ed >> and not reversal. >> >> * The introduction is aimed to the first user-flow: >> "* Appointing a network as the management network will make the network >> required in the given cluster. " - should block 'non-operational' networ= ks >> or 'non required' networks from being selected as a management network, = and >> also block any attempt to mark a management network as non-required. >> >> * network labels aspect: >> ** if a labelled network is marked as a management network, removing the >> label should not remove that network from the hosts (if labelled). >> ** "Moving a host from a cluster to another one." - if a management netw= ork >> on cluster A is configured on host, but not attached to cluster B, and t= hat >> network is management on the host by label, changing the cluster will re= move >> it from the host, which will targeted in a host without a management >> cluster. This should be blocked to avoid loosing connectivity. >> >> Regards, >> Moti >> >> ----- Original Message ----- >>> From: "Yevgeny Zaspitsky" >>> To: devel(a)ovirt.org >>> Cc: rhevm-network-staff(a)redhat.com >>> Sent: Thursday, August 14, 2014 6:52:41 PM >>> Subject: Management network as a role - design proposal >>> >>> 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. >>> >>> >>> Best regards, >>> Yevgeny Zaspitsky >>> >>> >> _______________________________________________ >> Devel mailing list >> Devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> --===============5300981563075123728==--