wiki:GEC20Agenda/DeveloperRoundtable

Version 3 (modified by Aaron Helsinger, 5 years ago) (diff)

--

GEC20 Developer Roundtable

This is an informal session for GENI developers to discuss details of software integration, and software issues that affect multiple control frameworks or tools. Note that this session is separate from the parallel experimenter and educator drop-in session.

Schedule

Tuesday, 11:30am - 1:00pm

Session Leaders

Marshall Brinn
GPO
Tom Mitchell
GPO
Aaron Helsinger
GPO

Agenda / Details

This software development session provides an opportunity for GENI developers to collaborate informally. Topics are TBD based on discussions in the Developer Topics session and topics raised by the GENI developers in attendance. Possible topics include Speaks For, Stitching, AM API implementation status, and tool use of the Common Federation API.

Session Summary

We 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.

Xi 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.

Marshall 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:

  • What are the connection options between these AMs?
  • What is the lowest cost connection?

We identified a few connection options: stitching, VTS, 'MiniVTS' (described in a moment), shared VLANs, and GRE tunnels.

Nick 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.

Nick 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.

Aaron proposed that this functionality could be satisfied with a single query: getConnectionOptions(AM1, AM2) Return: Ordered List of tuples: Connectivity Option, BW, Latency, comment (where the bandwidth and latency measures are just informational for experimenters, may not make sense for some options, and units are TBD).

Tom Lehman agreed to work with others to further define this new function in coming weeks and months.