FAQ

• 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 AMsoil, 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 AMsoil 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 AMsoil. The only important thing is to make sure they use the same certificate authority.

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

  If you follow the principles of AMsoil, 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.