== !ProtoGENI Project Meeting, 06 Nov 2007 ==

'''Who/When'''

   * attendees: Jay, Mike, Rob, David, Leigh (phone), Eric
   * start @ 11:10 AM
   * end @ 12:40 PM

'''Fork or Don't Fork the Emulab Code Base?'''

   * Leigh and Mike argue that we should [not] fork the code base
      * must have users for direction, testing, debugging
      * one code base is easier to keep up-to-date than two
      * we don't have people who are dedicated to the GENI project;
        all our people must work on GENI and production Emulab
        concurrently
      * 90% code/functionality overlap suggests not to fork; we would
        need to copy bug fixes back and forth
         * Rob: we currently commit several bug fixes per week,
           mostly committed by Leigh
      * Rob: look at what's happened to !PlanetLab
   * Jay argues that we should fork the code base
      * freedom to hack --- getting our developers to "change vision"
      * bugs in our GENI base are OK
      * instability is OK
      * a fork is a temporary thing; in one or two years, they will
        be remerged
      * Jay: "I don't care that much if the Emulab base has quality
        degradation."
   * Eric: is there a middle ground?  Can we componentize the code,
     and then fork only the parts that are needed?
      * Rob: this would be in conflict with the !ProtoGENI "develop
        fast" constraint
   * Rob: reasons to fork
      * assign_wrapper: must change, with systemic effects; touching
        lots of bits
      * Emulab and !ProtoGENI need different terminology; different
        user interfaces and other front ends
   * Mike: forking is "the death of Emulab"
      * fork represents that fact that we're moving on
      * we just won't have time to maintain both
   * Jay: what about the workbench?
      * must run on regular Emulab, where we already have users
      * so we must keep Emulab alive
   * Final comments
      * Jay: our !ProtoGENI work can be "successful" even if GENI fails
      * Jay: generalizing Emulab is important in its own right
      * Leigh: OK to table this for now
         * eventually we will get to a point where fork versus
           non-fork matters
      * Jay: free your mind to rearchitecting Emulab!
   * Resolution: table the discussion for now

'''GENI Abstractions'''

   * Rob: the stuff in the !ProtoGENI docs may not look a lot like what
     we have now...
      * ...but indeed, Rob believes that we can map a lot of the
        !ProtoGENI API onto our existing abstractions and
        implementation
   * Leigh: not worried about implementing the basic !ProtoGENI API;
     he's worried more about other issues
      * virtualization
         * with vservers
      * security model: model is so poorly specified
         * Jay: lead or follow in this area?  Following is more
           work-efficient, but leading might be faster in the sense
           that we get what we like
         * delegation is an intrinsic part of the model
         * infrastructure required for handling keys
         * Rob: implement something simpler than the full GENI
           specification, because the specification may never be
           fully fleshed out
            * we implement a similar API
            * come up with our own ways of doing certain things,
              e.g., signing
            * we store the bags of bits for users
   * Jay: what about collaborating with outside folks about security
     stuff?
      * Steve Schwab wants to collaborate with us
   * Handling virtualization
      * Jay: what about the shared node stuff?
      * Leigh: we don't really have the concept of a shared node at
        all in our core system
         * we cannot share a node between projects
      * Rob: the model that we already have for the !PlanetLab nodes
        is what we can go with
         * component == physical node
         * slivers == resources
         * as far as the database goes, we're not that far from what
           we need
      * Question: do we want !ProtoGENI to work on !PlanetLab nodes?
         * "break it and then fix it"

'''Node Manager'''

   * David was going to look at the node manager stuff, but was on
     vacation and didn't have time
   * Initial thoughts: do not take the schema wholesale; take some of
     their schema
   * Otherwise, we can take a lot of stuff from the node manager

'''Action Items'''

   * Leigh [carryover from previous meetings]: look at how we are
     currently unfaithful to XMLRPC or SOAP standards
   * Rob: work more on software list
   * Mike and Rob: list the features we don't have now to set up a
     GENI experiment?  "List of things that must be fixed."
      * e.g., shared nodes other than !PlanetLab nodes
      * e.g., we don't have tunneling to !PlanetLab nodes

-- Main.EricEide - 07 Nov 2007