Logistics

When

Monday July 9 through Wednesday July 11
Developer days July 12-13 for Scott and Marie

Development meeting July 12-13
(Dinner for those present Sunday July 8)

Location

The meeting will be held at the UWM School of Continuing Education in downtown Milwaukee:

  • 161 West Wisconsin Avenue, Milwaukee, WI 53203
  • Google maps
  • Enter from Wisconsin Avenue and look for the elevators on the right. Take the elevator to the 7th floor. Rooms are around the lobby to the left.
  • We will meet in Room 7310

Time

We have the room each day from 09:00 until 17:00.

Agenda

  1. Reconfirm/Reschedule scrum and dev meeting times (tick)
  2. I2MM f2f: Dev meeting tentatively all day Sunday (subject to REFEDs, etc) (tick)
    1. Do we need/want another f2f before then? Or before VAMP? (tick)
  3. Sprint08 Planning (tick)
    1. See also high level roadmap (tick)
    2. Tag 0.6? (tick)
    3. Do we want to flag tickets that need to get resolved during a sprint differently from those that just need some progress? (tick)
    4. Split cleanup tickets out of FUTURE and create a CLEANUP release? Or just tag as cleanup and do a cleanup sprint after the fall member meeting? Or is 1.0 the "CLEANUP" release? (tick)
    5. Work for COmanage+Conext Demo (see also VAMP meeting agenda item, below) (tick)
      1. New JIRA labels: vamp, cocoa (tick)
    6. Provisioning Implementation (see also plugin and provisioning agenda items, below) (tick)
    7. Update to Cake 2.2? (CO-369; Needed for CO-368) (tick)
  4. VAMP meeting implications
    1. VOOT and COmanage (CO-376) (tick)
    2. Email based invitation (CO-308) (tick)
    3. Authorization (tick)
    4. Grouper integration (CO-268) (tick)
  5. Grouper + COmanage: is a proper model to use COmanage to define roles and grouper to manage the groups those roles imply? (tick)
  6. Registry Enrollment Flow Configuration (enumerate enrollment patterns) (tick)
  7. svn vs git (tick)
  8. Directory UI (tick)
  9. Registry UI (tick)
    1. COU Admin Menu/Dashboard (CO-354)
    2. AJAX Field Editing (CO-361)
    3. Clean up black menu bar
      1. Drop "fake" notifications (CO-382)
      2. Default values for News | Support | Directory | Help? (CO-222)
    4. Default focus for various forms should be on the first editable element, not the black menu bar (CO-383)
    5. Back button (CO-374)
    6. Save button in wrong place (CO-360)
    7. Make Directory look like Registry (CO-380, CO-381)
    8. Improve Menu CO handling (CO-384)
  10. Registry API Authz (CO-91) for Directory (CO-307) (tick)
    1. OAuth?
  11. Plugin Architecture (CO-354), e.g. for LIGO's "Manage My Delegates" and Provisioning From Registry (draft model) (CO-188)
  12. Provisioning From Registry (draft model) (CO-6) (tick)
    1. Which LDAP model?
    2. Impact for code integration for plug-in vs native support?
    3. Kerberos plug in for LIGO
  13. Registry Dashboard (CO-348) (tick)
  14. When Registry is used as an IdP of last resort, what is populated into Org Identity tables vs CO Person tables? Does identifier assignment need to run for Org Identities if the former? (IA is currently attached to CO.) (tick)
  15. What identifiers should be defined by default? (tick)
    1. Note CoIdentifierAssignment.php has a copy of the default list as well as Identifier.php
  16. InCommon Silver, LIGO 2FA, etc (tick)

Agenda for Scott and Marie on Thursday/Friday

  • UI - customizations for LIGO
    • color scheme/theme/logo
    • LIGO-specific administration menus
      • council delegate administration requirements/implementation (CO-181)
    • Other LIGO-specific plugins?
  • Code to interact w/ grouper to set up template groups
    • interface design
  • Django based ligo certificate authority
  • LIGO-specific enrollment flows

Potential side conversations

  • LIGO two-factor
  • Benn/Steve Directory (after lunch, Monday)
  • long-term future of COmanage

Notes

1. Reconfirm/Reschedule scrum and dev meeting times

  • will retain M/W/F meetings, 2 scrums and a Dev call
  • no call this Friday, e-scrums next week, July 27 cancelled

2. I2MM f2f: Dev meeting tentatively all day Sunday (subject to REFEDs, etc)

  • agreed to Sunday in Philly, start @ 9am

2a. Do we need/want another f2f before then? Or before VAMP?

  • No time

3. Sprint08 Planning
Dates: Sprint08 = July 09 - August 5
Sprint09 planning meeting: August 6
Sprint 09 = August 6 - August 31

  • 177, 183 and 196 and their children need to be cleaned up and refactored

3a. See also high level roadmap

  • roadmap adjusted: grouper integration moved to .7, VOOT integration added to .7

3b. Tag 0.6?

  • aim to tag .6 by the end of this week, which means means we need to drop the Grouper work to .7

3c. Do we want to flag tickets that need to get resolved during a sprint differently from those that just need some progress?

  • no reason to make a change at this time

3d. Split cleanup tickets out of FUTURE and create a CLEANUP release? Or just tag as cleanup and do a cleanup sprint after the fall member meeting? Or is 1.0 the "CLEANUP" release?

  • FUTURE release is already large; want to be able to tell the difference between new feature requests versus cleanup; there are things that will need to get done before we release 1.0 and they need to be differentiated as well
  • pull out the ones that need to be done before 1.0, leave the rest in FUTURE

3e. Work for COmanage+Conext Demo (see also VAMP meeting agenda item, below)

    • New JIRA labels: vamp

3f. Provisioning Implementation (see also plugin and provisioning agenda items, below)

  • clean up tickets for Sprint-08 then come back and have more lengthy conversations about this

3g. Update to Cake 2.2? (CO-369; Needed for CO-368)

  • part of identifier assignments uses extended identifier types; won't use extended types for anything other than identifiers since the work is a significant not-terribly-stable hack until one gets to 2.2; also easier to map REST calls with a new feature in 2.1
  • note that cake 3.0 is likely to be an almost full re-write for COmanage
  • schedule this work after the demos this fall

4. VAMP meeting implications
4a. VOOT and COmanage (CO-376)

  • more info: https://github.com/andreassolberg/voot/wiki/Protocol, http://openvoot.org/voot-2.0.html
  • need to ask the SURFnet guys: do they have a test instance that we can work against, need to understand if the following model is how it all works:
    • 1. Browser <-> IDP
    • 2. Browser <- Conext portal (SAML + request)
    • 3. Conext portal -> Browser (OAtuh request)
    • 4. Browser <-> COmanage (OAuth authZ)
    • 5. Browser -> Conext portal (Request + token)
    • 6. Conext portal -> COmanage (VOOT + token)

4b. Email based invitation (CO-308)

  • useful for LIGO approach (though would rather not have an external dependency for the demo)

4c. Authorization

  • need to ask SURFnet folks about what they need/expect wrt authorization

4d. Grouper integration (CO-268)

  • Scott will keep working on that, need better notes in the ticket to help us remember what we decided last time (in notes from I2SMM12?)

5. Grouper + COmanage: is a proper model to use COmanage to define roles and grouper to manage the groups those roles imply?

  • we want to use grouper as source for all things groups, and CO/COU membership includes group membership; we want to have that information reflected one way or the other in grouper; we need to convey to people how they should be using the tools: adding roles in COmanage, and those roles get mapped to some set of group memberships and this will tie back to the other grouper ticket (CO-57); maybe having information on a default way to create groups, how COmanage will populate the information in grouper by default
  • the "preferred" deployment model is that the grouper subject source is derived from COmanage (part of CO-315)

6. Registry Enrollment Flow Configuration (enumerate enrollment patterns)

  • an early step towards documentation
  • this points out the Flows on the main page should probably be archived and replaced with Registry Enrollment
  • in particular, we need to flesh out the "Common Enrollment Patterns" on that page
  • need a slide in our standard slide deck to show the options in a more discrete format (3 columns, 6 rows, noting last two possible rows don't make sense)

7. svn vs git

  • Request sent to TSG, with no response; are we at the point where we need to do a migration? No, not at this time; will bring this back up at the I2FMM12

8. Directory UI

  • will need to clean up the 1 page of the UI, start by making it look as much as possible as the Registry UI

9. Registry UI
9a. COU Admin Menu/Dashboard (CO-354

  • with Marie already working on some of the integration issues for LIGO, this ticket is likely to be reassigned to her; Benn to update

9b. AJAX Field Editing (CO-361) - moved to Future release

9c. Clean up black menu bar
i. Drop "fake" notifications
ii. Default values for News | Support | Directory | Help?

9d. Default focus for various forms should be on the first editable element, not the black menu bar

9e. Back button (CO-374)

9f. (CO-360) - assigned to Marie in Sprint08

10. Registry API Authz (CO-91) for Directory (CO-307)
10a. OAuth?

  • for the early releases of Directory, we can hardcode authorization (NOT a longterm strategy)
  • other than VOOT and Directory, we have no other use cases

11. Plugin Architecture (CO-354), e.g. for LIGO's "Manage My Delegates" and Provisioning From Registry (draft model) (CO-188)

  • discussed in item 9
  • some provisioning will be tightly coupled with COmanage, some won't be (special VO use cases) and that's why we have the plugin

12. Provisioning From Registry (draft model) (CO-6)
12a. Which LDAP model?
12b. Impact for code integration for plug-in vs native support?
12c. Kerberos plug in for LIGO

  • Benn to update ticket(s)

13. Registry Dashboard (CO-348)

14. When Registry is used as an IdP of last resort, what is populated into Org Identity tables vs CO Person tables? Does identifier assignment need to run for Org Identities if the former? (IA is currently attached to CO.)

15. What identifiers should be defined by default?
15a. Note CoIdentifierAssignment.php has a copy of the default list as well as Identifier.php

  • No labels