Description of problem: Ansible 2.2 and 2.3 got a host of modules that depend on ovirt 4 SDK but the package providing it is not included in Fedora proper. This is unfriendly to users who are forced to add external repos to their machines or run ansible playbooks on engine. Version-Release number of selected component (if applicable): fedora and epel currently only include 3.x sdk (ovirt-engine-sdk-python.noarch) python-ovirt-engine-sdk4 is only available in ovirt repos How reproducible: always Steps to Reproduce: 1. run ovirt_auth playbook on host with just fedora or el7+EPEL packages 2. 3. Actual results: fatal: [${host}]: FAILED! => {"changed": false, "failed": true, "msg": "ovirtsdk4 version 4.0.0 or higher is required for this module"} Expected results: ovirt_* modules in ansible work right after ansible installation Additional info:
Ansible playbook is not usually executed on the server where Ansible is installed (although it's possible), but on the destination host, which needs to have available all required dependencies. Here are use cases: 1. Upstream oVirt/Ansible - Using pip is a standard way in Ansible how to resolve dependencies - So you can run you playbook on following destination hosts: a. engine host (preferred way) - this host already contains all necessary RPM repositories b. different host - you can install dependencies using pip (preferred way by Ansible) or install RPM using oVirt repositories 2. Downstream RHV/Ansible - EPEL is not supported option on downstream - Preferred way is to execute Ansible playbooks on engine hosts, which already contain requires subscriptions/channels Not to mention that maintaining Python SDK in Fedora and/or EPEL would require significant effort, which can be spent more effectively elsewhere. Due to the above closing as WONTFIX
(In reply to Martin Perina from comment #1) > Ansible playbook is not usually executed on the server where Ansible is > installed (although it's possible), but on the destination host, which needs > to have available all required dependencies. This works for use cases that require Administration Portal access in no-automation scenario, but it's not wise to grant shell access to engine machine to anybody who may want to automate their VMs lifecycle (analogous to accounts with access to the User Portal). That's why i called this approach "workaround" in #c0. > Here are use cases: > > 1. Upstream oVirt/Ansible > - Using pip is a standard way in Ansible how to resolve dependencies > - So you can run you playbook on following destination hosts: > a. engine host (preferred way) > - this host already contains all necessary RPM repositories > b. different host > - you can install dependencies using pip (preferred way by > Ansible) or install RPM using oVirt repositories > > > 2. Downstream RHV/Ansible > - EPEL is not supported option on downstream > - Preferred way is to execute Ansible playbooks on engine hosts, which > already contain requires subscriptions/channels That doesn't provide complete support, we're still forcing users to choose from: * insecure setup (non-admin users having shell access to engine) * installing packages from engine-specific channel elsewhere (may violate support agreements but IANAL) * doing custom builds of packages that we could provide in generic channel This issue also sort-of applies to guest agent as well which is also worked around by having it in ovirt-specific channel and EPEL. If these objections persuade you to reevaluate, please reopen this bug yourself. I don't mind if you keep this on back burner for some time but the issue is IMO real. > > Not to mention that maintaining Python SDK in Fedora and/or EPEL would > require significant effort, which can be spent more effectively elsewhere. > > Due to the above closing as WONTFIX