recently I encountered an issue with plugins and installer for which I'd like
to know your opinions. Our installer is capable of installing various plugins.
Some of them have extra custom installation logic, e.g. discovery, remote
execution and have their own enable/disable switch. When installer is run it
triggers migrations and seed and since just by installing the rpm/deb we put
the record in bundler.d, so the plugin is always loaded. Therefore installer
runs plugin migrations and seed the DB even if the plugin was not enabled.
This results in partially installed plugins which in UI looks completely
installed. Also it means that if we explicitly disable some plugin through
installer later, it still appears as installed.
I can see two possible ways out of it.
A) One is that we stop packaging bundler.d files and put it in place by the
installer only if the plugin is explicitly enabled.
B) Second is that the plugin in the installer would be always enabled if the
package is installed.
I think the first one would make it harder to setup Foreman not using the
installer but looks better to me. None of them solves disabling enabled plugin
though.
What do you mean by "not enabled", and "their own enable/disable
switch"? Is this a further config file or Setting that needs changing?
The installer classes should normally configure everything that is
required if the plugin class is enabled.
···
On 20/04/16 12:30, Marek Hulán wrote:
> Hello devs,
>
> recently I encountered an issue with plugins and installer for which I'd like
> to know your opinions. Our installer is capable of installing various plugins.
> Some of them have extra custom installation logic, e.g. discovery, remote
> execution and have their own enable/disable switch. When installer is run it
> triggers migrations and seed and since just by installing the rpm/deb we put
> the record in bundler.d, so the plugin is always loaded. Therefore installer
> runs plugin migrations and seed the DB even if the plugin was not enabled.
> > Hello devs,
> >
> > recently I encountered an issue with plugins and installer for which I'd
> > like to know your opinions. Our installer is capable of installing
> > various plugins. Some of them have extra custom installation logic, e.g.
> > discovery, remote execution and have their own enable/disable switch.
> > When installer is run it triggers migrations and seed and since just by
> > installing the rpm/deb we put the record in bundler.d, so the plugin is
> > always loaded. Therefore installer runs plugin migrations and seed the DB
> > even if the plugin was not enabled.
> What do you mean by "not enabled", and "their own enable/disable
> switch"? Is this a further config file or Setting that needs changing?
"not enabled"
Suppose you run --no-enable-foreman-plugin-discovery while you have tfm-
rubygem-foreman_discovery installed.
>>> Hello devs,
>>>
>>> recently I encountered an issue with plugins and installer for which I'd
>>> like to know your opinions. Our installer is capable of installing
>>> various plugins. Some of them have extra custom installation logic, e.g.
>>> discovery, remote execution and have their own enable/disable switch.
>>> When installer is run it triggers migrations and seed and since just by
>>> installing the rpm/deb we put the record in bundler.d, so the plugin is
>>> always loaded. Therefore installer runs plugin migrations and seed the DB
>>> even if the plugin was not enabled.
>> What do you mean by "not enabled", and "their own enable/disable
>> switch"? Is this a further config file or Setting that needs changing?
>
> "not enabled"
>
> Suppose you run --no-enable-foreman-plugin-discovery while you have tfm-
> rubygem-foreman_discovery installed.
The distinction then is that --no-enable means "don't manage X", not
"disable X".
Whether the installer is used or not, all of our Foreman plugin packages
will migrate or seed databases if installed, and all of our smart proxy
plugin packages will be enabled by default, so it's basically this that
you're proposing changes? All plugins would need to be explicitly
enabled after installation.
> A) One is that we stop packaging bundler.d files and put it in place by the
> installer only if the plugin is explicitly enabled.
To place the file only when the plugin is explicitly enabled would
require purging of a directory of files (one per plugin), or a single
file that loads multiple plugins - so managing the entirety of
bundler.d/, using another directory or managing bundler.d/plugins.rb or
something.
A config file would perhaps be better than the contents of bundler.d.
The bundler.d files aren't config files and needing users to move them
around will cause the packaging system to lose track of them and not be
able to update their contents. The packages would also be difficult to
use by themselves.
Note these are smart proxy plugins, which work somewhat differently.
They're also enabled by default.
Would changing the installer behaviour boil down to one of these two
options?
Keep --no-enable to remove management of the class, but disable
unmanaged plugins by purging a directory/managing a list in a file.
This'd work for the smart proxy, Foreman plugins would need similar
config files adding.
Always include every plugin class to manage their config files, but
add enabled flags to every plugin class. Also, don't configure other
resources when the plugin is disabled.
···
On 20/04/16 12:46, Marek Hulán wrote:
> On Wednesday 20 of April 2016 12:35:57 Dominic Cleal wrote:
>> On 20/04/16 12:30, Marek Hulán wrote:
> 1. Keep --no-enable to remove management of the class, but disable
> unmanaged plugins by purging a directory/managing a list in a file.
> This'd work for the smart proxy, Foreman plugins would need similar
> config files adding.
I agree - messing with bundler.d is a bad idea for all the reasons Dominic
lists.
Furthermore, the ability to separate enable/disable plugins via config
could potentially give us the option to allow users to alter enabled
plugins from the UI (alter configfile && touch tmp/restart.txt?) which is a
plus.
Greg
···
On 20 April 2016 at 16:42, Lukas Zapletal wrote:
