XSEDE Home
Space shortcuts
Child pages
  • WBS 2.3.2 RDR Next Phase 2021-08-25 Meeting
Skip to end of metadata
Go to start of metadata

Dates

 

Agenda, Discussion, and Action Items

Agenda & Discussion

Topic(s)

  1. Quick review of RDR plan (all)
  2. Update on what was recently delivered (Liz and Rob)
  3. Share new SP Coordination request (Tabitha and Liz)
  4. Discuss what the next priorities should be
    1. Combining earlier and more recent requests and plans
    2. Factoring what is worth doing and turning over to XSEDE's successor

Discussion

Recent deliverable (Liz and Rob)

  • Primarily surface level user interface changes that make it friendlier for enter new resources
    • Use a sequence of screens to enter base resource and partition information
    • No longer enter duplicate or redundant information in both base resource and partition
    • Only have one resource name per previously discussed rules
  • Each resource has one partition now, if we want to re-introduce multiple partitions that could be done in the future
  • Centers that had entered resources as sub-resource have been split into separate resources
  • Learned that future testing should include the API

New SP Coordination request (Tabitha)

  • Several spreadsheets are being used to track SP Coordination related  information about resources
  • Would like to consolidate all that information in RDR
    • These are primarily of internal interest to SP Coordination and other WBS groups
    • Most of the fields can be public and exposed through publish APIs
    • Would like an SP Coordination Notes field that would NOT be public

Next priority

We agreed to implement Phase 2 using Tabitha's SP Coordination request as the pilot.

Phase 2 would implement configurable field groups and fields that can be associated with a resource and be managed without having to modify RDR code or the underlying data schema:

  • A way to define new field groups and their fields
  • A way to enter/edit field groups for each resource
  • Tabitha's fields would become part of a new "SP Coordination" field group
  • Some storage options:
    • denormalized table with pk(resource id, field group name, field name) plus a field value
    • normal table with pk(resource id, field group) plus a JSON object with field names and field values

Some have concerns that it's possible for fields entered by some to be changed by others:

  • Maybe finer grained permissions associated with field groups could address this?
  • Liz to explore finer grained security.

We want to make sure that this increased flexibility doesn't create complexity.

Before starting Phase 2 Elizabeth Pantalone plans to upgrade Ruby and perform other maintenance and fixes.

Action Items

Attendees