Progress‎ > ‎Meeting Minutes‎ > ‎

9/16/2010

Notes by: Jia
Edited by: Mamta
Time: 1:30pm-3:30pm
Attendees: Eric, Mamta, Jia
Agenda: Go through the specification document (Goals, Timeline and Deliverable)

Discussion details:

1) Goals: Modify current goals to
  •  decided to use google calendar API.
  •  small number of resources so do not have requirement to scale up.
2) Non-Goals: Apart from goals, also list non-goals precisely.
  • no scale up requirement
  • only standard security needed
  • no need to do federation of testbed
3) Design
  • decided to deploy project to Testbed controlled node instead of Google App-Engine.
  • web services are preferred. APIs such as retrieve user/project/resource info are needed.
  • one user could belong to several projects; one project could have several users.
  • user account would have different types: project admin and project participant.
  • let user help themselves as much as possible: they could create login for user, add/remove user from/to project, every user could do everything to the project they belong to (They could modify reservations made by other user within the project).
  • things need to concern: when user modify their password, it should be updated across the entire testbed.
  • for scheduling part, instead of auto generate scripts, we'll provide web service which enable testbed environment configuration codes could get            information they need. Like the username/password, time slot, setting parameters, etc. The reason not auto generate configuration code is (1) They are in different language( C, Java, Script); (2) Both our project and script could have bugs, if auto-generate, it is hard to track the problem.
  • each resource has a default value, either shareable/not shareable. But the reservation system should enable admin manually toggle this                    parameter if  needed.
  • each resource have its own calendar, store the reservation status (time, date, duration, project, etc); Each project have its own calendar, provide granted time slot (not resources reservation time slot).
  • reservation system should provide ability to establish resources reservation template for project. By using the template, each project could directly use template to reserve resources rather than go to each resource to do reservation. But we still provide the ability to reserve resources one by one.
4) Timeline and Deliverable: testing should be done before deployment so change the timeline accordingly

5) Screen Flow
  • explicitly include Project Account, provide Project Management and User Management section for administrator.
  • for resource reservation flow, currently don't need to provide complex forms. (For example, current manual resource reservation would ask "Do you need to install software ?" if he want to reserve a host. For now, we could omit this kind of question, just provide simple reservation form.)
6) To Do
  • read Testbed Operation Manual asap
  • familiar with reservation work flow
  • write draft of resources by next Monday/Tuesday
  • think an easy to remember and pronounced project name
  • estimate time needed per person each week
  • check how Google calendar deal with conflicts
7) Next Meeting Agenda
  • review manual process of resource reservation with task details
  • review data structures for project, users, resources and calendar
  • review resources dependency graph
  • review how to interact between reservation system and testbed