Open Stack

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
<vkramskikh at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>