Re: [openstack-dev] [kolla][horizon] Out of branch horizon plugins?
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@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 [em...@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-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
Re: [openstack-dev] [kolla][horizon] Out of branch horizon plugins?
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 [em...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
