Define rollouts sub-project structure

[droot]

Based on the POC in the feature-rollouts branch, we have identified following APIs:

• Rollout APIs
• ProgressiveRollout Strategy
• RemoteRootSync

The task is to scaffold the project structure under directory rollouts in kpt repo with well defined GVKs for the rollouts related APIs with basic Makefile targets to build CRDs, manifests etc.

For majority of the tasks, the kubebuilder generated structure should work.

[mortent]

@droot As part of this effort, can we also come up with a proposal to align the RemoteRootSync code for rollouts with the RootSyncSet controller in Porch? This might require that we figure out where to put shared code between the different components in the kpt repo.

The RemoteRootSyncSet code seems to have less overlap with the current code in rollouts, so we can probably handle that later.

[droot]

As part of this effort, can we also come up with a proposal to align the RemoteRootSync code for rollouts with the RootSyncSet controller in Porch? This might require that we figure out where to put shared code between the different components in the kpt repo.

Actually, RemoteRootSync has a dependency on the clusterstore package (discovery targets and creating dynamic client for those targets). We wrapped up basic Fleet support last week, so I was planning to first get the clusterstore sorted wrt to Fleet support that will give me a good about the interaction between the two, then I can propose a few options with pros/cons (two weeks later). Is anyone waiting for RootSyncSet ?

[mortent]

It is not super urgent, but there is a lot of duplicate code between the rollout code and the rootsyncset controller that we need to clean up. I'm just worried that the longer we wait the harder it is going to be to fix it.