Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1204793 - [RFE] - use ovirtmgmt as the default name for the management network
[RFE] - use ovirtmgmt as the default name for the management network
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.5.0
x86_64 Linux
medium Severity medium
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Vinzenz Feenstra [evilissimo]
Meni Yakove
: FutureFeature
Depends On:
Blocks: 1231379 1231799 1231836 1284288
  Show dependency treegraph
 
Reported: 2015-03-23 10:01 EDT by Yaniv Lavi
Modified: 2017-10-23 20:36 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
With this update, the default name for the Red Hat Enterprise Virtualization management network has changed from 'rhevm' to 'ovirtmgmt'.
Story Points: ---
Clone Of:
: 1231379 1231799 1231836 1284288 (view as bug list)
Environment:
Last Closed: 2016-03-09 16:00:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
juwu: needinfo-
ylavi: testing_beta_priority+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 42384 None None None Never
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-09 20:20:52 EST

  None (edit)
Description Yaniv Lavi 2015-03-23 10:01:56 EDT
Description of problem:
Reduce diff between upstream and downstream management networks, use the same name for new clusters. ovirt-mgmt should be used for both ovirt & RHEV.
Need to make sure we do not change existing networks and only use new name for new clusters.
Comment 1 Sandro Bonazzola 2015-06-15 09:17:24 EDT
Yaniv, how do you plan to support 3.5 clusters managed by 3.6 engine?
3.5 cluster will have rhevm bridges and 3.6 will have ovirtmgmt.
Comment 2 Sandro Bonazzola 2015-06-15 09:21:59 EDT
Also Yaniv, how does this fit on a Hosted engine deployment upgraded from 3.5 to 3.6?
Comment 3 Yaniv Lavi 2015-06-17 03:56:19 EDT
(In reply to Sandro Bonazzola from comment #1)
> Yaniv, how do you plan to support 3.5 clusters managed by 3.6 engine?

In upgrades it will not change only on fresh installs.

> 3.5 cluster will have rhevm bridges and 3.6 will have ovirtmgmt.

(In reply to Sandro Bonazzola from comment #2)
> Also Yaniv, how does this fit on a Hosted engine deployment upgraded from
> 3.5 to 3.6?

The hosted engine needs to know what management network default name is defined, just like the engine.
Comment 4 Sandro Bonazzola 2015-06-18 01:55:46 EDT
According to comment #3 I'm going to accept the patch for rhevm-setup-plugins.
Will drop the branding also on ovirt-hosted-engine-setup and treat any issue derived by this change as a bug.
Comment 5 Julie 2015-11-15 23:45:21 EST
Hi Yaniv,
   Could you provide some context on why reducing the difference between upstream and downstream is important? 

Cheers,
Julie
Comment 6 Yaniv Lavi 2015-11-22 07:41:29 EST
(In reply to Julie from comment #5)
> Hi Yaniv,
>    Could you provide some context on why reducing the difference between
> upstream and downstream is important? 

it's not. We just need to make sure all the 3.6 docs only have this management network mentioned and not the old one.

> 
> Cheers,
> Julie
Comment 7 Julie 2015-11-22 17:32:20 EST
(In reply to Yaniv Dary from comment #6)
> (In reply to Julie from comment #5)
> > Hi Yaniv,
> >    Could you provide some context on why reducing the difference between
> > upstream and downstream is important? 
> 
> it's not. We just need to make sure all the 3.6 docs only have this
> management network mentioned and not the old one.
> 
> > 
> > Cheers,
> > Julie

So if it's not important, why go through the engineering effort to make this change? As you see, this creates extra workload for the docs team as well. I will create a docs bug for this. Ideally, if Engineering or the PM team see there is docs impact, a docs bug should be created already.

Cheers,
Julie
Comment 8 Yaniv Lavi 2015-11-23 02:57:54 EST
(In reply to Julie from comment #7)
> (In reply to Yaniv Dary from comment #6)
> > (In reply to Julie from comment #5)
> > > Hi Yaniv,
> > >    Could you provide some context on why reducing the difference between
> > > upstream and downstream is important? 
> > 
> > it's not. We just need to make sure all the 3.6 docs only have this
> > management network mentioned and not the old one.
> > 
> > > 
> > > Cheers,
> > > Julie
> 
> So if it's not important, why go through the engineering effort to make this
> change? As you see, this creates extra workload for the docs team as well. I
> will create a docs bug for this. Ideally, if Engineering or the PM team see
> there is docs impact, a docs bug should be created already.

It reduces upstream to downstream diff. This is engineering over head reduction.
Also for the docs team once all the docs are upstream as well.

> 
> Cheers,
> Julie
Comment 10 errata-xmlrpc 2016-03-09 16:00:26 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html

Note You need to log in before you can comment on or make changes to this bug.