Bug 1419554 - Please add python-ovirt-engine-sdk4 to Fedora (and EPEL) to make ansible ovirt_* modules work out-of-the-box
Summary: Please add python-ovirt-engine-sdk4 to Fedora (and EPEL) to make ansible ovir...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine-sdk-python
Classification: oVirt
Component: Packaging.rpm
Version: 4.1.0a
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
: ---
Assignee: Ondra Machacek
QA Contact: Pavel Stehlik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 13:42 UTC by David Jaša
Modified: 2017-02-08 15:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-08 12:05:57 UTC
oVirt Team: Infra


Attachments (Terms of Use)

Description David Jaša 2017-02-06 13:42:53 UTC
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:

Comment 1 Martin Perina 2017-02-08 12:05:57 UTC
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

Comment 2 David Jaša 2017-02-08 15:26:01 UTC
(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


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