------=_Part_21030313_114145744.1408031561755 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 ------=_Part_21030313_114145744.1408031561755 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi All,<br></div><div><br></div><div>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.<br></div><div><br></div><div>Feature page can be found here - <a target="_blank" href="http://www.ovirt.org/Features/Management_Network_As_A_Role" data-mce-href="http://www.ovirt.org/Features/Management_Network_As_A_Role">http://www.ovirt.org/Features/Management_Network_As_A_Role</a>.<br></div><div><br></div><div>Please take a look into the page especially into "Open issues" section. I'd like to have your opinions on that.<br></div><div><br></div><div><br>Best regards, <br>Yevgeny Zaspitsky <br><br></div></div></body></html> ------=_Part_21030313_114145744.1408031561755--
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: devel@ovirt.org Cc: rhevm-network-staff@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 the network at RESTFul API?
Best regards, Yevgeny Zaspitsky
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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?) 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.
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
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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.
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?) We'd like to get rid of that difference between oVirt and REVM. IMHO
This is a multi-part message in MIME format. --------------050009080408030600070300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 15/08/14 12:55, Dan Kenigsberg wrote: 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=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <link href="chrome://translator/skin/floatingPanel.css" type="text/css" rel="stylesheet"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <div class="moz-cite-prefix">On 15/08/14 12:55, Dan Kenigsberg wrote:<br> </div> <blockquote cite="mid:20140815095523.GA6805@redhat.com" type="cite"> <pre wrap="">On Thu, Aug 14, 2014 at 11:52:41AM -0400, Yevgeny Zaspitsky wrote: </pre> <blockquote type="cite"> <pre wrap="">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 - <a class="moz-txt-link-freetext" href="http://www.ovirt.org/Features/Management_Network_As_A_Role">http://www.ovirt.org/Features/Management_Network_As_A_Role</a> . Please take a look into the page especially into "Open issues" section. I'd like to have your opinions on that. </pre> </blockquote> <pre wrap=""> May I ask why you change the default management network from ovirtmgmt to "Management"? (And why the upercase M?)</pre> </blockquote> 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.<br> If you do not like capital letters in the network name I'm OK with changing it to the lower one.<br> <blockquote cite="mid:20140815095523.GA6805@redhat.com" type="cite"> <pre wrap=""> 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. </pre> </blockquote> Using a specific network name seems isn't possible, as that network might be not existent at the time of issuing the command.<br> 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.<br> <blockquote cite="mid:20140815095523.GA6805@redhat.com" type="cite"> <pre wrap=""> 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.</pre> </blockquote> Thank you for turning my attention to this scenario, I'll update the wiki page.<br> <blockquote cite="mid:20140815095523.GA6805@redhat.com" type="cite"> <pre wrap=""> Dan. </pre> </blockquote> <br> <div style="bottom: auto; left: 311px; right: auto; top: 371px; display: none;" class="translator-theme-default" id="translator-floating-panel"> <div title="Click to translate" id="translator-floating-panel-button"></div> </div> </body> </html> --------------050009080408030600070300--
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 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?) 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.
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.
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
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. radio button). A network has a status field in the context a cluster: A new required network 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, 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 network on cluster A is configured on host, but not attached to cluster B, and that network is management on the host by label, changing the cluster will remove 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" <yzaspits@redhat.com> To: devel@ovirt.org Cc: rhevm-network-staff@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
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 protocol. 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 changing the management network in such clusters, or we suggest a method to update the host address and its certificate. ----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@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. radio button).
A network has a status field in the context a cluster: A new required network 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, 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 network on cluster A is configured on host, but not attached to cluster B, and that network is management on the host by label, changing the cluster will remove 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" <yzaspits@redhat.com> To: devel@ovirt.org Cc: rhevm-network-staff@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
* 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. radio 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" <masayag@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@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. radio button).
A network has a status field in the context a cluster: A new required network 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, 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 network on cluster A is configured on host, but not attached to cluster B, and that network is management on the host by label, changing the cluster will remove 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" <yzaspits@redhat.com> To: devel@ovirt.org Cc: rhevm-network-staff@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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 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. radio 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" <masayag@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@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. radio button).
A network has a status field in the context a cluster: A new required network 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, 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 network on cluster A is configured on host, but not attached to cluster B, and that network is management on the host by label, changing the cluster will remove 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" <yzaspits@redhat.com> To: devel@ovirt.org Cc: rhevm-network-staff@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (7)
-
Dan Kenigsberg -
Einav Cohen -
Lior Vernia -
Livnat Peer -
Moti Asayag -
Yair Zaslavsky -
Yevgeny Zaspitsky