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.
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.