<div dir="ltr"><div><div>Hi,<br><br></div>As you may know, in Fuel 8.0 we've implemented blueprint <a href="https://blueprints.launchpad.net/fuel/+spec/external-dashboard-links-in-fuel-dashboard">external-dashboard-links-in-fuel-dashboard</a>. 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: <a href="https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/absolute-dashboard-link.pp">for absolute url</a> and <a href="https://review.openstack.org/#/c/251472/11/examples/fuel_plugin_example_v4/deployment_scripts/relative-dashboard-link.pp">for relative url</a>. For me this approach was designed during 7.0 development cycle and looks fine to me and some other python developers.<br><br></div><div>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 <a href="https://review.openstack.org/#/c/251881/12/examples/fuel_plugin_example_v4/post_install.sh">pretty complex</a>:<br><ul><li>It needs to fork (as post_install is run before the plugin registration process)<br></li><li> It needs to extract login/password from <span class="">/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)</span></li><li><span class="">It needs to obtain a new Keystone token</span></li><li><span class="">Using this token, it should poll /api/plugins and look for the plugin with the needed name until it appears (after registration process)</span></li><li><span class="">After the plugin is registered, script should construct a url using the found id and send a POST request to add a link.</span></li></ul><p>Registering a plugin-level link shouldn't be that complex and we need to think for a better approach. Do you have any ideas?</p><p>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 <span class=""><span class=""></span><span class="">public_ip_required=</span></span><span class=""><span class="">tru</span></span><span class=""><span class="">e and limits.max=1 (monitoring solutions case). For more complex cases plugins will still use the API to create the links manually.<br></span></span></p></div><div><div><div><br>-- <br><div><div dir="ltr"><div><div dir="ltr">Vitaly Kramskikh,<br>Fuel UI Tech Lead,<br>Mirantis, Inc.</div></div></div></div>
</div></div></div></div>