Plugging In

The skeleton plugin is not a real plug-in. It is one of the standard access controllers that ships with the fedd install. First we'll create a plug-in. A plug in is just python code that defines a class called access that accepts the same parameters to its initializer as the skeleton plugin. These are a configuration object and an authorizer object (and the standard plug-in base class will handle the authorizer for you. It should also conform to the conventions in the skeleton with respect to setting up the self.soap_services and self.xmlrpc_services dicts, and handle the various plug-in calls.

An easy way to do this is to simply copy the skeleton into a file in another directory with a different name. Because you have moved this module relative to its current place in the hierarchy (it is no longer in the federation directory) you will have to modify the import paths at the beginning. Specifically change the lines:

from util import *
from fedid import fedid, generate_fedid
from authorizer import authorizer
from service_error import service_error
from remote_service import xmlrpc_handler, soap_handler, service_caller

import topdl

from access import access_base

to:

from federation.util import *
from federation.fedid import fedid, generate_fedid
from federation.authorizer import authorizer
from federation.service_error import service_error
from federation.remote_service import xmlrpc_handler, soap_handler, service_caller

import federation.topdl as topdl

from federation.access import access_base

That is, explicitly set the federation. scope for modules in fedd's federation directory. The plugin sits outside the fedd code tree, so if it needs to use other code that lives in that tree, it must import from the federation package.

It is also probably worthwhile to add a log message to the initializer so that you can tell your code ran. For example, add

self.log.debug("This is my plugin module")

to the end of your access.__init__(self, config, auth) member.

To dynamically load the plug-in you need to:

• Create a directory readable by the user fedd will run as
• Move your python plug-in code into there. Name the file something other than emulab.py, dragon.py, protogeni.py, deter_internal.py or skel.py. Make sure it can also be read by the fedd user.
• Add your pathname to the module_path configuration variable in the [globals] section
• Set the access_type to the name of your file (without the .py).

If your plugin is in /usr/home/faber/plugins/plug.py then your configuration file should contain the following definitions in the [globals] section:

module_path: /usr/home/faber/plugins
access_type: plug

Run fedd with your modified configuration after --config and with --debug to see your log message:

fedd.py --config=/home/faber/fedd/fedd.config --debug

and you should see something like:

29 Jun 10 19:33:29 fedd.access [read_state]: No saved state: Can't open /users/faber/fedd-config/skel2/skel_access.state: [Errno 2] No such file or directory: '/users/faber/fedd-config/skel2/skel_access.state'
29 Jun 10 19:33:29 fedd.access This is my plugin module