Description of problem: Backport these to RHOSP 16.1 Here is the list of features for VxFlex OS cinder driver: • Add support for VxFlex OS 3.5 to VxFlex OS driver: https://review.opendev.org/#/c/705176 • Add OpenStack volume replication v2.1 support in VxFlex OS driver: https://review.opendev.org/#/c/707390 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Two more to backport.. Add support for volume migration in VxFlex OS driver - https://review.opendev.org/#/c/711624/ Add revert to snapshot support in VxFlex OS driver - https://review.opendev.org/#/c/712622/
All the changes seems to be driver specific. Given their size and impact, it is unlikely they are going to be backported upstream.
Everything has been merged upstream in USSURI. Can we start the backports?
Hi Rajini, the backports can start. As you are no doubt aware, these will be downstream backports. Pablo @pcaruana will help, please coordinate with him and Alan @abishop.
Thanks John
Hi, I have done cherry-picks for each patch. https://review.opendev.org/#/c/723825/1 https://review.opendev.org/#/c/723826/1 https://review.opendev.org/#/c/723827/1 https://review.opendev.org/#/c/723828/1
Thanks, Ivan. Even if the upstream community rejects the patches on stable/train, we are working on downstream backports for osp-16.1
The blueprint for vxflexos tripleo integration is https://review.opendev.org/#/c/724301/
Looks like these patches are already merged downstream What is expected of the upstream patches on the stable/train? Should we abandon them? if so when? https://review.opendev.org/#/c/723825 https://review.opendev.org/#/c/723826 https://review.opendev.org/#/c/723827 https://review.opendev.org/#/c/723828
If the patches can be backported upstream then they should be backported upstream. Reducing the number of downstream patches really helps minimize the complexity of maintaining a long term OSP release. The next step is to see what the stable core team feels about backporting them to a stable branch, so maybe ping them on irc (or this might be a good virtual hallway discussion during next week's PTG). The fact that the DellEMC_VxFlexOS CI jobs are all passing is encouraging. If the first patch n the sequence is rejected then you can immediately abandon the others. @Derek, as Pablo noted this is a FeatureBackport. In this instance, this BZ *is* the RFE, and the scope is limited to the Dell EMC cinder driver. We don't require (or want) a separate BZ per patch when the patches represent a single functional set.
The upstream backports have been rejected for all the reviews, we cannot go upstream route. Can you please proceed with the downstream backporting?
(In reply to Vladislav Belogrudov from comment #18) > The upstream backports have been rejected for all the reviews, we cannot go > upstream route. Can you please proceed with the downstream backporting? Hello Vladislav, not sure if you being aware, but Backports were perfomed already and current status is ON_QA. If everythings goes well and no regression detected, it would be included in openstack-cinder-15.1.1-0 package and laters when the errata being published. Regards, Pablo.
Thanks Pablo. I suggest we do 2 things: 1. deprecate all 4 upstream backports since they are no longer needed and they had been backported to 16. 2. change this BZ to 16.1 Thanks, Arkady
Will this be available in 16.0 zStream? or 16.1 GA?
(In reply to Rajini Karthik from comment #21) > Will this be available in 16.0 zStream? or 16.1 GA? Rajini, I expect this to be in the 16.1 GA and not in the 16.0 Z-stream. Is it needed there?
Can we get confirmation this is in 16.1 RC can can be tested by Dell-EMC?
(In reply to Paul Grist from comment #24) > Can we get confirmation this is in 16.1 RC can can be tested by Dell-EMC? I can confirm there are in the 16.1 RC.
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://access.redhat.com/errata/RHBA-2020:3148