1:43 p.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--