Logistics

Mon 09 Sept - Tue 10 Sept
10 - 5
705 Pupin, Columbia University

Agenda - Monday

  1. Review current KAGRA-LIGO deployment (tick)
  2. Review use cases
    1. KAGRA-LIGO Self Enrollment (Lite) (tick)
    2. LIGO External Collaborator Email Based Enrollment (tick)
      1. GWnu
      2. LIGO-Condor
  3. MyLIGO 3.0 Planning
    1. Review of current MyLIGO functionality (tick)
    2. Use Cases / User Stories
    3. Timeline (tick)
    4. Backlog
  4. Release Planning (tick)

Agenda - Tuesday

  1. LIGO as the IdP of first resort and COmanage (see LIGO-COmanage Deployment Architecture) (tick)
  2. MyLIGO 3.0 Planning (tick)
    1. Use Cases / User Stories (tick)
    2. CO Group provision a mailing list vs LIGO weird use cases vs Grouper integration vs MailingListProvisioners (tick)
    3. CO-311 vs Should enrollment flows be configurable to ignore $ENV variables (tick)
  3. General UI discussion (tick)
    1. Review /registry/co_people/index layout (tick)
    2. Drag-and-drop (tick)
    3. Navigation Links (tick)
  4. Searching (tick)
  5. Sprint Planning (tick)
  6. Directory - Postponed
  7. Screencast - Postponed
  8. Upcoming Stuff (tick)
    1. Educause Session (tick)
    2. LIGO Hannover Meeting (tick)
    3. VAMP, etc (tick)
    4. Identity Week (tick)
    5. KAGRA f2f (tick)

Notes

Review current KAGRA-LIGO deployment

See https://gw-astronomy.org/registry

  • Petitions
    • it would be helpful if it would be able to not show by default the approved petitions; a filter that made it possible not to see approved petitions and yet be easy to be able to add them back when necessary
    • by default, have approved filtered out and have the display by created order (oldest first)
    • new ticket: CO-680
  • Pending confirmations
    • if you click on the email icon, does that resend the invitation? at least looking at the code, this (probably) does the correct thing
  • What about name?
    • Remember - deep, dark road to perdition to try and require family name
  • Review use cases
    • KAGRA-LIGO Self Enrollment (Lite)
    • LIGO External Collaborator Email Based Enrollment
      • GWnu
      • LIGO-Condor
    • Right now, the only major blocker for these use cases is the notification, which is part of the v 0.9 roadmap
    • we could also use the administrator enrollment process as a workaround for the LIGO-Condor use case
    • we will start with the external collaborator use case to drive notifications, and apply this to KAGRA later
    • CO-659 is the required ticket, and CO-207 is required for that; it is not terribly well specified, so we need to get through what we can then close the tickets and we see what's left
  • MyLIGO 3.0 Planning
  1. let people enroll and state what COU they are in (self-select which one they are applying to) - (tick)
  2. when an individual goes through a flow for the LSC, need to be able to collect whether they are admin support (an extended attribute)
  3. need to have a separate flow for VIRGO members; collects very little info (see basic info collection form on 2.5)
  4. there should be a COU or COU Roles person that gets a notification about the petition and a link to approve (or not) the petition
  5. an individual may be a member of several COUs, but the approvers should only see an individual's petition to their COU
  6. notification and approval roles and approval delegation are the key points
  7. once the external collaborator use case works, we can suggest that LIGO uses that rather than the current 2.5 process
  8. if you have pending petitions, then you have the ability to process the petitions; you also need to be able to manage things like the FTE percentage (the extended attributes)
  9. manage council delegates will take advantage of some simple group management on a per-COU basis; this may need to be a plugin for LIGO to write that may use Grouper (or the native group management); i twill include provisioning in to a very specific LDAP attribute
  10. will need to flag one of the possible email addresses as primary and have the others on record in other attributes; need them so we can say "these are the addresses from where the mailing lists will accept email"
  11. reporting might be interesting as well; consider some simple reporting (though more detailed features would be a plugin)
    • CO Group provision a mailing list vs LIGO weird use cases vs Grouper integration vs MailingListProvisioners
    • CO-311 vs Should enrollment flows be configurable to ignore $ENV variables
    • Timeline
      • Initial set up in October in prep for the October 18 meeting with Scott, Melody
    • Backlog
      • need to set up a COmanage LIGO instance and import the data to see what might actually be missing; need to free up time for Scott to do this
  • Release Planning
    • Have 0.8.2 pending, then 0.9, then 1.0; will we need any interim releases? Probably will need a series of 0.9 releases before we can truly call a 1.0 release
    • are there tickets that MUST be resolved before 0.9? Do we want to tag 0.8.2 now and create an 0.8.3 before our 0.9? Desirable, but we need to lok at the grouper plugin work and when it might be ready = aiming for end of October
    • will tag 0.8.2 this week; everything not done will move to 0.8.3 (target to complete in October), and leave 0.9 as is (focusing on notifications)

Tuesday's notes

  • LIGO as the IdP of first resort and COmanage (see LIGO-COmanage Deployment Architecture)
    • is there a way to handle the IdP issue, and have COmanage call it at the appropriate points in the process?
    • the LIGO IdMS populates Kerberos, which is exposed to Shibboleth
    • when LIGO can fully take advantage of federated identity, the above component will go away, and there will be a LIGO COmanage that feeds an LDAP and the LDAP is exposed to a Shib instance
    • right now, those two components are merged; the architecture described forces a discrete separation of those two functions so we can more clearly drop the former when necessary
  • MyLIGO 3.0 Planning
    • CO Group provision a mailing list vs LIGO weird use cases vs Grouper integration vs MailingListProvisioners - see CO-426 and CO-685
    • CO-311 vs Should enrollment flows be configurable to ignore $ENV variables - not going to deal with this until we have a more urgent use case
  • General UI discussion
    • Review /registry/co_people/index layout
      • Benn: getting better, but may still be too hard to read and wastes too much space; maybe go back to the table layout that the other windows have, and have a pop-up/mouse over
      • Scott: things it does look better than what we have now, but would like to see all the pertinent information when actually doing the drop down (name, email, role, etc); however, that might defeat the purpose of having the detailed page; at the end of the day, the goal is to be able to determine if you have the right person
      • general consensus (for now) leave this as is, and we can come back to it if it proves to be a problem
    • Drag-and-drop
      • good - commit it
    • Navigation Links
      • Marie to work on this further
  • Searching
    • we have initial advance search implemented, and we have CO-209; given we know that Stewart will have further requests, holding off on further work here for now (Marie to commit the existing work) and will come back to it when we have further requirements
    • see CO-209 in particular; will need some further thoughts/recommendations prior to meeting with Melody/Steward in October
  • Directory? - postponed
  • Screencast - postponed
  • Upcoming Stuff
    • Educause Session - 30 minute basic presentation
    • LIGO Hannover Meeting - no specific COmanage presentations
    • VAMP, etc - Heather and Benn to prep after we have more info from the coordinators
    • Identity Week - presentation at CAMP on Friday (repeat of A)
    • KAGRA f2f - planning in progress
  • No labels