Re: [openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

[Vitaly Kramskikh]

Igor,

2015-12-15 13:14 GMT+03:00 Igor Kalnitsky :

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

Re: [openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

[Igor Kalnitsky]

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

[openstack-dev] [Fuel] [Plugins] Ways to improve plugin links handling in 9.0

[Vitaly Kramskikh]

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