[[PageOutline]] = Coding Sprint and Experimenter Tutoring = The joint software coding sprint and experimenter tutoring session is an informal session where aggregate and tool developers will discuss software details, and experimenters will run though GENI tutorials or ask questions of the GPO for help running experimenters. == Schedule == Wednesday, 1:30 pm - 5:30pm == Session Leaders == Sarah Edwards, Aaron Helsinger, and Niky Riga, GENI Project Office == Agenda / Details == {{{ #!comment Dial In: 866-453-5550 ; Participant pin: 6513886# }}} This software development session provides an opportunity for GENI engineers to collaborate in real time on a particular software or documentation issue. The topic will be selected well in advance of the conference, based on need and key party availability. At GEC12 and GEC13, the topic was AM API changes. Likely topics this time include requesting resources connected to a shared VLAN (like the mesoscale), stitching by GEC16 and specifically stitching racks by GEC15, improving the GENI experimenter experience, minor revisions to [wiki:GAPI_AM_API_V3 AM APIv3] based on questions while implementing the API, !UpdateSliver(), and RSpec schema changes. The GPO will also hold a tutoring session for GENI experimenters, where experimenters can come and work on various online GENI tutorials. The list of available tutorials will be advertised in advance of the GEC. The GPO will answer questions and provide assistance. Experimenters with an idea they want to work on are encouraged to come do so in the same room, so that they can have support from the on site GPO staff and other experimenters. GPO operations staff will also be available to help GENI ops/admin folks who'd like a hand getting set up with GENI credentials, the Omni command-line tool, etc. This can be useful if you're running a GENI aggregate, so you can create a slice and some slivers, and test for yourself whether the aggregate manager is working like you expect. === Developers Coding Sprint Topics === The actual topics will be dictated by the people in the room and their concerns, but we anticipate discussing these topics in particular: 1. Shared VLANs How do experimenters request resources on a shared VLAN like the GENI Mesoscale? How do aggregates define shared VLANs in RSpecs? How can we make the experimenter experience consistent? This topic may be quick. For reference, see the existing RSpec extension: http://www.geni.net/resources/rspec/ext/shared-vlan/1/ 2. Rack stitching demo at GEC15 By GEC16 our goal is to have GENI network stitching operational. As a near term goal, we anticipate doing some demos at GEC15 of operational GENI racks, showing the racks stitching amongst racks of a single flavor (InstaGENI or ExoGENI). We will discuss technical hurdles to making this a reality. 3. Experimenter Experience In coming months, we hope to have many new GENI experimenters. What can aggregate, tool and clearinghouse developers do to make it easier to get started with GENI? Of special interest is improvements to already existing tools and services. 4. Other miscellaneous topics - Update Sliver in the AM API - Questions or concerns with the GENI Portal and Clearinghouse == Session Summary == The Coding Sprint session attracted around a dozen experimenters, several operators, and around 20 developers. Experimenters got help getting started or working with GENI, operators discussed primarily monitoring, and developers worked through several issues. The developers had a productive discussion, working through AM API status and proposed changes, stitching, shared VLANs, and questions and concerns about the new GENI Clearinghouse and portal. Thank you to everyone who participated. - AM API v3 implementations are in process, - We agreed to move forward with Update() as proposed on the dev mailing list, and - We're hoping for an inter-rack stitching demo this Fall. - We worked out a plan for naming and working with shared VLANs (like the mesoscale), and - People provided several good critiques of the GENI Clearinghouse and Portal as implemented. === AM API === Aaron solicited updates from the group on the status of [wiki:GAPI_AM_API_V3 AM API v3] implementations: Planetlab is well underway, ProtoGENI will be doing their implementation soon, and Orca will likely implement v3 soon after GEC15. Meanwhile, Omni and the GCF AM will likely be updated in the next few months. ==== Action ==== - All developers should work to complete their AM API v3 implementations, and keep the community updated. === Update() === We then discussed Jon Duerig's proposal for an Update() method in the AM API (http://lists.geni.net/pipermail/dev/2012-July/000823.html). After a brief discussion, we agreed in principle to Jon's overall proposal. We still need to work through the details, but Update() may be added to the AM API in version 4. In detail: Ilia pointed out that in many instances slivers cannot be modified without losing state. This is why Jon's proposal calls for a state guarantee in the manifest RSpec. We may also want some kind of default guarantee by sliver type in the Ad RSpec. Ilia removed his objection to Update() taking a full RSpec, as long as translating the RSpec into NDL does not require a stateful translator. ==== Actions ==== - Jon Duerig will flesh out his Update() proposal for posting on the GENI wiki - All developers should read and comment on the Update() proposal === Stitching === We then moved on to [wiki:GeniNetworkStitching stitching]. First, we talked about the possibility of a GENI stitching demo between rack varieties. We agreed that this seems possible: probably starting with a rack-to-rack demo within the GPO lab, but then perhaps a demo going among RENCI, Starlight, MAX, and ProtoGENI Utah. The timing of this demo depends very much on other tasks for the rack teams, and will likely be after GEC15. ExoGENI expects to be able to first consume but then also produce a VLAN tag for stitching. Currently InstaGENI only produces tags (it cannot consume). So a demo where InstaGENI produces a tag and ExoGENI consumes it might be a first step. Rob believes it won't be hard for InstaGENI to also be a consumer of VLAN tags. Ilia warned that there are several layers of work at ExoGENI to make this work, pushing the timing for such a demo into December. ==== Actions ==== - InstaGENI will implement accepting a specified VLAN tag on a link using the stitching extension - ExoGENI will implement both accepting and producing a VLAN tag for a link terminating on a particular port on some non-AM local switch - We will plan a rack to rack demo within the GPO lab for November/December. Rob then expressed concern that the stitching workflow logic is too complex to implement in every tool. We agreed there should be a library or service to encapsulate this logic. This service should not actually submit requests to aggregates, but only determine the order of requests, and help pass tags from earlier manifests into later requests in the workflow. We also noted that negotiation makes this component complex. We decided that the stitching extension in the Ad RSpec should be explicit about whether the aggregate can be a producer of labels, a consumer, or both. Rob commented that he has a path computation service he could share. Rob also suggested that such a service should have a function allowing tools to pre-cache information about the sets of nodes that can be connected with different kinds of connections, to simplify graphical tools. ==== Actions ==== - Rob will supply his path computation service to Tom Lehman and Aaron - Tom Lehman and Xi will propose a modification to the stitching extension to advertise at each aggregate whether a given Link can produce or consume labels, or both - ISI/MAX and the GPO will continue plans for a workflow library and service === Shared VLANs === There is an RSpec extension now for specifying that requested nodes should be connected to a pre-existing shared VLAN (http://www.geni.net/resources/rspec/ext/shared-vlan/1/). We noted that the AMs do not yet support the geni.net schema location, nor the Ad RSpec extension version. We then discussed common naming of shared VLANs. We agreed these should be URNs, of the form `urn:publicid:IDN++vlan+