Open Stack

Hi,

As you may know, in Fuel 8.0 we've implemented blueprint
external-dashboard-links-in-fuel-dashboard
<https://blueprints.launchpad.net/fuel/+spec/external-dashboard-links-in-fuel-dashboard>.
It will allow plugins to add links to their dashboards to the Fuel UI after
deployment. As link construction logic could be rather complex (what IP
should be used - public_vip or a separate public IP, should HTTPS be used,
etc), we decided to create a new API handler with auth exepmtion for POST
requests (/api/clusters/:id/plugin_links), which should be used from
post-deployment tasks of plugins. Relative links (without a protocol and a
hostname) are treated relative to public_vip (or SSL hostname in case of
enabled SSL for Horizon). Here are the examples of such post-deployment
tasks: for absolute url
<https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/absolute-dashboard-link.pp>
and for relative url
<https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/relative-dashboard-link.pp>.
For me this approach was designed during 7.0 development cycle and looks
fine to me and some other python developers.

But by the end of the development cycle the we figured out that we also
need to cover the case for plugins which install their dashboard on the
master node. We decided to go with the same approach and add same API
handler for plugins (/api/plugins/:id/plugin_links), but without auth
exemption. It should be used from post_install.sh script to create links.
But the logic of the script appeared to be pretty complex
<https://review.openstack.org/#/c/251881/12/examples/fuel_plugin_example_v4/post_install.sh>
:

   - It needs to fork (as post_install is run before the plugin
   registration process)
   - It needs to extract login/password from /etc/fuel/astute.yaml to
   access API (so in case they are outdated this approach won't work; it won't
   also be possible to request actual credentials from the user as it's a fork)
   - It needs to obtain a new Keystone token
   - Using this token, it should poll /api/plugins and look for the plugin
   with the needed name until it appears (after registration process)
   - After the plugin is registered, script should construct a url using
   the found id and send a POST request to add a link.

Registering a plugin-level link shouldn't be that complex and we need to
think for a better approach. Do you have any ideas?

I have one: unlike cluster-level links, plugin-level links don't need
custom construction logic as they are always relative to the master node IP
and use the same protocol, so that they can be specified in plugin
metadata. We also can use metadata describe cluster-level links in 2 most
frequent cases: relative to public_vips (Horizon plugins case) and for
plugins which provide only one role with public_ip_required=true and
limits.max=1 (monitoring solutions case). For more complex cases plugins
will still use the API to create the links manually.

-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151215/9c1c00d0/attachment.html>