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