ksobrenat32 commented on PR #35107: URL: https://github.com/apache/beam/pull/35107#issuecomment-3120611535
> > The idea is to start with the original permissions, which is a 1:1 copy to the permissions on the gcp protect. > > Then move to the migrated permissions, which are the ones based on the custom roles. This migration can be made gradually based on the permissions each user has. > > The migration plan is explained at the end of the readme > > > > > I think this still results in a huge diff between what we have today and what we're migrating to - https://github.com/apache/beam/blob/b26ecbadb35c2876b50fa29ddd49b1470163ed9d/infra/apache-beam-testing.permission-differences.yaml is quite large. > > > > > > > > > > > I think we should be targeting exact 1:1 permission parity for a migration like this. If we want to update/prune permissions later, that seems fine, but I don't think we should do that as part of this. > > > > > > > > > > > > > > > > > > > > the file is large because it adds a lot of permissions, but it only removes one. We should target to remove zero, right? so this way the migration is backwards compatible. > > > > > > > > > > > > > > > > > > > > @ksobrenat32 can we investigate why dcrhodes is losing that one permission? > > > > > > > > > I think we should target adding 0 permissions as well > > Ok, looking at that, `users.yml` should match `apache-beam-testing.original-roles.yaml`, then right? > > If there are 2 distinct parts to this migration could we split this into those pieces? I think migrating the initial set of roles to terraform management is reasonable, but I do not think we should bundle that with changing permissions (including at the review stage) I have done just that. Created a smaller PR that has only the 1:1 migration at #35701 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
