Grouper Call of Nov. 30, 2022

Attending 

  • Chris Hyzer, Penn, Chair
  • Shilen Patel, Duke
  • Vivek Sachdiva, independent  
  • Chad Redman, UNC
  • Carey Black, Purdue
  • Drew Aschenbrener, Internet2
  • Emily Eisbruch, Internet2

Note this was an off week call as the Nov 23 Grouper call was cancelled. 

New Action Items

 Nov 30, 2022 -  Chris clarify wiki around config properties for External Systems

Nov 30, 2022 -  Chris change millisecond to timestamp on  Grouper data field and subject source next generation


Discussion

 Administrivia

Semantic Versioning for Grouper

  • We haven’t been using it
  • Has been discussed at Component Architects call
  • Versioning & Support Policy
    • We will need to do some re-educating of the community on the new approach.
    • Release notes page explains what are the stable releases
    • COmanage project uses “RC” for release candidate
    • Under this proposal , the number will be more meaningful
    • Matt: should be a linear progression
    • Even numbers (semantic) versus odd  (release candidates)
    • Does not have a dash
    • Jumping between 2 threads of numbering schemes

 Suggestion for "semantic versioning" (potential for future)

There is a suggestion to adopt semantic versioning.

The development, upgrades, and releases are not really going to change, but the numbering of the versions will change.

Here is the suggestion:

v2.5.67 (or whatever release we are on) will stay with legacy versioning strategy

v2.6.19 (or whatever release we are on) will be named to v4.0.0 - LTS - Long term support

v2.7.0 will be named v5.0.0 for the enhancement version and v6.0.0 for LTS (when it is done)

previously discussed v3.0.0 will be developed on v7.0.0, stable on v8.0.0 (odd is the enhancement branch, even is the LTS branch)

We will stop using a fourth number.  We currently use the fourth number for a container release where the maven version does not change, but we will just use the next third number, and skip that version in Maven.  For instance, container version v5.2.23 might be using Maven version v5.2.21.  And if that's the case, we will skip in maven to v5.2.24 so we do not re-use that container version.

This only applies to versions which are in Long Term Support (LTS).  The latest Grouper major version has new enhancements until it is complete and stable.  the major version will not be incremented until the enhancements are done (e.g. over a year).

For instance if this is an LTS version: v6.1.8

6 = major version (incompatible changes will bump this number)

1 = minor version (backwards compatible changes)

8 = patch (backwards compatible bug/security fixes)

For instance if this is the enhancement version: v5.1.6

5 = major version (will stay at 5)

1 = minor version (incompatible changes or backwards compatible changes)

6 = patch (backwards compatible bug/security fixes)

If there is a security fix in an LTS version that causes incompatible changes, it will be documented.  For instance if we need to change a 3rd party library we will do so in a way that is the least risky and disruptive, but it might require some configuration changes or change in functionality.  The defaults for all configuration should not change.

      • Incrementing a major version will have upgrade instructions. 
        • These will be the list of instructions of all the minor versions up to the current version of the next major version.
        • e.g. when upgrading from v6.5.13 → v8.8.21
          • Follow instructions for v6.6?, v6.7?, v7.0, v7.1, ..., v7.x, v8.0, v8.1, v8.2, ... , v8.8
      • Incrementing a minor version of an LTS version will generally have no upgrade instructions
      • Incrementing a minor version of an enhancement version might have upgrade instructions
      • Incrementing a patch version will not have any upgrade instructions

The release path for a major version is still linear. 

      • For instance, if you are on v6.5.13, and there is a security fix
        • If the latest v6 version is v6.8.4, and this is backwards compatible, the fix will be released in v6.8.5
        • If the latest v6 version is v6.8.4, and this is not backwards compatible, the fix will be released in v6.9.0

Update on Jar / Config issues:
For each type of plug in, must register everything in a config file. Must coordinate how it’s set up for what config ID to use. Should pick Config ID that is unique for that use case.  Must register external system in Grouper properties to enable the plug in.  It will use the config ID and the package to form string.  Don’t need to add to grouper base properties. Jars can be used.  Nothing changes in base properties.  Need to update the wiki to clarify this?  Example institution-specific provisioner for web service (WS)  

Look at this wiki if you are creating your own provisioners.

There is new generic provisioner

AI -  Chris clarify wiki around config properties for External Systems

Tech Ex Next week in Denver: Attending from Grouper: Chris Hy, Shilen, JJ, Chris Hubing

Current Projects

Vivek

  • Working on External Systems
  • For example, Box
  • Will be working on data fields


Shilen

  • Worked on Point in Time Sync
  • Circular reference issue: Loader loaded groups, script loaded groups and composites keep a state in the database, 
  • How to identify the problem memberships?
  • Veto memberships where circular references can cause issues
  • Store in attributes, don’t want to add more tables, use timestamp or flag
  • Shilen will look at circular reference
  • Start with composites
  • Lockouts issue


Chris

Terminology:

      • "data field" is a user attribute, do not want use attribute since it overlaps with attribute framework

This is a suggestion for how user data could flow to Grouper in future state

The problem this is trying to solve

      • User data in subjects, provisioners, and loaders solve similar problems
      • Real time data solved in multiple ways
      • Security of who is allowed to see what (by person aka row or data field aka value)
      • Efficiency of being able to query data without reaching out to other resources
      • Ability to use data from multiple sources at one time
      • Reduce the number of network calls in various places
      • Reduce the SQL and LDAP syncs required to make things work
      • Troubleshooting access is difficult when the history of data field changes is not known
      • Unresolvable subjects are a pain... history of data fields of users will help
      • Change JEXL to "expression"


  • Comments:  issue on querying with milliseconds
  • AI Chris change millisecond to timestamp on  Grouper data field and subject source next generation

  • Long running transaction and dictionary issue
  • Trying to move away from hibernate
  • Don’t need “last updated” 
  • Chris implemented a simple dictionary class
  • Improved flexibility 
  • Feedback : looks great
  • Next task for data fields is UIs


Chad


  • Grouper Training in mid November went well.
  • 16 students
  • A few complained about Kahoots quizzes in evaluation


Issue Roundup 


Jiras in past weeks

GRP-4472
update provisioning help text for proper translation

Wiki Updates since Nov 9, 2022


Next Grouper Call: Wed.  Dec 7  (during Tech Ex in Denver) (unless this call gets cancelled)


   

  • No labels