10:52 a.m.
------=_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...
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--
9:02 p.m.
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
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 the network at
RESTFul API?
Best regards,
Yevgeny Zaspitsky
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4:55 a.m.
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.
4:15 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:11 a.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
10:10 a.m.
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.
5:43 a.m.
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:
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.
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&quo...
.
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--
10:13 a.m.
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.
6:31 a.m.
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
1:12 p.m.
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(a)redhat.com>
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
2:54 a.m.
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(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
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. 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(a)redhat.com>
> 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
>
>
noon
* 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(a)redhat.com>
> To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> 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. 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(a)redhat.com>
> > 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
>
9:43 a.m.
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(a)redhat.com>
> To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
> 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. 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(a)redhat.com>
>> 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
>
3534
days inactive
3541
days old
12 comments
7 participants
participants (7)
-
Dan Kenigsberg -
Einav Cohen -
Lior Vernia -
Livnat Peer -
Moti Asayag -
Yair Zaslavsky -
Yevgeny Zaspitsky