FAQ

• I want to add a new API (e.g. SFA). Do I need a new eiSoil instance for this? Simple answer: No. Long answer: Adding a new API is quite simple in eiSoil and possible within a single instance. First, please read RPC Handling for GENI which details the relationship between RPC Handlers, Delegates and Resource Managers.

  If you want to add a new API, you only need to add new Handler. It registers itself as RPC listener with the flask plugin. An example for GENI AM API v3 is provided in src/plugins/geniv3rpc/g3rpc/genivthree.py. As with the GENIv3 Handler, the Handler should retain a reference to a single Delegate. Additionally it shall define all the methods needed for the new API. As detailed in [1], the Handler should only perform basic processing (e.g. general error handling, consistency checks). But: The Handler shall not perform operations related to the specific resource handling (e.g. code for handling a VM specification would be wrong in the Handler). Handlers are implemented once for an API and can be re-used by others. This is what Delegate and Resource Managers are for.

  When adding a new Handler, you should also define a base for the Delegate (e.g. MyApiDelegateBase). Later the AM developer only needs to subclass this base class and translate the calls to the respective resource managers. Code for such a base class can be found src/plugins/geniv3rpc/g3rpc/genivthree.py. Also, please find the motivation for such a decoupled approach via [1]. Additionally, the dhcp example included in eiSoil provides a simple Delegate (src/plugins/dhcpgeni3/dhcpgenithreedelegate.py) and Resource Manager (src/plugins/dhcprm/dhcpresourcemanager.py).

  P.S.: When you will write or wrote a new Handler please contact me and we could merge the code into the trunk of eiSoil.

• How can I support different control frameworks with other APIs? eiSoil can handle multiple API versions and different API types. In fact, eiSoil was built for this.

  If you follow the principles of eiSoil, you (the developer) would create a Resource Manager which is domain-specific. Let's say you want to create a VM Aggregate: Your Resource Manager would have domain-specific methods like instanciate_vm(), restart_vm(), assign_ip_to_vm().
  In contrast to the RPC Handler (see GENI), these methods are not given by the AM API (e.g. generic calls like Provision, CreateSlice). The RM methods suit the needs of the VM Manager and not the needs of the control framework.

  Now, we have two things missing: Someone who takes the call from a control framework client (e.g. SFA client, omni). This is what RPC Handlers are for, they take the generic calls, do some magic and pass the request on to a RPC Delegate.
  The RPC Delegate is the second thing missing. It translates the generic calls received from the RPC Handler to Resource Manager methods. Keep in mind the RPC Delegate has methods which are specific to the control framework (e.g. GENI AM API v2, SFA); the Resource Manger methods are specific to the managed resource. The translation is - often - fairly straight forward: E.g. the Delegate gets called from the RPC Handler. It receives the GENI AM API call "Provision" and the Delegate implementation calls instantiate_vm() on the Resource Manager.

  Now, we know how it works when we have one RPC (one control framework API). But now, we can use the same concept to add new control framework APIs. Let's say we have created a VM Aggregate Manager which has a Resource Manager that handles all the XEN specific work. This AM speaks GENI AM API v2. Now we want to make it speak SFA. We create a new SFA RPC Handler which is generic and can be reused by others later*. This RPC dispatches the calls to a SFA Delegate. This delegate then uses the Resource Manager (yey, we already created that one before). [repeat this paragraph for other RPCs].

  More on this concept can be found in the GENI page.

  * Contact me. I may be of assistance here. We need to consider re-usability, authentication, authorization and more.

• What is the relation of Aggregate Managers and eiSoil? In OFELIA, each resource type is managed by a dedicated AM (e.g. Virtual Machine Aggregate Manager). Each of those AMs can be based on eiSoil (or not). If we want to deploy multiple resource types, we need different instances of AMs, hence different installations of eiSoil. To use a more familiar analogy: Let’s assume Amazon’s and eBay’s web sites would be implemented with the Django framework. If our goal would be to run the Amazon and eBay website, we would need two instances/servers (= two AMs). Since both of those two implementations are using Django (= eiSoil) we would have two instances of Django. Side note: There is no concept like virtual servers or similar included in eiSoil. eiSoil assumes one handler (~ resource type) and one handler only.

• Why does each request take so long? Each request for the GENIv3-RPC plugin performs validation of the given RSpec schemas. The validation process tries to download the schemas from the schema URL. This may take time. While you are developing, it is faster to deactivate the geniv3rpc.rspec_validation configuration key (also see GENI).

• I am getting weird SSL errors in production mode. Why? When the client (omni) sends a request, the request goes to nginx (the webserver). Nginx then delegates the request to eiSoil, but only if the client's certificate (sent by omni) matches the one in the nginx config. So please make sure that the nginx installation uses the client_certificate which is used by your Clearinghouse (this certificate is usually named certificate authority or short CA).

• I am trying to run an AM (e.g. FOAM) and an eiSoil instance on the same machine. How can I do this? Related to the SSL question above: Follow the other AM's instructions and the instructions of eiSoil. The only important thing is to make sure they use the same certificate authority.