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.
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.
Also Yaniv, how does this fit on a Hosted engine deployment upgraded from 3.5 to 3.6?
(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.
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.
Hi Yaniv, Could you provide some context on why reducing the difference between upstream and downstream is important? Cheers, Julie
(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
(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
(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
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