Changes between Initial Version and Version 1 of FeddPluggingIn

Timestamp:

Jun 29, 2010 12:20:17 PM (14 years ago)

Author:

faber

Comment:

--

FeddPluggingIn

@@ +1 @@
+= Plugging In =
+
+The [source:fedd/trunk/federation/skeleton.py 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 [source:fedd/trunk/federation/skeleton.py skeleton plugin].  These are a configuration object and an authorizer object (and the [source:fedd/trunk/federation/access.py 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 [FeddPluginCalls 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
+}}}