Changes between Version 6 and Version 7 of GEC18Agenda/CodingSprintTutoring


Ignore:
Timestamp:
10/29/13 15:26:25 (10 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC18Agenda/CodingSprintTutoring

    v6 v7  
    6666interest to the ops/admin community.
    6767
    68 {{{
    69 #!comment
    7068== Session Summary ==
    7169
     
    7977
    8078Overall, developers agreed to:
    81  - Collect ports used by GENI services, for use in testing networks for tutorials
    82  - Implement a `geni-get-info` script for each compute aggregate and substrate to provide slice and aggregate information within a node
    83  - Negotiate a new AM API v3 operational action for changing SSH keys installed on an existing node
    84  - Some conventions for tools to work with the ExoSM, an aggregate of aggregates
    85 
    86 === Developer Coding Sprint Session Details ===
    87 
    88 Niky raised the issue of running tutorials on new networks, where
    89 ports may be blocked. InstaGENI and ExoGENI agreed to provide lists of
    90 the ports their services use.
    91 
    92 Following on from the [wiki:GEC17Agenda/UniformExperimenterExperience Uniform Experimenter Experience session], we
    93 discussed what information experimenters would like to have available
    94 from within a reserved compute resource. Starting with wish lists from
    95 GENI Desktop, the data currently available at InstaGENI and ExoGENI,
    96 and other voices in the room, we compiled a consolidated wish
    97 list of information, including the local `client_id`, the
    98 aggregate URN, the slice manifest, and user accounts and SSH keys. We
    99 discussed how to get this data, and noted that the actual mechanism
    100 would depend on the aggregate and substrate (VM vs bare metal). To hide this, we agreed to provide a
    101 common script that could be available at all aggregates, whose
    102 implementation would hide the aggregate specific differences. We
    103 agreed to work out the implementation details in coming weeks.
    104 
    105 Following on from the Developer sessions, we discussed how to provide
    106 `Update()`-like functionality, before a full `Update()` is
    107 implemented. We agreed that aggregates could update the installed SSH
    108 keys using a new operational action with
    109 `PerformOperationalAction()`. The GPO agreed to propose something, and
    110 has since posted a proposal on
    111 [wiki:GAPI_AM_API_DRAFT#ChangeSetQ:Supportchangingusersandkeysonexistingcomputeslivers the AM API Draft wiki page]. Rob Ricci suggested that with some
    112 changes, InstaGENI experimenters could make an aggregate-local LAN
    113 shared, and then connect new nodes to this shared LAN. InstaGENI will
    114 work to add this capability.
    115 
    116 We then discussed how to support the ExoGENI ExoSM in tools. The ExoSM
    117 is an aggregate of multiple component managers, and this breaks some
    118 assumptions in existing tools. After some discussion, the solution
    119 appears to be that the sliver_id in manifest RSpecs will reflect the
    120 aggregate that issued the reservation, while the component_id and
    121 component_manager_id will reflect the component manager (i.e. the
    122 specific ExoGENI rack). Note that tools will require some extra
    123 workflow to identify the aggregate where the experimenter wants a
    124 reservation, and to deal with unbound requests.
    125 }}}
     79 - Post a specification for the `geni-get` tool that lets you get slice information from inside a node. ProtoGENI implements this, and ExoGENI will look at implementing this. If there are ProtoGENI images missing the latest `geni-get` client, contact protogeni-developers.
     80 - Ilya agreed to implement the new `PerformOperationalAction` action for updating installed SSH keys by GEC 19, as [wiki:GAPI_AM_API_DRAFT#ChangeSetQ:Supportchangingusersandkeysonexistingcomputeslivers documented] and already implemented at ProtoGENI. Note that the proposal allows implementing `PerformOperationalAction` as part of an AM API v2 aggregate.
     81 - ProtoGENI agreed to implement `PerformOperationalAction`s to make an existing LAN shared and then make it not shared later. This would be used to let an experimenter add a node to an existing slice. It could also be used to connect two slices. They will define some semantics.
     82 - Ilya described the 'stitch port' concept in Orca that allows connecting to any interface in their defined (advertised) topology. It could be used to connect 2 stitch ports, or 2 slices. Rob described a similar model in ProtoGENI, using a `node` (say, 'ION'), that might have multiple interfaces. Then you can connect to arbitrary interfaces as well. Xi notes that this does not need to be involved with the stitching extension or the SCS. We will follow up via email on representing this in RSpecs in a consistent way.
     83 - Common OS images: Rob and Ilya agreed to pick a single OS version for which they will continue to support an image and make that the default image. This is likely to be Ubuntu 12.04. The next action is for Rob to pick an OS from a list sent by Ilya. Additionally, Rob described an Emulab website interface for converting an Openstack image into a ProtoGENI XEN image. Rob will send a pointer to Ezra and Mike for them to try using an ExoGENI image, and then fix any issues they discover.
     84 - Niky raised a question of how the developer community (including tools, aggregates, clearinghouses) can support experimenters as a group, and get experimenters to support each other. We agreed to support a Google groups mailing list (which is better indexed for searching than a regular mailing list). Additionally, the GPO experimenter support group will investigate deploying a GENI Stackoverflow equivalent.
     85 - Niky noted that supporting long lived slices remains difficult. Leigh noted that in the end, this is a per aggregate policy. Niky noted she wants the permission to apply to all members of a slice. We discussed using credential delegation, special credentials, and overall policies. We tentatively agreed that Slice Authorities could issue slice credentials that include a special privilege. Then aggregates can choose (or not) to honor that credential in a call to `Renew` or `RenewSliver`. We will follow up via email on the name of this privilege, whether this is a 2nd slice credential or the only slice credential, and on possible Slice Authority APIs for requesting and retrieving these credentials.
     86 - We also discussed [wiki:GAPI_AM_API_DRAFT#ChangeSetR:AllowRenewtoextendsliversasmuchaspossible a new option] to `Renew` and `RenewSliver` to let experimenters request their renewal to go as long as possible, even if local policy does not allow renewal to the requested time. This [wiki:GAPI_AM_API_DRAFT#ChangeSetR:AllowRenewtoextendsliversasmuchaspossible proposal is posted on the GENI wiki], and was adopted. Additionally, the developers of the ProtoGENI/InstaGENI, ION/MAX, Orca/ExoGENI and FOAM aggregates agreed to implement this change.
     87 - Marshall described the planned roll out of the [wiki:UniformClearinghouseAPI Uniform Federation API]. The GENI Clearinghouse will be using/supporting this in the next couple months. ProtoGENI will also be implementing and supporting this API. Omni will be able to also contact any Clearinghouse supporting this API. Fed4Fire and Ofelia have also been involved in developing and testing this API.
     88 - Speaks For: We agreed that the format of the speaks for credential will be ABAC on the wire. The Speaks For signing tool will support this format by the end of November. GCF will support this by the end of November (in a pre-release form). The ION/MAX aggregate depends on SFA for credential handling. GPO will supply Tony Mack with python code for handling the ABAC speaks for credential. Ilya says he will try to support this by the next GEC (with a long list of caveats). We will aim for mid February, in hopes this can work at a tutorial. The GENI Portal will use Speaks For in this time frame as well.