Manage groups instead of rolebindings

[larsks]

@knikolla asked for comments on the architecture of this code.

I think that directly modifying rolebindings is the wrong way to do things. Our roles and rolebindings should be static; we should create and manage groups that correspond to each role. This ends up being more flexible in the future because if we need to introduce any sort of project-specific role/rolebinding, we can tie these to the existing group (which would be managed this automated tooling) rather than having to manually manage a list of subjects in the new rolebinding.

[larsks]

OCP-on-NERC/BU-RHOAI#7 is a perfect example of why the way we are doing things right now is broken. That pull request adds a cron job that synchronizes the subjects in the edit rolebinding with a group.

If we were just managing groups to begin with, that synchronization task would be unnecessary.

[knikolla]

@larsks I agree that with your reasoning and desire about rolebindings being static and fully agree with shifting to managing permissions with groups and how it is better.

I don't agree with your characterization of "the way we are doing things right now is broken." A new requirement completely destroyed all assumptions that held for the past 3 years, RHODS not caring about namespaces. That scripts is now necessary because of the way RHODS functions.

If we knew all the requirements to begin with, we would have chosen the right architecture from the get go. Hindsight is 20/20.

[larsks]

Managing groups instead of rolebindings is a better way of managing things regardless of whether or not RHODS is in the picture. The existing code suffered from lack of planning and review, and I am glad we have the chance to revisit some of the decisions that brought us to where we are.

[knikolla]

The existing code suffered from lack of planning and review

Yes, it did.