Support for version 4 of oVirt engine

[jhernand]

Currently the gem used by ManageIQ to connect ot oVirt or RHEV-M uses a hard-coded URL:

https://engine.example.com/api

The path of this URL, /api, has been used in oVirt since version 3.0. In version 3.5 of the engine that URL has been deprecated, and replaced by /ovirt-engine/api. The old \api URL has been preserved, for backwards compatibility, but it will be removed in version 4 of the engine.

In addition, version 4 of the engine will support two versions of the API:

• Version 3 of the API, identical to the one available now in version 3.6 of the engine.
• Version 4 of the API, different and not compatible with the one available now in version 3.6 of the engine.

Clients that need to work with version 4 of the engine can select the version of the API that they want to use. If they don't, then they will use version 4 by default. There are two mechanisms to select the version of the API:

• A URL prefix: /ovirt-engine/api/v3 or /ovirt-engine/api/v4. This is not recommended, as it doesn't work with old versions of the engine, like 3.6.
• An HTTP header: Version: 3. This is the recommended mechanism, as old versions of the engine (3.6 and older) will just ignore the header and new versions of the engine (4.0 and newer) will honor it.

These two changes together (the new /ovirt-engine/api path and the multiple versions support) mean that the ovirt gem and/or ManageIQ need to be modified in order to work correctly with version 4 of the engine. There are several approaches:

1. Modify the ovirt gem so that it always sends the Version: 3 header, and so that it detects the correct path. That is what is proposed in pull request Add support for version 4 of the engine ovirt#48. The second part of this pull request, detecting the path, isn't needed if the oVirt support is restricted to version 3.5 or newer.
2. Modify the ManageIQ web interface (for oVirt at least) so that it has a drop down where the user can select the version of the API to use, and modify the ovirt gem so that it uses the value of that drop down to build the correct URL. That is what is proposed by pull requests api_uri - oVirt API v4 moved to /ovirt-engine/api ovirt#47 for the ovirt gem and pull request [WIP] rhevm provider - add an 'API version' select-box in UI #7127 for ManageIQ. This builds the correct URL, but doesn't tell the server what version of the API to use.
3. Modify ManageIQ web interface so to support a complete URL instead of just a host name and port. This way the user can type something like https://engine.example.com/ovirt-engine/api/v3, which would out of the box without any additional modification. This URL field could be par of an advanced section, and hidden by default. It could also be populated automatically from the host and port number, and then shown to the user so that she can accept it or do some additional changes.
4. Add to ManageIQ a new provider for oVirt 4, so that the user only has to select it from the existing drop down. The new provider can then build the URL correctly, and send the required Version header.

One of these approaches needs to be selected and implemented in order to support oVirt 4.

[jhernand]

@masayag, @oourfali, @danielerez, @blomquisg

[Fryguy]

I think this issue needs to be opened in the https://github.com/ManageIQ/ovirt repo since that's the library we use.

Or is this saying, "given these changes made in the ovirt gem, here's what needs to change in ManageIQ".

EDIT: I didn't see the links in the OP. Normally we use GitHub's automatic linking for remote repos and it full qualifies the links...I changed the OP accordingly

[Fryguy]

I think the first thing to check is whether or not we need to support oVirt < 3.3 as @bdunne mentioned in ManageIQ/ovirt#47 (comment). If we can drop that, then the simple answer is to always hit /ovirt-engine/api

Otherwise, I think number 2 is the best approach, for now. I'm not sure the user cares what underlying API is used as long as the data comes back, so, the ovirt gem can also not care. Of course this changes if we need to actually use anything that is only in the v4 API and not in the v3 API, but then in that case that one class in the ovirt gem can talk v4 under the covers, so again the caller doesn't care.

Another similar option, which might be nicer for the end-user, is to just autodetect the version. Try to hit v4, and if it 404s, then try v3. The autodetection code would live as a helper method in the ovirt gem, but called on the manageiq side at provider creation (or perhaps at credential validation time), and stored in the ext_management_system's api_version column. Then, subsequent calls would pass the autodetected version number to the ovirt gem on connect.

[jhernand]

The ovirt gem can't work with version 4 of the API: authentication is different, names of certain attributes are different, some types have been removed, etc. If it is modified to support these changes, then it won't work with version 3 of the API. To make it work with versions 3 and 4 it would need to be full of if version == 3 then ... else ....

[Fryguy]

@jhernand I'm not sure that's a problem, really, but I don't think we should add it until we need specific features. We already have a little bit of that already (example) cc @bdunne

[gregsheremeta]

@gregsheremeta

[necarnot]

Hello,

Does all this mean that ManageIQ version '*' + oVirt 4.y.z is not working so far?

[jhernand]

No, the issues with oVirt 4 have been addressed. I am closing this issue.