This is critical to existing customers looking to upgrade to 3.6. Made this request more general to allow engineering to suggest any design that will allow this.

(In reply to Yaniv Dary from comment #4)
> This is critical to existing customers looking to upgrade to 3.6. Made this
> request more general to allow engineering to suggest any design that will
> allow this.

in 3.5 we decided that the way to upgrade is via a new cluster and cross-cluster one way migration.
How could this be critical?

(In reply to Michal Skrivanek from comment #5)
> How could this be critical?

The current approach implies:
- creating a new additional cluster for each already existing cluster.
- configuring each new cluster with the same settings (memory optimization, cluster policy, etc) as in the corresponding "old" cluster.
- apply the same permissions to the new clusters as in the old clusters.

Some customers have hundreds of clusters.

(In reply to Julio Entrena Perez from comment #6)
> (In reply to Michal Skrivanek from comment #5)
> > How could this be critical?
> 
> The current approach implies:
> - creating a new additional cluster for each already existing cluster.

not for each, it can be only one new cluster for the duration of conversion.
And since you anyway don't want to keep the empty old cluster around once all hosts from that cluster are upgraded, you can move hosts back to the original cluster (once all el6 hosts are gone, the first el7 host added will make it a el7 cluster)

> - configuring each new cluster with the same settings (memory optimization,
> cluster policy, etc) as in the corresponding "old" cluster.

for the conversion, yes, it indeed should be the same....but it depends on the scale. When the upgrade is fast (small environment, few hosts in cluster) you may not need 1:1 functionality, especially when you don't have extra set of hosts you will be running in degraded mode anyway (some hosts old, some new - without a way how to load-balance the load)

> - apply the same permissions to the new clusters as in the old clusters.
> 
> Some customers have hundreds of clusters.

then it really depends on strategy of the upgrade. small cluster would imply just few hosts in each, so you anyway need to upgrade carefully one by one with respect to the load.

State of development can be followed on the feature page:

http://www.ovirt.org/Features/InClusterUpgrade#InClusterUpgrade

Wiki page is now at www.ovirt.org/feature/inclusterupgrade

Hi Jullie,

This important process should go into the user-guide I believe. We have this wiki from comment 21 to start from. Let me know of any think you need.

Thanks

Hi Roy,
 We have a docs bug to track this change (BZ#1301447). It should affect the standard upgrade procedure in the Upgrade Guide[1] and the self-hosted engine upgrade procedure in the SHE Guide[2].

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Upgrade_Guide/Upgrading_a_Red_Hat_Enterprise_Linux_6_Cluster_to_Red_Hat_Enterprise_Linux_7.html
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Self-Hosted_Engine_Guide/Upgrading_the_Self-Hosted_Engine_from_6_to_7.html

Kind regards,
Julie

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Verified on rhevm-3.6.6-0.1.el6.noarch
See polarion run: https://polarion.engineering.redhat.com/polarion/#/project/RHEVM3/testrun?id=3%5F6%5FSLA%5FIn%5FCluster%5FUpgrade%5Frun%5F1

Please clone bug or fix flags.