ceph-ansible 4.0.14 refuses to work with ansible 2.9, which is the latest version found for centos8 when deploying rdo
Please specify the severity of this bug. Severity is defined here: https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity.
This is a CentOS 8 issue not a ceph-ansible issue. > ansible 2.9, which is the latest version found for centos8 when deploying rdo Because you're using EPEL 8 which provides this ansible package. The EPEL ansible package is always bumped to a recent major ansible release and there's no versionning. This package was based on 2.8 few weeks ago. So you can't pin on a previous version. If ansible 2.10 is out tomorrow then the EPEL ansible package will also be updated. Will you then asking us to update to 2.10 ?
Giulio, we don't understand the exact implications to the products downstream. Would you please say how this bug impacts OpenStack 16? and OpenStack 17?
(In reply to Ken Dreyer (Red Hat) from comment #3) > Giulio, we don't understand the exact implications to the products > downstream. > > Would you please say how this bug impacts OpenStack 16? and OpenStack 17? This impacts OSP16. As tracked in bz1807145, inevitably OSP16 will move to Ansible 2.9 because Ansible live cycles tend to be shorter than OpenStack life cycles and OSP16 is a five-year release. OSP16/RHCSv4 need to continue their joint support.
(In reply to Dimitri Savineau from comment #2) > This is a CentOS 8 issue not a ceph-ansible issue. > > > ansible 2.9, which is the latest version found for centos8 when deploying rdo > > Because you're using EPEL 8 which provides this ansible package. > > The EPEL ansible package is always bumped to a recent major ansible release > and there's no versionning. This package was based on 2.8 few weeks ago. So > you can't pin on a previous version. > > If ansible 2.10 is out tomorrow then the EPEL ansible package will also be > updated. Will you then asking us to update to 2.10 ? RDO doesn't use EPEL at all, but maintain its own builds of ansible in CloudSIG repository, i.e.: https://cbs.centos.org/koji/buildinfo?buildID=28297 In this particular case, for CentOS8 bootstrap we built 2.9 which was last upstream release (2.9 was released on 2019-10-31) for the OpenStack version under development (Ussuri). Using latest upstream version of dependencies in the development phase is the recommended practice in OpenStack ecosystem. Note that, in the case of OpenStack, Ceph is integrated in a wider set of projects and tecnologies that need to be coinstalled and live together so cooperation between all involved parts to define the versions of ansible (the same may apply to others, although i think ansible is the most critical one) is needed. Typically, supporting new versions of ansible with backwards compatibility at some level has been very helpful as a way to provide flexibility in the integration, although i understand there can be several ways this can be achieved and discussing the best way for all parties is fair. Also note that according to https://access.redhat.com/support/policy/updates/ansible-engine, EOL 2.8 EOL is "After the release of Ansible Engine 2.11 - Approx. 8-12 months after GA" (May 21, 2019). At this point, I'm flexible with moving back to ansible 2.8 in RDO for CentOS8 if TripleO is fine with it.
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/RHSA-2020:2231