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. Customers would like to have automated director deployments and we should provide a set of ansible roles that allow customers, consultants, etc to be able to automate their environment setups. These roles should be the basic wrappers around tripleo related actions which can be used to construct customer specific playbooks. It is a tracking bug for packaging. Other RFE bugs are filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1971005
Why are we filing a RFE so far along into 16.2?
(In reply to Yaniv Kaul from comment #2) > Why are we filing a RFE so far along into 16.2? The RFE was filed to get it included into the RHOS 16.2 release.
(In reply to Chandan Kumar from comment #3) > (In reply to Yaniv Kaul from comment #2) > > Why are we filing a RFE so far along into 16.2? > > The RFE was filed to get it included into the RHOS 16.2 release. I understand why, I don't understand why so late in the process - what have we missed earlier? And since https://bugzilla.redhat.com/show_bug.cgi?id=1971005 is also stuck in NEW without all acks, seems quite late the whole thing to me (but perhaps I'm missing context!)
(In reply to Yaniv Kaul from comment #4) > (In reply to Chandan Kumar from comment #3) > > (In reply to Yaniv Kaul from comment #2) > > > Why are we filing a RFE so far along into 16.2? > > > > The RFE was filed to get it included into the RHOS 16.2 release. > > I understand why, I don't understand why so late in the process - what have > we missed earlier? And since > https://bugzilla.redhat.com/show_bug.cgi?id=1971005 is also stuck in NEW > without all acks, seems quite late the whole thing to me (but perhaps I'm > missing context!) Let me try to help w/ context... tripleo-operator-ansible provides a supported standard interface to tripleo for folks running openstack/tripleo cli comands from ansible. The target release for this feature has always been osp-17. The primary goal of tripleo-operator-ansible is to provide a stable interface to ansible to reduce errors in the deployment caused by providing incorrect or outdated cli options via ansible. This feature is not the current documented deployment for OSP, but can be helpful for consultants and customers, developers and testers. It is in use by Red Hat field consultants, and multiple ansible toolsets that automate the deployment steps of tripleo/osp. This tool can be helpful to operators using ansible, but is no way required. By adding this tool to 16.2 we can lower the barrier to it's adoption where only rpms and not source can be used. An example.. Operator named Jane: Jane is an OSP deployer and has written her own tools in ansible to automate OSP Jane has an ansible playbook or role that captures deployment failures from a deployment Red Hat updates the tripleo debug command across a release and now Jane's tooling is broken. A standard interface to ansible can help.. https://github.com/openstack/tripleo-operator-ansible/tree/master/roles/tripleo_overcloud_failures By using tripleo-operator-ansible the scenario changes a bit.. Jane has ansible tooling to deploy that uses tripleo-ansible-operator Red Hat updates the tripleo cli debug command. Red Hat updates the tripleo-ansible-operator to account for the change. Jane's tooling continues to work and no changes are required. Documentation is here: https://docs.openstack.org/tripleo-operator-ansible/latest/ Initial socialization started back in 2019 via email, meetings, openstack ptg etc. https://mailman-int.corp.redhat.com/archives/rh-openstack-dev/2019-November/msg00163.html https://docs.google.com/presentation/d/1qpLABzoVpOTP4QaXkbjh5OZ1rqcNne5PZVTFUq0i1Mk/edit#slide=id.p3 Why is this RFE coming in now to 16.2? Simply to lower the barrier to entry, allow the same ansible tooling to be used across osp16/17.. etc. Prevent tooling forks from 16 -> 17 if one desires that. Hope this helps provide the context.