# tripleo-operator-ansible exception request

## Info
https://docs.engineering.redhat.com/display/PRODCHAIN/Exception+Policy+and+Procedure

## Email

OSP-16.2 BZ Exception request - https://bugzilla.redhat.com/show_bug.cgi?id=1975737

Hello,

I would like to request an exception for the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1975737
Summary:
tripleo-operator-ansible[0] contains an ansible collection of TripleO roles. This collection contains a set of roles providing an ansible interface for the TripleO cli actions.
It is used in Production Chain upstream and downstream promotion CI via tripleo-quickstart for deploying tripleO.
Currently it is installed via pip, which causes issues in CI due to mixing of pip and rpm packages. 
we are working to installing it via RPM.

But, The rpm package is only available for RHOS-17 [0]only, we need to build it for RHOS-16.2 also so that we can consume in Downstream CI.

Links:
[0] https://code.engineering.redhat.com/gerrit/plugins/gitiles/ospinfo/+/refs/heads/master/packages.yml#710

What is the business rationale for this exception? 
In order to avoid issues coming from mixing of pip and RPM in the production chain downstream CI, we need to package and
install it via RPM.

Is there a specific customer that needs this RFE?
No

Are there any security concerns?  Has Product Security been informed ([e-mail])?
No

What other functions, teams, or DFGs are impacted by this feature?
No one

What is the estimated time to have the upstream work complete and approved?

Package is already available for train in RDO as well as for RHOS-17.
We need to cross-tag it for RHOS-16.2 and make sure it is getting built by Downstream DLRN so that we can consume it in downstream CI.

What is the time and resources required to test this issue? On what date will automated tests be written and ready to run and report results in Polarion?
Once the package will be available for RHOS-16.2, on this patch https://review.opendev.org/c/openstack/tripleo-quickstart/+/790701 downstream CI passes, we are good to land
it.

Is there potential doc impact? If yes, has your doc team point of contact agreed that docs have the capacity to complete the required work?
No

Are there new packages needed that are not packaged in OSP or RHEL?  Does it require newer versions of existing dependencies (dependency bumps)?
It is already packaged for OSP-17.0, we need to cross-tag or rebuild it for RHOS-16.2.

What is the support level? Tech Preview or fully supported
Tech preview or no support (As we need it for downstream CI only), It is already going to be shipped for RHOS-17.0

How invasive is the code?  From very invasive, a core change to very isolated, no risk to other components?
No risk to other components

What is the impact to deployment/updates/upgrades/FFU; what are the test plans in these areas?
No impact

Thanks,

Chandan Kumar