Changes between Version 14 and Version 15 of FeddPluginCalls

Timestamp:

Jul 16, 2012 3:12:28 PM (12 years ago)

Author:

faber

Comment:

--

FeddPluginCalls

@@ -138 +138 @@
 That is done in all the existing plug-in code.  The various plug-ins walk, alter, and write topologies in several ways, and that code is a good guide to them.  The [source:fedd/federation/topdl.py topdl source] is also available.
 
-The connection information explains how the connectivity is established between the sub-experiments.  Now there are two ways to establish connections - ssh tunnels and direct transit connections.  The ssh connection implies a portal in this experiment (it will be in the topology description) that will connect to the peer.  Generally the port on which to communicate will be a parameter as it is here.  Parameters are set using the SetValue interface, which is demonstrated in most existing plug-ins.
+The connection information explains how the connectivity is established between the sub-experiments.  Now there are two ways to establish connections - ssh tunnels and direct transit connections.  The ssh connection implies a portal in this experiment (it will be in the topology description) that will connect to the peer.  Generally the port on which to communicate will be a parameter as it is here.  Parameters are set using the !SetValue interface, which is demonstrated in most existing plug-ins.
+
+There are a few conventional parameters:
+
+ '''peer'''::
+  The DNS name or IP address of the other side of the connection
+ '''ssh_port'''::
+  The port to contact ssh on the peer
+ '''vlan_id'''::
+  For federants that are connected to transit federants, e.g., dragon, this is the VLAN ID to use in the connection
+
+For most federants the {{{import_store_info}}} member of {{{federation/access.py}}} will import the necessary parameters correctly.  For those outputting values, the {{{export_store_info}}} member of {{{federation/emulab_access.py}}} is a good starting point.
 
 A plug-in should export its connection parameters as soon as it can determine them, and import connection parameters as late as it can in the experiment creation process.
@@ -214 +225 @@
 {{{allocID}}} identifies either the allocation to release or that has been released.
 
+== Using !SetValue and !GetValue ==
+
+The experiment controller acts as an exchange point where access controllers can exchange information they need to interconnect.  Specifically the parameters in the connection structures of a !StartSegment request are exchanged through the experiment controller.
+
+A !SetValue request has the form:
+
+{{{
+request = {
+    'name': key_from_connection_parameter,
+    'value': value_to_set,
+}
+}}}
+
+Values are strings and the name is a unique key (generated by the experiment controller) that identifies the variable.  Access is contolled for each variable.
+
+The response is
+{{{
+request = {
+    'name': key_from_connection_parameter,
+    'value': value_set,
+    'proof': An_ABAC_proof_of_access
+}
+}}}
+
+!GetValue requests are similarly formatted:
+
+{{{
+request = {
+    'name': key_from_connection_parameter,
+    # If wait is true, the call will block until some access controller has set the value
+    'wait': boolean,
+}
+}}}
+
+and the response is
+
+{{{
+response = {
+    'name': key_from_connection_parameter,
+    # This is optional.  If wait was not set in the request and the value is unset, this field will not be in the response
+    'value': value,
+    'proof': An_ABAC_proof_of_access
+}
+}}}
+
+Requesting !GetValue with the {{{wait}}} parameter set blocks the caller until the value is set.  Commonly, access controllers will set their output parameters using multiple SetValue calls and then wait for values from others using blocking !GetValue calls.
+
 == Next ==