Description of problem:
From 3.6 customer will start moving production environment from el6 to el7 either via upgrade or reinstall. We need to enable adding el7 hosts in that situation and only allow VMs to migrate from el6 to el7 and not back. Then customer can start re-provisioning hosts and not need to create new cluster and move hosts that can be a risk to the VMs.
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:
Wiki page is now at www.ovirt.org/feature/inclusterupgrade
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.
We have a docs bug to track this change (BZ#1301447). It should affect the standard upgrade procedure in the Upgrade Guide and the self-hosted engine upgrade procedure in the SHE Guide.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see firstname.lastname@example.org 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.