BACKGROUND Work toward ovirt-engine product to be more administrator's user friendly. CURRENT IMPLEMENTATION We assume that we are the only application installed on the host, we hijack the root URI for our use. This reduce the ability of administrator to share the web configuration with other products. We already are in better shape, as per ovirt-engine-3.3 we intercept only our own URIs, but these are too generic, and creates a complex apache configuration. SUGGESTED IMPLEMENTATION Move all our resources into /ovirt-engine URI namespace. Caveats: The following must remain at root as part of ovirt-node-interface, but should be also available under /ovirt-engine/ to allow migration path. - /engine.ssh.key.txt - /rhevm.ssh.key.txt - /ca.crt The following will be redirected by apache: /api -> /ovirt-engine/api So applications will be able to use /api for legacy and /ovirt-engine/api I also suggest to have shortcuts for redirection for future compatibility of user's bookmarks /ovirt-engine/userportal -> <whatever> /ovirt-engine/admin -> <whatever> While we at it, if we can split the static content and dynamic content URI namespaces it will help us to split the application or cache the content. /ovirt-engine/<application/static/xxx /ovirt-engine/<application/dynamic/xxx BACKWARD COMPATIBILITY Only if absolutely required! I don't think so. We install a redirection within apache as a separate configuration during upgrade to redirect the old URIs into the new. This will not be installed when installing from scratch.
oVirt 3.4.0 alpha has been released including the fix for this issue.
Verified on ovirt-3.4.0-beta3 Re-direct from /api to /ovirt-engine/api is checked in all automation testing intrinsically. added basic Test Plan for sanity and change effect on ovirt-node host registration will be implemented on ovirt-node testing.
This is an automated message: moving to Closed CURRENT_RELEASE since oVirt 3.4.0 has been released.