Bug 1917409 - [RFE] Provide Ansible Engine within RHV channels
Summary: [RFE] Provide Ansible Engine within RHV channels
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ansible
Version: 4.4.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.4.5
: 4.4.5
Assignee: Martin Perina
QA Contact: Pavol Brilla
URL:
Whiteboard:
Depends On:
Blocks: 1923169
TreeView+ depends on / blocked
 
Reported: 2021-01-18 12:58 UTC by Martin Perina
Modified: 2021-04-14 11:41 UTC (History)
7 users (show)

Fixed In Version: ansible-2.9.17-1.el8ae, ansible-2.9.17-1.el8ae
Doc Type: Release Note
Doc Text:
Red Hat Virtualization (RHV) 4.4.5+ includes Ansible within its own channels. Therefore, the ansible-2.9-for-rhel-8-x86_64-rpms channel does not need to be enabled on either the RHV Manager or RHEL-H hosts. Customers upgrading from RHV releases 4.4.0 through 4.4.4 or 4.3.z, should remove that channel from their RHV Manager and RHEL-H hosts.
Clone Of:
Environment:
Last Closed: 2021-04-14 11:41:01 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5480561 0 None None None 2021-03-24 00:57:37 UTC
Red Hat Product Errata RHBA-2021:1185 0 None None None 2021-04-14 11:41:13 UTC

Description Martin Perina 2021-01-18 12:58:29 UTC
Only specific version of Ansible is properly tested with specific RHV version and to prevent breakages of already released RHV we have introduced a version lock on specific Ansible release. But this caused an issue during upgrades which needed to be mitigated by KCS https://access.redhat.com/solutions/5480561

From RHV 4.4.5 we are going to provide correct ansible version in RHV channel, so we will no longer need subscription to ansible-engine channel and there should no longer be version lock issues with newer version of ansible from this channel

Comment 4 Marina Kalinin 2021-03-26 21:30:11 UTC
Hi Martin / Didi,
Do we have a question/warning during engine-setup that the user should remove external ansible channels to avoid conflicts?
If not, can we please add this? 
I know we are late in the game, but it is important. And it can be just a note at the end of the setup, so that should not add load to QE.

Comment 5 Martin Perina 2021-03-29 07:30:36 UTC
(In reply to Marina Kalinin from comment #4)
> Hi Martin / Didi,
> Do we have a question/warning during engine-setup that the user should
> remove external ansible channels to avoid conflicts?

No, we don't

> If not, can we please add this? 

Definitely not in 4.4.5. The problem is complex, we can't rely on channel names (they can be completely different on Satellite setup).
Not to mention, that this detection and error reporting would need to be done not only in engine-setup, but also in hosted-engine-setup and host-deploy, so quite complex solution.

> I know we are late in the game, but it is important. And it can be just a
> note at the end of the setup, so that should not add load to QE.

As mentioned above, the correct solution would mean a change in engine-setup, hosted-engine-setup and host-deploy, so too complex change. If we agree that this is really needed, we need a new bug for that targeted to 4.4.6

Comment 7 Yedidyah Bar David 2021-04-04 08:45:15 UTC
(In reply to Marina Kalinin from comment #4)
> Hi Martin / Didi,
> Do we have a question/warning during engine-setup that the user should
> remove external ansible channels to avoid conflicts?
> If not, can we please add this? 
> I know we are late in the game, but it is important. And it can be just a
> note at the end of the setup, so that should not add load to QE.

In addition to comment 5, can you please clarify why this is important?

In both ovirt-engine and ovirt-hosted-engine-setup packages, we require exactly ansible 2.9.17.

(That's for RHV. oVirt's ovirt-engine requires ansible >= 2.9.0, ansible < 2.10.0).

Does it matter if the user supplies this version of ansible using whatever possible means?

Worst case, a 'dnf install/upgrade' will fail due to a conflict, if a newer version is available. A fix for this should be '--nobest', IMO, or some more specific manual dnf configuration, if needed - not adding more complexity to the installation code. I might be missing something...

Comment 12 errata-xmlrpc 2021-04-14 11:41:01 UTC
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 (RHV Engine and Host Common Packages 4.4.z [ovirt-4.4.5]), 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-2021:1185


Note You need to log in before you can comment on or make changes to this bug.