Agenda, Discussion, and Action Items
Agenda & Discussion
- Quick review of RDR plan (all)
- Update on what was recently delivered (Liz and Rob)
- Share new SP Coordination request (Tabitha and Liz)
- Discuss what the next priorities should be
- Combining earlier and more recent requests and plans
- Factoring what is worth doing and turning over to XSEDE's successor
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
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 Liz Pantalone plans to upgrade Ruby and perform other maintenance and fixes.
- Tabitha Samuel will provide Liz Pantalone with a detailed list of desired fields
- Liz Pantalone will define a new JIRA task to track this effort
- Liz Pantalone will reach out to JP Navarro and Shava Smallen when progress meetings would be helpful