Changes between Version 2 and Version 3 of GEC20Agenda/DeveloperRoundtable

06/30/14 10:19:38 (10 years ago)
Aaron Helsinger



  • GEC20Agenda/DeveloperRoundtable

    v2 v3  
    3030== Agenda / Details ==
    3131This software development session provides an opportunity for GENI developers to collaborate informally. Topics are TBD based on discussions in the [wiki:GEC20Agenda/DeveloperTopics Developer Topics] session and topics raised by the GENI developers in attendance. Possible topics include Speaks For, Stitching, [wiki:GAPI_AM_API_V3 AM API] implementation status, and tool use of the [wiki:CommonFederationAPIv2 Common Federation API].
     33== Session Summary ==
     34We started the Developer's Roundtable by going around the room to see if anyone in attendance had issues that they wanted to raise. Paul Ruth of RENCI and one of the experiments trying to push the bounds of GENI asked about getting more resources in InstaGENI: more disk space for example. Paul also indicated that often bringing up multiple Xen VMs at a single AM fails. Nick Bastin indicated that this is a limitation of the time it takes to start the image. Bringing up the VMs in chunks might help. If we complete implementation of the AM API `Update()` call, this might help. Nick indicated that geni-lib can call the ProtoGENI CM interface to do this now. In a related comment, Nick noted that at InstaGENI racks, the 'type_slots' element uses a number that is likely too high and does not distinguish between Xen and openvz instances, and the numbers should not be the same.
     36Xi Yang asked about the status of AM API v3 development. Anirban Mandal of RENCI said he believes it is not in their plans for ExoGENI. Nick says the !FlowVisor FOAM will not support it. VTS does support APIv3, though it needs to be cleaned up. The OESS AM (which uses FOAM) will not get the v3 support for free. Aaron Helsinger noted that while we want v3 support, we do not really need it now.
     38Marshall Brinn raised the main topic of the session: how can we provide uniform guidance to tools on what cross-AM connectivity options are available, and how to pick among them. We quickly decided that this is an AM to AM question, not a specific node type question (though the tool will need that knowledge as well). We also noted that there are two kinds of questions. First, there are questions about basic static attributes of the aggregate (has-lots-storage, supports-openvz); these attributes can be pulled from the Ad RSpec or stored as attributes in the GENI Clearinghouse Service Registry. Some questions however require reasoning about multiple Ad RSpecs or other computation. These should be answered by a service, and we proposed that the existing Stitching Computation Service be expanded to provide this functionality. We determined that there are a couple questions we would like to be able to answer:
     39 - What are the connection options between these AMs?
     40 - What is the lowest cost connection?
     42We identified a few connection options: stitching, VTS, 'MiniVTS' (described in a moment), shared VLANs, and GRE tunnels.
     44Nick noted that we should discourage GRE and other control plane connections where a data plan connection is an option; such connections are easy to set up, but may disrupt other experimenters more significantly. We discussed that this might be a factor in the 'cost' we use when listing connectivity options.
     46Nick offered to make the VTS AM support the stitching RSpec extension, so that it could look like another way to get a VLAN between 2 AMs that do not support stitching (but do support VTS). Nick termed this 'MiniVTS', as it would not support arbitrary datapaths or Openflow control, but would simply provide a VLAN between the AMs. Nick agreed to push this on his development plan. He also noted that the MTU on the link might be limited when using these links.
     48Aaron proposed that this functionality could be satisfied with a single query:
     49`getConnectionOptions(AM1, AM2)`
     51Ordered List of tuples: Connectivity Option, BW, Latency, comment
     52(where the bandwidth and latency measures are just informational for experimenters, may not make sense for some options, and units are TBD).
     54Tom Lehman agreed to work with others to further define this new function in coming weeks and months.