Description of problem: In Victoria cycle we deliver integration of powerflex (formerly vxflex) with TripleO. https://review.opendev.org/#/c/724301/ It is delivered in out-of-tree repo https://github.com/dell/tripleo-powerflex. The code is ready and had been reviewed partially. We can do release of it when RH is ready. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Rajini, please, check if any other patches also need to be included. I think that all other TripleO patches are already have BZs and are targeted for z2.
Expect that we can land it in z3 so we can release it by year end.
The first step to get the package in OSP is to add it to RDO. Please follow the process show in: https://www.rdoproject.org/documentation/add-packages/#how-to-add-a-new-openstack-package-to-rdo-trunk
Thanks Alfredo. Adding Chris to guide us to follow what wad done for out of tree python-drac-client repo for https://github.com/dell/tripleo-powerflex.
(In reply to arkady kanevsky from comment #1) > Rajini, > please, check if any other patches also need to be included. > I think that all other TripleO patches are already have BZs and are targeted > for z2. Yes, all patches needed are targeted for Z2
https://bugzilla.redhat.com/show_bug.cgi?id=1877881 - RDO Package Review BZ
Can we get a drop release candidate of z3 with this BZ in it to test before GA?
Two questions: - Who'll be in charge of maintaining this repo and push any future release? - How is the release model of this kind of RDO repository?
I confirmed ansible-tripleo-powerflex-0.0.1-1.20201118113650.66f52a0.el8ost.noarch.rpm is available in OSP-16.1 composes starting with RHOS-16.1-RHEL-8-20201124.n.0. The Dell EMC team should have access via DCI. As for JP's questions in comment #12, the package will now follow the same workflow as the rest of the OSP packages. Generally speaking, package updates will flow into OSP via RDO. It will be Dell EMC's responsibility for maintaining things in RDO, which means submitting RDO patches to get updates you make into RDO. From there, the RDO updates will flow down into OSP. I think this means Dell EMC will need to "cut a release" (bump the semantic version), then submit a patch to RDO to adopt the new version in the appropriate RDO release(s). We also have the ability to handle downstream updates, but the usual rules apply (patches must be "upstream first").
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 (Red Hat OpenStack Platform 16.1.3 bug fix and enhancement 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/RHEA-2020:5413