On Sat, 9 Mar 2019 at 02:44, Chris Lambertus <[email protected]> wrote: > > Thank you for your work on this, Sebb. I need to go through the threads and > make sure all the ’t’s are dotted and all the ‘i’s crossed, but then I’ll > start the work to decom that OU.
It might be sensible to start by dropping one or two ou=pmc groups (apart from TAC and security) and see if anything breaks or changes. Maybe then empty the OU and leave it a little while before removing it entirely? A missing OU may be handle differently from an empty one (if it can be empty). Just a thought. If things do break, it's presumably possible to temporarily recreate the missing items whilst things are fixed. > -Chris > > > > > > On Mar 8, 2019, at 3:28 AM, sebb <[email protected]> wrote: > > > > Whimsy no longer references LDAP ou=pmc groups (*) > > > > I emailed the TAC chair (Gavin) about the TAC discrepancies, but I've > > not heard what the final resolution is. > > > > S. > > (*) except in the script that does basic checks of (asf|pit)-authorization > > Those files still use ou=pmc for TAC and Security, so the script has > > to allow for it. > > Removal will not affect the script. > > > > On Wed, 30 Jan 2019 at 23:11, sebb <[email protected]> wrote: > >> > >> Turned out to be not too hard to recreate public_ldap_committees.json > >> from ou=projects with some help from committee-info.txt. > >> The public_ldap_groups.json file can also be created with some data > >> from ou=groups to supply the non-PMC groups. > >> > >> This should allow external projects to continue working mostly correctly. > >> However the JSON files cannot be used to determine membership of > >> ou=pmc or ou=groups. > >> This has long been the case for the guinea pigs. > >> > >> The updated scripts should continue to work even when projects are > >> deleted from ou=pmc and ou=groups. > >> > >> However the rest of the Whimsy code has yet to be updated; that is > >> looking much more complicated. > >> > >> > >> On Wed, 30 Jan 2019 at 15:48, sebb <[email protected]> wrote: > >>> > >>> It's looking to be quite complicated to maintain compatibility. > >>> I think this is important because external projects may rely on the > >>> generated JSON data files, and it may not be possible to fix all the > >>> projects in time. > >>> > >>> The change will affect two of the JSON files: > >>> public_ldap_groups.json > >>> public_ldap_committees.json > >>> > >>> In both the above cases, the guineapig projects are added to the output. > >>> This was done to maintain compatibility for external projects. > >>> In theory all projects now become guineapigs. > >>> However the ou=projects list includes lots of podlings as well. > >>> > >>> One way to maintain compatibility would be to make all the existing > >>> projects in groups/committees into guineapigs. > >>> A bit messy, but it might work. > >>> > >>> Longer term, external projects need to stop using ldap_committees, and > >>> only use ldap_groups for whatever is left (e.g. member, committers) > >>> This involves fixing phonebook and projects.a.o; there are probably > >>> others. > >>> > >>> The cutover date of Feb 9th might be somewhat optimistic. > >>> > >>> I think we need to find out if there are any other projects using the > >>> 2 above-mentioned Whimsy JSON files. > >>> > >>> On Wed, 30 Jan 2019 at 13:15, sebb <[email protected]> wrote: > >>>> > >>>> On Wed, 30 Jan 2019 at 11:36, sebb <[email protected]> wrote: > >>>>> > >>>>> Note mixed private and public lists > >>>>> > >>>>> On Wed, 30 Jan 2019 at 09:37, sebb <[email protected]> wrote: > >>>>>> > >>>>>> On Wed, 30 Jan 2019 at 03:54, Chris Lambertus <[email protected]> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Sam, Whimsy Dev, > >>>>>>> > >>>>>>> Some time ago we migrated projects to use the ou=groups,ou=project > >>>>>>> format with owner and member attributes. > >>>>>>> > >>>>>>> > >>>>>>> The time has come to delete the legacy CNs. > >>>>>> > >>>>>> It might make sense to fix Whimsy ASAP and see if that causes any > >>>>>> grief. > >>>>> > >>>>> I have started looking at Whimsy. > >>>>> > >>>>> It needs a bit of care as the Groups/Project code is closely related, > >>>>> and we need to keep the Groups for members and committers etc. > >>>>> > >>>>> There are some other entries only in ou=groups: > >>>>> > >>>>> apsite concom infra podlings > >>>>> > >>>>> I think infra and podlings are not used and could be deleted? > >>>>> (podlings is empty anyway) > >>>>> > >>>>> apsite probably ought to be in a different OU -- if it is to be kept > >>>>> It gives write access to /websites/production/www; maybe an existing > >>>>> group (member?) would do > >>>>> > >>>>> Not sure about concom - maybe it should be ou=project? > >>>> > >>>> INFRA-17782 - create concom ou=project. > >>>> > >>>>> S. >
