If the problem is just that recreating ou=meta is messy, then there are other solutions.
For example, it should not be too difficult to compare the lists and only update those which have changed. Probably can also speed this up by comparing last updated dates. It might also make sense to enhance Whimsy to update the ou=meta list at the same time as the owners. As Sam points out this would require that the karma needed must agree with the karma for owners. This would minimise process changes as well as minimising LDAP updates. In case there are Infra scripts that update owners it would make sense to keep a regular check on the consistency of the lists. Sebb On Mon, 13 Jun 2022 at 00:32, Sam Ruby <ru...@intertwingly.net> wrote: > > From a whimsy requirements perspective, the key requirement is that > PMC members can update LDAP the PMC (i.e., both the PMC and committers > lists). > > On Sun, Jun 12, 2022 at 6:56 PM sebb <seb...@gmail.com> wrote: > > > > On Sun, 12 Jun 2022 at 21:26, Chris Lambertus <c...@apache.org> wrote: > > > > > > > > > Hi folks, > > > > > > I have been working on some updates to the LDAP service, and I would like > > > to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the process > > > which manages it.) > > > > > > Some history -- this ou was created to address a problem which arose > > > after project groups were converted to member/owner (INFRA-16188). The > > > Atlassian Crowd service that feeds authentication and authorization for > > > Jira and Confluence does not understand the "owner" concept. > > > > > > Infra had previously created local roles in cwiki and jira, and generally > > > pushed maintenance of memberships of said roles to the project owners > > > defined within cwiki and jira. Over time this grew cumbersome, and we > > > elected to switch to LDAP-based groups, but we only had access via Crowd > > > to the attr=member version of the groups, so we could not assign > > > PMC-based roles. > > > > > > Because of this, I created a stop-gap process which drops and reloads > > > ou=meta nightly, populating > > > ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of > > > the PMC members. This process is awkward, and causes problems with the > > > LDAP audit logging system. > > > > > > I would like to gather feedback on re-creating and maintaining the ou=pmc > > > tree in parallel with the owner/member paradigm that is now in place, > > > specifically to support Crowd-based applications (which now also include > > > JFrog/artifactory,) or other 3rd party tooling which may not understand > > > member/owner. > > > > > > At this time, I believe the only ASF tooling which creates or modifies > > > the owner attribute of project groups is Whimsy, so any code adjustments > > > would likely have to happen here. > > > > AFAIK Whimsy is not the only place where accounts are created and PMC > > memberships updated; there are likely some Infra scripts that do so. > > > > It's not clear to me whether the existing owner attributes will be kept or > > not. > > Indeed I'm not clear what the proposal is. > > > > > What are your thoughts? > > > > > > Thanks, > > > Chris > > > ASF Infra > > > > > >
