Grouper Users - Open Discussion List

["Black, Carey M." <>]

Chris,

 

Thanks for the reply.

 

At this point I am learning the system and trying to make sure that I can see the “train coming” around configuration/management details. So some of this discussion is about “How best to”… more than trying to fix a problem that I have at this time.

( My grouper system was having network issues trying to reach the LDAP source. I think that has been resolved for now. )

 

 

I have been thinking about this condition and I wonder if something like the following could be added?

 

When a entity is found in a group membership, and the Subject API is not defined (at runtime) maybe the system should automatically “mock in” (fall back?) the Subject API with the “NullSourceAdapter”?

                Trying to avoid the inability to manage the group memberships under this condition.

                I am not clear on how much data Grouper still has “locally” to still display the entity for the membership, but even Just a subject.id.GUID is better to show than a broken membership list that does not let you remove the potentially “now defunct” references. ( IMHO )

               

 

Q1) How much does the value of the Subject API “ID” ( or “name”) matters over time?

                I imagine that reusing a subject.id value is generally ill advised.

 

                Example: Let’s say I have a set of source.id values of ‘1’,’2’,’3’, and ‘4’.

                Then I retire ‘4’. ( remove it totally from the config, but do not strip group of all entities from the source )

                                This state appears to “break the display” of any remaining memberships from this source.

                Then later the value of ‘4’ is “reused’ (unbeknown by the new admin who never had seen ‘4’ before) with another System of Record (SOR).

                Maybe if the OLD SOR ID collides that new SOR ID values, then the new entities would “inherit” the old memberships that is not theirs. (Ouch)

 

                I could imagine that if the identifier remained the same between the two source systems then things could “work out just fine” too. However, that seems like a very unusual possibility.

 

 

                So, maybe grouper could keep a record of subject.id values and their configured “type of source Adapter” into perpetuity.

                                On load/startup/config read,  mark any “missing” as  now being effectively a “NullSourceAdapter”? (maybe a Boolean “Missing flag” column.)

                                Then WARN on detected reuse when the actual type changes?

                                                Or maybe more drastic, and maybe a necessary feature to, have the user prove they are not doing this on accident and throw a FATAL error.

                                                Then provide a way to use the GSH to “remove the old definition” before a reuse/change of Type is allowed?

 

 

Q2) Could/Should Grouper “know enough” ( and keep details hidden somewhere ) about every registered/configured Subject API to be able to “mock in” all the right additional config values?

                ( I am not clear on how many, if any other values, other than the subject.id would be needed for the NullSourceAdapter to be stubbed in. )

                Or does “WHATEVER” really mean that the config values are irrelevant and can be null/not defined?

                Or should they remain “whatever” they were before the subject API was “removed”?

                “

                subjectApi.source.jdbc99.param.sortAttribute0.value = WHATEVER

                subjectApi.source.jdbc99.param.searchAttribute0.value = WHATEVER

                “

 

What do you think?

 

--

Carey Matthew

 

From: Hyzer, Chris [mailto:]
Sent: Friday, April 14, 2017 4:11 PM
To: Black, Carey M. <>;
Subject: RE: Subject API "lifecycle"/"interruption of service" issue....

 

Can you add a null source for that one?  Here is an example:

 

#########################################

## Configuration for source id: jdbc99

## Source configName: jdbc99

#########################################

subjectApi.source.jdbc99.id = jdbc99

 

# this is a friendly name for the source

subjectApi.source.jdbc99.name = jdbc99 is some legacy source that isnt used anymore

 

# the adapter class implements the interface: edu.internet2.middleware.subject.Source

# adapter class must extend: edu.internet2.middleware.subject.provider.BaseSourceAdapter

# edu.internet2.middleware.grouper.subj.GrouperJdbcSourceAdapter2  :  if doing JDBC this should be used if possible.  All subject data in one table/view.

# edu.internet2.middleware.grouper.subj.GrouperJdbcSourceAdapter   :  oldest JDBC source.  Put freeform queries in here

# edu.internet2.middleware.grouper.subj.GrouperJndiSourceAdapter   :  used for LDAP

# edu.internet2.middleware.subject.provider.NullSourceAdapter      :  returns not found.  You can use if you phase out a subject source

subjectApi.source.jdbc99.adapterClass = edu.internet2.middleware.subject.provider.NullSourceAdapter

 

# the 1st sort attribute for lists on screen that are derived from member table (e.g. search for member in group)

# you can have up to 5 sort attributes

subjectApi.source.jdbc99.param.sortAttribute0.value = WHATEVER

 

# the 1st search attribute for lists on screen that are derived from member table (e.g. search for member in group)

# you can have up to 5 search attributes

subjectApi.source.jdbc99.param.searchAttribute0.value = WHATEVER

 

 

From: [] On Behalf Of Black, Carey M.
Sent: Thursday, April 13, 2017 12:58 PM
To:
Subject: [grouper-users] RE: Subject API "lifecycle"/"interruption of service" issue....

 

Any input on this?

 

--

Carey Matthew

 

From: [] On Behalf Of Black, Carey M.
Sent: Tuesday, April 11, 2017 11:14 AM
To:
Subject: [grouper-users] Subject API "lifecycle"/"interruption of service" issue....

 

All,

 

I have stumbled into a behavior of Grouper that I think should be improved. For a several reasons. However, maybe I am not seeing some other designed way to deal with this condition.

 

The setup:

                I added a new Subject API to grouper. However, I knew it was “temporary” as I was just “trying it out”. ( Let’s call it “TEMP”.)

                I then removed the definition of the Subject API and now the Grouper UI is unable to display the memberships of any group that has any member from that TEMP Subject API.

                Error message when viewing a group in the New UI:

“

Error: Cant find source with id: 'TEMP', Possible source id's: 'g:gsa', 'grouperEntities', 'grouperExternal', 'jdbc', 'g:isa', , Problem calling method viewGroup on edu.internet2.middleware.grouper.grouperUi.serviceLogic.UiV2Group

“

( And no members of the group are displayed at all. )

 

 

 

While I doubt it would be common to add or remove Subject APIs. I am sure this kind of event is part of “the long lifecycle” of using Grouper.

 

From a conceptual point, I think it would be useful for Grouper to tolerate the “failed to find” and “failed to get data” from a Subject API to allow for a transition model between Subject API sources. Basically keep the “old references” while layering in the new (replacement) references to the new Subject API. If both Subject API’s (old and new) are available, then I think life is currently good. It is when the “old” is removed that it appears to impact, at least, the functionality of the UI.

 

 

Is there a way to tell grouper to “Just use the data you have” when the subject API is undefined? ( removed subject api definition)

Is there a way to tell grouper to “Just use the data you have” when the subject API fails to return data? (  intermittent incident/outage of Subject System )

Is there a way to give grouper a “dummy subject API configuration” that would just return the data that Grouper already has for the subject API?

 

Is there some documentation for “How to remove a Subject API” from Grouper that I did not yet find and follow?

Are there other ideas/details about adding/removing Subject API’s that I should be aware of?

 

Thanks in advance.

 

--

Carey Matthew