• Integration of OMF Management with PlanetLab testbeds
  • 1. Goal:
  • 2. Simple Scenario Overview:
  • 3. Scope:
  • 4. Design:
    • 4.1. Procedure from adding a new user to a new experiment:
      • In OMF:
      • In PlanetLab using SFA:
      • Proposed integration for the 1st version:
    • 4.2. Required software extension
    • 4.3. Security considerations:
  • 5. Implementation
    • 5.1. Version 1
      • Aggregate Manager Wrapper
      • RSPEC extension
    • 5.2. Version 2

Integration of OMF Management with PlanetLab testbeds¶

1. Goal:¶

Allow experimenters to use the PlanetLab tools to discover and browse resources managed on an OMF-enabled testbed, and associate such a resources to their slice.

In other words, allow an experimenter to use the sfi.py tool with OMF-managed resources, and allow the operator/maintainer of an OMF-enabled testbed to open her/his testbed resources to the SFA user community.

Please read our OMF Introduction Page or refer to the Glossary for more information about OMF.

Also please read the SFA Overview and Guide wikis for more information about SFA.

2. Simple Scenario Overview:¶

• 1 - the user request a slice using the SFA tools, the slice is approved and created by her/his Principal Investigator (PI).

• 2 - the user uses the SFA command sfi.py to browse for available resources, similar to the procedure described on the SFA guide page

• 3 - the user can browse for available resources on an OMF-managed testbed. For example:

# If the OMF-managed testbed is provided by the "nicta" site, 
# then the user would issue the command:

 sfi.py list -t node omf.nicta

# Which would produce an output similar to this:

 omf.nicta.node1 (node)
 omf.nicta.node2 (node)
 omf.nicta.node3 (node)

# The user can then request for more information on one of these resources:

 sfi.py show omf.nicta.node2

# Which would produce something similar to:

     peer_authority: None
     hrn: omf.nicta.node1
     last_updated: 20100325T22:23:06
     authority: omf.nicta
     gid:
          hrn: omf.nicta.node1
          urn: None
         uuid: 1234567890123456(...)
     date_created: 20100325T22:23:06

• 4 - the user can then add OMF-managed and traditional PlanetLab resources to his/her slice, using the SFA tools, as described in the procedures explained on the SFA guide.

3. Scope:¶

• Version 1 of this development will only focus on enabling the above scenario for users registered on PLC or PLE, using the SFA tools.

• Version 2 will extend the previous step to address the federation of user base between PlanetLab and OMF. More precisely, this version will enable the above scenario for users registered on either a PlanetLab or an OMF-enabled testbed, using the SFA tools.

• About virtualisation:
  • OMF currently does not support any virtualisation scheme on the resource (this is being investigated).
  • Thus an OMF-managed resource is currently available to only a unique user for a given time duration.
  • During this duration, the user has full access to the resource (i.e. root account and/or privileges)

4. Design:¶

4.1. Procedure from adding a new user to a new experiment:¶

In OMF:¶

• 1 - User registration - This is currently testbed-dependent, e.g. at WINLAB an LDAP-based solution is used to maintain the user base, at NICTA testbed users need to have a unix account on the norbit machine.

• 2 - Resource discovery - The user looks at resource lists (usually online, via webpage map of the testbed)

• 3 - Resource reservation - The user looks at available time slots for the resources she/he wants to use, again this is testbed-dependent, she/he then books a time slot for the resource. For example, at WINLAB a web-based scheduler/planner is used, at NICTA a shared google calendar is used. Note that NITLAB developed and are using another scheduler, which might be included in OMF in the future.

• 4 - Experimentation time - When the booked time slots arrives, the user is allowed to run her/his experiment on the resources.

In PlanetLab using SFA:¶

• 1 - User registration - The PI of a site uses SFA to create a new account for a user.

• 2 - User/Slice association - The PI uses SFA to associate the user to an existing or a new slice (if new, then the PI has to first use the SFA to create a new slice)

• 3 - Resource discovery - The user uses SFA to browse available resources from all the testbeds federated by SFA

• 4 - Resource allocation - The user uses SFA to add some available resources to the slice she/he is associated to

• 5 - Experimentation time - After a "short" time period, the user is allowed access to the resources to run her/his experiment.

Proposed integration for the 1st version:¶

• The PlanetLab steps above will be used. However:
  • steps 1 & 2 (registration, and slice association) will not necessarily trigger any action on the OMF side for this 1st version:
    • for the OMF testbed, we could have a generic 'planetlab' user maintained, which will be used for all resource reservations coming from the planetlab world
    • or a unique temporary user is created on the OMF side for each new resource reservation from the planetlab world
  • step 3 (resource discovery), here the SFA tool will return to the user a RSPEC of the resources available on the OMF testbed. For this 1st version, each resource in that RSPEC will have an additional availability tag, which for example could mention the next available 10 time slots for this resource.
  • step 4 (resource reservation), here the SFA tool will accept from the user an RSPEC, where each OMF resource entry will contain the selected time-slot to reserve
  • step 5 (experimentation), a given OMF resource previously added to a slice will only become accessible to the user during the booked time slot.

• Open question: How do we control the access to the OMF resources?
  • currently for a given slice Planetlab lab uses SSH pub/priv key authentication for each slice users (i.e. pub key of user is copied in each virtual machines in the slice)
  • currently no authentication & authorization schemes are defined in OMF, each testbed deploys its own. For example at NICTA the resources are open to all users with an account on the testbed, since the user base is small, we trust them to respect each other's booked time-slot. In another example, at Winlab LDAP is used to restrict the user login and access to their booked resources only within their time-slot.

4.2. Required software extension¶

• Fig. 1 illustrates the software design of the current SFA tool (server-side) when used to federate to Planetlab-type of testbeds (e.g. PLC and PLE). This figure is derived from the SFA Implementation description document, available on Planet-Lab's svn repository. Please refer to that document for more details on the SFA design.

Figure 1: Current SFA federation

Figure 2: Integration of OMF-Management into SFA federation (v1)

• Fig. 2 illustrates the software extension required to implement the 1st version as described earlier:
  • we will re-use all of the existing SFA components, e.g. Slice Manager, Registry, except for the SFA Aggregate Manager component
  • we will implement a AM Wrapper which will:
    • act as an Aggregate Manager component in regards to the other SFA components
    • translate request/replies from the SFA components to their equivalent request/replies for the OMF Aggregate Manager
  • we will extend the current SFA RSPEC to allow a resource description to include an "time slot" attribute, which:
    • in the case of a RSPEC returned as a reply to a resource discovery (e.g. "sfi.py resources"), will contain the details of the next 10 (or X) available time slots
    • in the case of a RSPEC sent as a resource addition to a slice (e.g. "sfi.py create sliceX r.rspec"), will contain the details of the time slot to reserve
    • Open question: we noticed the presence of a "time" and "duration" attributes in the current SFA RSPEC, is it possible to use these attributes for this additional purpose??

Figure 3: Integration of OMF-Management into SFA federation (v2)

• Fig. 3 illustrates the software extension required to implement the 2nd version as described earlier:
  • similar to the previous version, we need to implement a Registry Wrapper around OMF's user and resource base
  • Open question: as stated earlier, OMF does not currently specify how the user base should be manage (e.g. user-base = existing users on a given server at NICTA, user-base = LDAP directory at Winlab). We need to unify that for OMF. OMF currently has an inventory database with information for all resources on a testbed, maybe this could be extended to include the user-base?
  • Open question: the above 1st version made a simplification regarding the mapping of the user registration and slice creation steps between OMF and PlanetLab. OMF currently does not have a notion of slice. Shall we introduce a notion of slice at this stage (and remove the previous simplification), or wait for virtualisation support in OMF (and design that feature with this OMF-PlanetLab federation in mind)?

4.3. Security considerations:¶

• As mentioned earlier, OMF currently does not define a unified authentication & authorization schemes, each OMF testbed deploys its own. We need to design such unified schemes on the OMF side, or adopt/extend an existing one. These need to at least match the level (or improve over it) of any such similar schemes in the testbeds federating with OMF, i.e. in this case at least match the features provided by PlanetLab and SFA public/private key + SSL schemes.

• Once we have such schemes in OMF, we need to address their integration with the existing SFA authentication & authorization schemes. We should keep in mind this federation requirement when designing our OMF solutions for this.

• Open question: What is the priority of such design/development compared to other OMF features (e.g. virtualisation)? In other words, shall this be in the currently under-development 5.3 release, or in a future one? What would be the path to deploy this on heavily used testbed such as the ORBIT grid at Winlab? Shall this be backward compatible with the current 5.2 release?

5. Implementation¶

• All slice and resource names will follow the PlanetLab HRN (Human Readable Name) convention

• The current public source of SFA is available here: http://svn.planet-lab.org/browser/sfa

• The following implementation proposals are based on the "trunk" sources from that repository

5.1. Version 1¶

Aggregate Manager Wrapper¶

• Valid SFA-server methods are declared as method classes (see: link to source). Each of these commands specify what type of interface they could be implemented for, i.e. a given command might be available for as a Slice Manager command and as an Aggregate Manager command. Depending on which interface it is used for (e.g. for an AM), the command code calls the specific method corresponding to this interface. This specific command is implemented in the "manager module for that interface (e.g. the manager module for planetlab). The current list of valid commands for an Aggregate Managers are:
  • create_slice
  • delete_slice
  • get_slices
  • get_ticket
  • reset_slice
  • start_slice
  • stop_slice
  • (get_aggregates)
  • (get_registries)
  • (get_resources)

• Open question: while some of these commands have obvious function after reading the available SFA docs and browsing the code (e.g. create_slice => assign resources to slice via RSPECs), the function of others is not clearly explained (e.g. start_slice, what does "starting" a slice involve? is it a PI-only command or also available to plain user?). We need to get detailed information on this from the SFA developers. Also the commands within brackets seem not to be used by the AM itself, we need to confirm that.

• The SFA-server has a modular design allowing different type of Aggregate Managers to be used (see: link to source). To implement the proposed 1st version, it seems that we need to:
  • create a new module at: /sfa/managers/aggregate_manager_omf.py
  • inside that module, implement the processing code for each of AM-specific commands described in the above list
  • in the SFA config file (at /etc/sfa/sfa_config) make sure that we use "SFA_AGGREGATE_TYPE = omf" and the others component type parameters should stay set to "pl".

RSPEC extension¶

• We need to verify with SFA developer the exact semantic of the "duration" and "start_time" attributes associated with the current <RSPEC> and <NETSPEC> tags of the current RSPEC schema.

• If we possible, then we should first try to augment/extend the semantic of these attributes to allow RSPEC related to OMF-managed resources to specify available time slots, and to allow users to specify requested time slots. If not possible, then we need to create a new RSPEC extension that will allow this.
  • create a new XML schema at: sfa/trunk/sfa/managers/omf/omf.rng following examples in pl.nrg
  • Open question: what is the purpose of the .rnc files (e.g. pl.rnc)? Is this the Dict definition file? Is it required?
  • Open question: the current RSPECs defined and illustrated in sfa/trunk/sfa/managers/pl do not seem to match the ones returned by the "sfi.py resources" command. Is the SFA-client (sfi.py) using its own formatting (and translates whatever RSPEC is sent/received from the server), or is the current deployed SFA using an old RSPEC schema?

• Open question: the current SFA documentation do not state what reply message (if any) is sent to the user if the association of a resource to a slice is unsuccessful, i.e. if a "sfi.py create my_slice my_resource.rspec" fails because the resources described in my_resource.rspec are not available. In the context of OMF-managed resources, this will happen if two users try to book the same resource for the same time slot after both of them discovered the resources as "available" a few moment earlier. The first request will get the booking, and the second request should result in some error message to the user (e.g. "resource X not available"). Is there a mechanism in the current SFA implementation to handle such type of replies, or do we need to extend it?

5.2. Version 2¶

• Implementation for this version will first require more design clarification, i.e. address the "open questions" from 4.2 and 4.3 sections above.