Logistics

Sun 21 April 9:30 - 4:30 Madison
Mon 22 - Tue 23 April TBD

Agenda

  1. KAGRA-LIGO Self Enrollment (Lite) 
    1. User Stories
  2. LIGO External Reviewer Self Enrollment  LIGO External Collaborator Email Based Enrollment 
    1. Review offboarding and other open issues
  3. Grouper Provisioning (CO-57) (tick)
    1. What approaches, what priorities
  4. MyLIGO 3.0 Planning
    1. Use Cases / User Stories
    2. Timeline
    3. Backlog
  5. UI Stuff (tick)
    1. Cancel Button Behavior (CO-374)
    2. Search (CO-209, CO-497, and CO-139) / Filter
  6. Grand finale planning
    1. summer students who need CLI access
  7. When to tag 0.8? (tick)
  8. Sprint 14 planning (tick)
  9. Contemplate Greenhopper

Notes

KAGRA-LIGO use case

  • Scott sent email to KAGRA asking about organization, and that's not quite happening as LIGO would prefer - LIGO is looking for individual organizations, KAGRA is asserting "KAGRA" as the organization; this is not a show stopper
  • there is no approval step, since if they can enroll to an IdP they are part of KAGRA; still, attributes like Validity should not be a self-asserted attribute
    • LIGO is looking to move to a fixed validity range where everyone will be forcibly removed if the PI hasn't been updating participant information
    • what happens at renewal time? Do notifications go out? we need to focus more on expiration process
      • think along the model of exponential decrease in notifications
      • in the KAGRA use case, to whom do the notifications go? who has the authority to change validity? The CO Admin
    • if there is self-enrollment, should there be self-renewal? that is up to KAGRA, but for initial use case we will have this be the CO Admin
  • want to get the concept of caveats and exceptions as an intrinsic part of notification
    • notifications will require a great deal more spec'ing out
  • for initial deployment, Sponsor will be fixed, not self-asserted
  • Remember, this is the first priority; we have to deploy in production and then refine; need to try and roll this out this summer
    • provisioning work (item 7 in the use case) is close
    • the fixed attribute tickets will be fast when we get to it
    • the LANG column will be intrusive, and we need to fix this for the name rendering issue
    • then notifications
    • then groups
  • Off-boarding
    • people will either expire out or be manually removed by the CO Admin; what happens to LDAP and Grouper when COmanage takes a user from active to inactive? What happens now is if your status changes to inactive, then something will trigger provisioning to run, provisioning will then run for each configured module and send a delete message and get dropped from the LDAP; if we don't want that, we need a grace period
      • removing them from LDAP will cause difficulties with Grouper
      • LDAP should not be the Registry -> in normal circumstances, a record will be removed from the LDAP but not from the Registry; this will be problematic for LIGO (moving past the KAGRA use case); we may want to try the "right" way for KAGRA to see if/how it would work for LIGO
      • we should consider adding a way to order the provisioning modules

LIGO External Reviewer - Email Based

  • if the primary goal is the KAGRA use case, do we need to deal with this other use case at this time? Yes, but it should be fairly incremental work over the KAGRA use case
  • moved this up to next priority after KAGRA and before External Reviewer Self Enrollment

Grouper discussion

  • General dev discussion - see Scott for notes on potential rescoping of group effort (implement Chris Hyzer's features, point to grouper loader for sites more grouper-savvy, then call this effort done)
  • Scott will work on fixing work he's already done based on Benn's commit changes; then will leverage Chris Hyzer's enhancements; then call this done; step 2 will be a loader (easier and standard from a Grouper perspective) or a COmanage provisioning plug in (fits the COmanage architecture)

MyLIGO 3.0

  • with priority to KAGRA, we need to come back to this at a later date
  • want to do the MyLIGO 3.0 planning after we have a production KAGRA COmanage instance
  • the latest thing being bolted on to MyLIGO 2.5 is being able to manage through the web interface consul memberships; we will treat that as an application plug in on the side, but it will have to be written
  • also bolting on the default expire and notification emails, which means that will be another thing we have to have in MyLIGO 3.0
  • we have promised MyLIGO 3.0 by end of this calendar year

Greenhopper

  • might be useful, not blow-your-socks-off useful; Benn submitted request to TSG to enable that plug in (if it's free)

Sprint Planning

On the roadmap, we have more to accomplish to get to .8, but we have resolved as many tickets at this point as we did before tagging .7

  • given the current functionality, will do a short sprint to finish up some immediate work and then tag .8

Other topics

  1. Demo walk through
  2. Find Paul Caskey re: where Texas stands in being ready to work on and adopt COmanage
  3. iPlant
  • No labels