<div dir="ltr">Igor,<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-15 13:14 GMT+03:00 Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Vitaly,<br>
<br>
I agree that having a lot of logic (receiving auth token, creating<br>
payload and doing post request) in RPM post_install section is a huge<br>
overhead, and definitely it's not a way to go. We have to find better<br>
solution, and I think it should be done declaratively (via some YAML).<br>
<br>
Moreover, I'd like to see the same approach for cluster's dashboard. I<br>
see no reason why YAML + custom formatting wouldn't be enough.<br></blockquote><div><br></div><div>Cluster-level links building logic is more complex in case of absolute url: the dashboards can be located on a separate IP or VIP in case of multiple nodes, it may use HTTPS or not and this may depend on the plugins settings and/or number of nodes, etc. If we could cover all the cases by YAML description, that would be perfect, but I don't think that's possible.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- Igor<br>
<div><div class="h5"><br>
On Tue, Dec 15, 2015 at 11:53 AM, Vitaly Kramskikh<br>
<<a href="mailto:vkramskikh@mirantis.com">vkramskikh@mirantis.com</a>> wrote:<br>
> Hi,<br>
><br>
> As you may know, in Fuel 8.0 we've implemented blueprint<br>
> external-dashboard-links-in-fuel-dashboard. It will allow plugins to add<br>
> links to their dashboards to the Fuel UI after deployment. As link<br>
> construction logic could be rather complex (what IP should be used -<br>
> public_vip or a separate public IP, should HTTPS be used, etc), we decided<br>
> to create a new API handler with auth exepmtion for POST requests<br>
> (/api/clusters/:id/plugin_links), which should be used from post-deployment<br>
> tasks of plugins. Relative links (without a protocol and a hostname) are<br>
> treated relative to public_vip (or SSL hostname in case of enabled SSL for<br>
> Horizon). Here are the examples of such post-deployment tasks: for absolute<br>
> url and for relative url. For me this approach was designed during 7.0<br>
> development cycle and looks fine to me and some other python developers.<br>
><br>
> But by the end of the development cycle the we figured out that we also need<br>
> to cover the case for plugins which install their dashboard on the master<br>
> node. We decided to go with the same approach and add same API handler for<br>
> plugins (/api/plugins/:id/plugin_links), but without auth exemption. It<br>
> should be used from post_install.sh script to create links. But the logic of<br>
> the script appeared to be pretty complex:<br>
><br>
> It needs to fork (as post_install is run before the plugin registration<br>
> process)<br>
> It needs to extract login/password from /etc/fuel/astute.yaml to access API<br>
> (so in case they are outdated this approach won't work; it won't also be<br>
> possible to request actual credentials from the user as it's a fork)<br>
> It needs to obtain a new Keystone token<br>
> Using this token, it should poll /api/plugins and look for the plugin with<br>
> the needed name until it appears (after registration process)<br>
> After the plugin is registered, script should construct a url using the<br>
> found id and send a POST request to add a link.<br>
><br>
> Registering a plugin-level link shouldn't be that complex and we need to<br>
> think for a better approach. Do you have any ideas?<br>
><br>
> I have one: unlike cluster-level links, plugin-level links don't need custom<br>
> construction logic as they are always relative to the master node IP and use<br>
> the same protocol, so that they can be specified in plugin metadata. We also<br>
> can use metadata describe cluster-level links in 2 most frequent cases:<br>
> relative to public_vips (Horizon plugins case) and for plugins which provide<br>
> only one role with public_ip_required=true and limits.max=1 (monitoring<br>
> solutions case). For more complex cases plugins will still use the API to<br>
> create the links manually.<br>
><br>
><br>
> --<br>
> Vitaly Kramskikh,<br>
> Fuel UI Tech Lead,<br>
> Mirantis, Inc.<br>
><br>
</div></div>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><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>