Changes from Version 1 of MinutesFrom30Oct2007

Author:

trac (IP: 127.0.0.1)

Timestamp:

03/26/08 18:05:12 (2 years ago)

Comment:

--

MinutesFrom30Oct2007

@@ +1 @@
+
+
+== !ProtoGENI Project Meeting, 30 Oct 2007 ==
+
+=== Agenda ===
+
+'''Important decisions to make early-on'''
+
+   * Fork Emulab?
+      * Pro: Allows us to develop more quickly, since we don't have to worry
+        about breaking existing installations
+      * Con: We may want to merge later, and that could be a pain
+   * Short-term goals: Hardware-centric or software-centric?
+      * Hardware-centric: We start by getting hardware deployed (ie.
+        getting PCs and routers deployed at various sites, and getting
+        Internet2 tunnels between them), but with the current Emulab
+        interface, APIs, etc.
+      * Software-centric: We start by getting the GENI APIs, etc. working,
+        then worry about getting the hardware deployed
+
+-- Main.RobertPRicci - 30 Oct 2007
+
+=== Notes ===
+
+'''Who/When'''
+
+   * Attendees: Rob, me, David, Jay, Leigh (phone)
+   * start @ 11:10 AM
+   * end @ 12:25 PM
+
+'''Jay: preparatory work was not done for this meeting; let's do it now!'''
+
+   * make lists of issues, tasks, priorities, schedule
+   * early operation
+   * easy things first or hard things first?
+   * think about devices; what hardware are we going to include?
+   * usage model
+   * who we get to partner with us?  time is running out; can't wait
+      three months
+
+'''Rob: suggest that we start with the issue of choosing (1) GENI API first, or (2) hardware first?'''
+
+   * Jay: go through the list of components in order to make this
+     choice.
+   * Interfaces:
+      * Advantages: finding stuff that's wrong, influence the GENI
+        design earlier, making the design better, makes us look better
+      * Disadvantages: getting stuck in design by committee, would
+        rather just "show up" with something that works with the
+        right hardware
+      * Rob: existing interfaces are narrow, 10-20 methods.  A first
+        cut at putting these interfaces on top of our stuff would be
+        mostly painless, if we ignore certain problems such as
+        security, etc.
+      * Rob: spec hardware now and order, then while we wait work on
+        SW?
+
+'''Jay: back on the partnerships...'''
+
+   * Jay: example: CMU as a "loss leader" for us; getting other people
+     to use Emulab
+   * Matt Welsh: sensor network stuff; must get him to use our stuff! 
+     If he uses PlanetLab or ORBIT, it's a "permanent loss" to us.
+      * Rob: so, what can we do about that?
+      * Jay: likely issues for Matt
+         * unreliable backhaul
+         * stuff like what MoteLab gives [what are those things?]
+   * Jay: work on the key architectural issues
+
+'''Customers'''
+
+   * General "missing features" for users; not GENI API issues, just
+      usability issues
+      * Just selling to key customers
+    * Jay: customers we have/want:
+   * Rob: would we use our own stuff on our Emulab eventually?
+      * Jay: yes.
+      * But Emulab-like testbeds have no "place" in the architectural
+        design of GENI
+
+'''Fork or not to fork?'''
+
+   * fork: free to hack; old system will degrade; ...
+   * Leigh: forking will do nothing to speed up development of GENI
+     stuff
+   * Rob: comfortable with forking
+
+'''To-do's'''
+
+   * Put these notes in Wiki on Emulab... where?
+   * Look at the proposal: ~lepreau/tb/prop/nsfmri3/
+      * Look at Section 4 in particular
+   * Jay says to look at his slides from the recent GENI meeting
+   * Look at GENI architecture documents
+      * http://www.geni.net/GDD/GDD-06-11.pdf
+      * http://www.geni.net/GDD/GDD-07-44.pdf
+   * Look at GENI slideware about distributed services
+      * http://www.geni.net/office/office_events.html
+      * http://www.geni.net/office/office_events_71007.html
+   * Think about the role of cluster-like testbeds in GENI?
+
+-- Main.EricEide - 01 Nov 2007
+
+
+