Version 5 Development > Plugin Design
Some suggestions to get the ball rolling
bubbaQ:
[moved from webGui Design ]
After walking through code in /u/l/w/, I see some obvious ways plugins can be hooked in, but the basic question is do you want unRAID to handle presentation of plugins and handoff to the individual plugin when selected in the UI, or do you want unRAID to simply point to and handoff to a plugin manager, that has its own UI and will take care of presentation of plugins to the user?
Of course, the later can be one of the former.... so the question is do you want the former at all.
The same question will come up with event callouts to plugins.... should unRAID provide the callouts to every plugin, or to a plugin manager that takes care of passing the event callouts to the plugins? Or do plugins hook into the callouts (i.e. the callouts are to a predefined script name and plugins have to add themselves to it... not the way I'd do it but some do).
A separate question is installation and updating of plugins, which I see as left to the community to develop a third party plugin manager (TPPM).
I also do not see a away to add to the 5 predefined tabs (Main, Settings, Shares, Users, Utils). Fingured it out.... create a .page file containing:
Menu="Tasks"
Type="xmenu"
And that will create a tab with the same name as the .page file
I'll throw out the following for discussion:
Add a tab "Plugins" that includes a config option to enable or disable plugin processing. Perhaps always scan the plugin .page files, but display the icons for plugins greyed-out if plugins are globally diabled.
Optionally consider a "path to plugins" option, so they could be stored other than a fixed location on the flash. Or perhaps allow fully qualified paths in the .page files.
Do plugin processing the same as is being done in the webGui (scan the flash config/plugins for .page files)
Allow some way for devs to add to the predefined 5 tabs. Perhaps scanning the .page files, and the list of tabs comes from the unique aggregate of menu names used in the .page files.
There is no mechanism for scripting of plugins (i.e an init or stop script). This could come from the event callouts, but also could come from additional directives in the .page files. There are benefits to both. If it was done in the .page files, disabling plugins would then give you a "virgin" system on reboot by also disabling callouts to the plugins... so that could be a positive for troubleshooting for Tom (i.e easy way to make sure no plugins are messing with anything when users report a core unRAID problem).
I also think there needs to be some smarts to enable/disable individual plugins within unRAID, so if the third-party plugin manager is broken, users have a fallback other than globally disabling all plugins. The third-party plugin manager (TPPM) can use the same mechanism, but I strongly think unRAID should also be able to do it independently. This could be done on the Plugins tab, by a table listing all the plugins found and allowing them to be manipulated individually.
So in sum, I suggest
- a plugins tab, that includes configuration options to globally disable all plugin support.
- includes a path to plugins option, which defaults to the conventional /boot/config/plugins location.
- includes a tabular list of all plugins found and info about them, and the ability to manipulate (disable) them.
- ability of a dev to add to the predefined list of tabs.
- leave installation, updates, and other management of plugins to a TPPM.
WeeboTech:
--- Quote from: bubbaQ on July 19, 2010, 10:20:08 AM ---The same question will come up with event callouts to plugins.... should unRAID provide the callouts to every plugin, or to a plugin manager that takes care of passing the event callouts to the plugins? Or do plugins hook into the callouts (i.e. the callouts are to a predefined script name and plugins have to add themselves to it... not the way I'd do it but some do).
--- End quote ---
We've gotten pretty far without any formal support of Plugins.
I would prefer not to be adding/removing lines to predefined call out scripts.
Instead, I would prefer the callout or "event" scripts to read a directory of plugin/installed scripts.
How the unix environment does it is fine and not overly complex.
Each plugin can be designed to source a basic config file that has definitions for it.
I.E. Should it run, where it's files exists.
Put a file named a certain way in a runlevel directory and it will get run when that event occurs.
This is how Thecus does it.
We've had many conversations about events and part of this discussion needs to be the list of events that occur and where we want to hook in.
There was mention a while ago about an http call to "register" your plugin into the event list.
I prefer installing a script into a event level directory.
From what I can see, the minimal Event Levels needed.
1. Before the array is started for the "first time". After boot.
2. After the array is started.
3. Before the array is stopped.
Right now we have #1 from the go script, but a formal specification would be better.
2 is achieved by polling mdcmd or some dev or some other method.
3 is not really handled correctly. the powerdown package simply hooks itself into the rc.shutdown script and hopes to achieve a more graceful shutdown by doing rudimentary cleanup.
I'm not going to get into the presentation of them right now as there seem to be a number of options available.
In summary,
Also up for discussion is the agreement of events and how we're going to run/trigger them.
bubbaQ:
--- Quote ---I would prefer not to be adding/removing lines to predefined call out scripts.
--- End quote ---
I agree. But that means the script has to have more intelligence in it. Not necessarily a lot, but even just iterating over files flagged as executable is more smarts than just a single script call.
--- Quote ---Instead, I would prefer the callout or "event" scripts to read a directory of plugin/installed scripts.
--- End quote ---
I agree, with the caveat that unRAID should have an ability -- at a minimum -- for a user to disable all plugins that would also disable all callouts to plugins.
--- Quote ---part of this discussion needs to be the list of events that occur and where we want to hook in.
--- End quote ---
Agreed. You've identified the bare minimum, and I also agree that the go script is not the place to achieve #1.
I also perceive of things other than standard "plugins" that will want to use the callouts, so they shouldn't be married to the plugin arch.
Some of the alternatives are:
-- scanning a plugin dir for +x scripts of a particular name.
-- scanning a plugin dir and subdirs for +x scripts of a particular name.
-- scanning a plugin dir for a subdir of a particluar name (ie. start, started, stopping) and running +x scripts in that dir.
-- scanning a plugin dir for .page files, getting script names from there and running them
-- scanning a plugin dir and subdirs for +x scripts of a particular name
However, I expect the plugin root (e.g. /boot/config/plugins) will have all the .page files, and each plugin will live either in the plugin root (particularly simple plugins) or in its own home dir under the plugin root. I would suggest that any plugin that wants to act on script callouts be required to create its own home under the plugin root, and unRAID simply scan all the subdirs under the plugin root.
The advantage is that the plugin home dir is self contained. For example:
--- Code: ---/config/plugins/xyz.page
/config/plugins/xyz/xyz.php
/config/plugins/xyz/array_start.sh
/config/plugins/xyz/array_started.sh
/config/plugins/xyz/array_stop.sh
--- End code ---
This would all be independent of unRAID script callouts that are independent of the plugin architecture, which could be:
--- Code: ---/boot/config/array_start.sh
/boot/config/array_started.sh
/boot/config/array_stop.sh
--- End code ---
Of course, the last three callouts could be used to invoke a script that invokes the plugin scripts ... but I would not do that, as it makes it harder if you want to do a master disable of all plugins (i.e. a unRAID safe mode) as you either need more smarts in the scripts, or you have to disable all the scripts, instead of just the plugin scripts.
WeeboTech:
In thinking out loud.....
--- Quote ---unRAID should have an ability -- at a minimum -- for a user to disable all plugins that would also disable all callouts to plugins.
--- End quote ---
Without a doubt.
Disable all or individually.
What I would add and require for each event/rc script to source a main plugin.cfg file and then source it's own name.cfg in the config or the plugin directory (I'm open there).
In the sourced config you would have
VAR=VALUE
and then use some of these variables to determine if you should run or not.
This would control if a plugin is enabled or disabled.
This is how RHEL operates for some of it's control mechanisms.
It's also easy enough to operate with sed scripts.
I'm sure there are some PHP libraries to manipulate the .cfg/.conf VAR=VALUE files safely.
I have some C programs that do it if need be. (That's for the front end).
I like the idea of consolidated management.
array_start.sh array_stop.sh, etc, etc. could get unwieldy after a while.
If we provide a template of an event script, then people just need to fill in the blanks.
the /etc/rc.d/rc.samba is a simple enough place to begin.
--- Quote ----- scanning a plugin dir for a subdir of a particluar name (ie. start, started, stopping) and running +x scripts in that dir.
--- End quote ---
This seems to be closer to a unix rc environment, however, I also think there may be too many names or subdirectories.
Is it easier to operate on one resource control script or a few resource control scripts to manage an event?
The closer it is to basic administration methods, the easier it will be for new comers to feel at home.
So... do we mimic an rc.d like structure of named event directories as a sysv unix environment would.
Or do like slackware does with a master rc.d directory and rc.plugin name.
or just look for one rc.plugin name and use the first argument to control what it's doing.
I.E. Each plugin control script would have to adhere to basic standards.
Parm 1 is the event. It either supports it or it doesn't and exits gracefully.
I'm not fond of start/started/stop.
What about
boot/start/stop
boot = first startup of environment after boot. before array is active.
start = start block of plugin after array is active
stop = stop block of plugin when array is going to be stopped.
we could have a shutdown block. I'm not sure that's needed. unless you want to copy something to flash when you know you are going to be rebooted.
So this gives
boot = install environment & cached etc files from flash.
start = starts package/environment/plugin
stop = stops package/environment/plugin
shutdown = save anything on root ram because it will not survive.
--- Quote ---However, I expect the plugin root (e.g. /boot/config/plugins) will have all the .page files, and each plugin will live either in the plugin root (particularly simple plugins) or in its own home dir under the plugin root. I would suggest that any plugin that wants to act on script callouts be required to create its own home under the plugin root, and unRAID simply scan all the subdirs under the plugin root.
The advantage is that the plugin home dir is self contained.
--- End quote ---
I agree with this idea. (thumbs up ;) )
Just thinking out loud here, lots of cool suggestions.
Joe L.:
One rc. script, similar to how Slackware does it is easiest for all, especially since it will mirror how Slackware itself works.
"boot", "start", "stop", "shutdown" works for me. Might want to permit others.. ("restart", "status" ) as needed to assist in maintenance.
I see that the current unRAID main page now provides real-time updates of the steps as it stops the array.
Try this to see it in action:
log in via telnet
cd /mnt/disk1
Then, use the management web-page to "Stop" the array. It will sit there adding "Attempting to un-mount" to the window, again, and again.
(until you type:
cd /boot)
I'd like to take advantage of that feature of real-time-status to send start-up/shut-down messages back to the user when there is a need, or when a plug-in cannot be started, or stopped.
With that in mind, the stdout and stderr output of an invoked rc. script should end up in a specific spot for capture by the unRAID web front-end. (A method to communicate the successful start/stop status of a plug-in to the user.)
Joe L.
Navigation
[0] Message Index
[#] Next page
Go to full version