Open Stack

Igor,

2015-12-15 13:14 GMT+03:00 Igor Kalnitsky <ikalnitsky at 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
> <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
> >
>
> __________________________________________________________________________
> 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
>



-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151215/a27dfacc/attachment.html>