Changes between Version 1 and Version 2 of GEC23Agenda/ArchitectsMeetingSummary


Ignore:
Timestamp:
06/22/15 11:25:10 (9 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC23Agenda/ArchitectsMeetingSummary

    v1 v2  
    1 Date: 6-16-2015, 0800-0915 CT (GEC23, University of Illinois, Champaign-Urbana)
     1'''Date''': 6-16-2015, 0800-0915 CT (GEC23, University of Illinois, Champaign-Urbana)
    22
    3 Participants: Nick Bastin, Max Ott, Ivan Seskar, Mike Zink, Marshall Brinn, Mark Berman, Chip Elliott, Aaron Helsinger.
     3'''Participants''': Nick Bastin, Max Ott, Ivan Seskar, Mike Zink, Marshall Brinn, Mark Berman, Chip Elliott, Aaron Helsinger.
    44
    5 Agenda: The agenda of the GEC23 meeting of the GENI Architect team was to focus on the future of GENI from an organization as well architectural point of view. What processes do we need to make and disseminate decisions about the GENI architecture? What themes and functional capabilities should we stress? How should GENI position itself with respect to other cyberinfrastructure initiatives in the coming years?
     5== Agenda ==
     6The agenda of the GEC23 meeting of the GENI Architect team was to focus on the future of GENI from an organization as well architectural point of view. What processes do we need to make and disseminate decisions about the GENI architecture? What themes and functional capabilities should we stress? How should GENI position itself with respect to other cyberinfrastructure initiatives in the coming years?
    67
    7 Summary:
     8== Summary ==
    89
    910Several major themes emerged from the meeting.
    1011
    1112Looking at GENI going forward, there seem to be several different goals:
    12 1.      A stable GENI with relatively static capability that can be used for education and research
    13 2.      An experimental GENI with new kinds of resources (new rack/switch times and entirely new kinds of resources like GPUs and FPGAs, etc.).
    14 3.      A federated GENI that grows by linking and interoperating with other cyberinfrastructure testbeds and clouds and helps develop new standards  and technologies for federation, SDX, policy, identity.
     13 1. A stable GENI with relatively static capability that can be used for education and research
     14 2. An experimental GENI with new kinds of resources (new rack/switch times and entirely new kinds of resources like GPUs and FPGAs, etc.).
     15 3. A federated GENI that grows by linking and interoperating with other cyberinfrastructure testbeds and clouds and helps develop new standards  and technologies for federation, SDX, policy, identity.
    1516
    1617These may be conflicting goals and as GENI grows, it may evolve along different paths simultaneously. “Evolve and dissolve”: Both continue to grow and become part of what CI is prevalent in the future.
     
    1819We discussed the challenges of entropy of software and of documentation, tutorials, manuals, schemas. The obsolescence of hardware is a similar concern. One charge of an ongoing architecture team will be to push these things to be kept up with changing times and requirements or brought off line.
    1920
    20 Several of us stressed the importance of adding new innovative, even “bleeding edge” resources to GENI, that there are diminishing returns for a larger GENI consisting of the current set of resources and that different research will be driven by providng access to new and rare kinds of resources (much as OF HW switches were when the first GENI racks were being specified).
     21Several of us stressed the importance of adding new innovative, even “bleeding edge” resources to GENI, that there are diminishing returns for a larger GENI consisting of the current set of resources and that different research will be driven by providing access to new and rare kinds of resources (much as OF HW switches were when the first GENI racks were being specified).
    2122
    2223We talked about the challenges, past and future, of getting campus buy-in for GENI and how that might be alleviated moving forward. Clearly campus CIO buy-in is critical (top-down) as is researcher demand (bottom-up) and the architecture team may play a role in mediating a conversation between these entities.