Igor, 2015-12-15 13:14 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>:
> Hey Vitaly, > > I agree that having a lot of logic (receiving auth token, creating > payload and doing post request) in RPM post_install section is a huge > overhead, and definitely it's not a way to go. We have to find better > solution, and I think it should be done declaratively (via some YAML). > > Moreover, I'd like to see the same approach for cluster's dashboard. I > see no reason why YAML + custom formatting wouldn't be enough. > 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. > > - Igor > > On Tue, Dec 15, 2015 at 11:53 AM, Vitaly Kramskikh > <vkramsk...@mirantis.com> wrote: > > Hi, > > > > As you may know, in Fuel 8.0 we've implemented blueprint > > 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 and for relative url. 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: > > > > 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. > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev