Open Stack

Hi,

sorry for late reply. The whole "openstack_dashboard/local/enabled/"
mechanism was inspired by the mechanisms used commonly in Debian and other
distributions to enable/disable plugins. In short, you shouldn't *copy* the
configuration files to the "enabled" directory -- instead you should keep
them with the plugin, and only symlink them there when you actually want
the plugin to be enabled. There is no need for additional logic in the
plugin checking any environment variables and so on.

On Tue, Jul 5, 2016 at 7:57 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> I wrote the app-catalog-ui plugin. I was going to bring this up but hadn't
> gotten to it yet. Thanks for bringing it up.
>
> We do package it up in an rpm, so if its installed with the rest of the
> packages it should just work. The horizon compress/collect rpm hook does
> the right thing already. It does cause it to be enabled though, so I was
> thinking, maybe we make a docker environment variable ENABLED_PLUGINS that
> contains a list of plugins to be enabled?
>
> The value of ENABLED_PLUGINS could be written into
> /etc/openstack-dashboard/local-settings.d and the plugins could enable
> themselves based on it?
>
> I'd rather have the horizon container be bigger then needed and have all
> the plugins test/ready to go as needed instead of trying to slide the
> plugins in myself. Its kind of a pain.
>
> Thanks,
> Kevin
> ------------------------------
> *From:* Dave Walker [email at daviey.com]
> *Sent:* Sunday, July 03, 2016 1:15 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [kolla][horizon] Out of branch horizon plugins?
>
> Hi,
>
> Whilst writing a Kolla plugin, I noticed some issues with the way Horizon
> is configured in Kolla.
>
> Horizon is increasingly embracing a plugin architecture with UI's and
> Dashboards being maintained outside of Horizon's tree.
>
> These can be found with the type:horizon-plugin tag in
> openstack/governance [0], with 16 projects at current.
>
> This isn't really addressed in Kolla, and is a little awkward to integrate
> as the horizon docker image is pure horizon.
>
> Some projects have a tools/register_plugin.sh which performs the grunt
> work, where as others require a workflow similar to:
>
> cp /path/to/projects/new/panel openstack_dashboard/local/enabled/
> cp /path/to/local/defualt/settings
> openstack_dashboard/local/local_settings.d/
> cp /path/to/*policy.json openstack_dashboard/conf/
> # compress if environment wants it
> ./manage.py collectstatic
> ./manage.py compress
>
> (Separately, it would be nice if this was standardised.. but not the topic
> of this thread)
>
> It would seem logical to pack all of these into the horizon docker image,
> and add a symlink into dashboard/local/enabled via ansible, policy.json and
> default settings with some conditionals if enabled_$service... but this
> will make the horizon docker image larger and more complicated.
>
> What are your thoughts?
>
> [0]
> http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
>
> --
> Kind Regards,
> Dave Walker
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160708/6e749ee7/attachment.html>