Make explicit that we would like to have the migration from v3 to v4 helped by tooling

[camilamacedo86]

Description
Make explicit that we would like to have the migration from v3 to v4 helped by tooling

Suggested Solutions

• Add new plugin interface documented with this information
  OR
• Add doc which describes that

[camilamacedo86]

• The goal of this task is just we keep this in mind and do not forget that we would like to try to do that by tooling when the go/v4 plugin is released.
• We are unable to discuss how it would get done before v4 exist

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[camilamacedo86]

/remove-lifecycle stale

[camilamacedo86]

Suggestion / Idea to move forward with a proposal for this one:

All commands executed with the tool (data) are tracked in the PROJECT file.
(ihmo) it would be desirable to have a command that re-scaffolds all based on that so it could help in the migration process ( like I want to upgrade my project to the latest versions changes )

We would have an alpha command to try to make it where we could inform via a flag the PROJECT file and the --plugins which we would like to use to do the re-scaffold. Then it would mean for example:

$ kubebuilder alpha scaffold --project-config=<inform the path of the PROJECT file> --plugins=go/v4,grafana/alphav1 --output=path

That could result in:

-> create a directory with the project name
-> call the tool to init the project with the plugins --plugins=go/v4,grafana/alphav1
-> call edit subCommans for edit the project ( example if multigroup be enabled )
-> call create API to create all APIs and controllers scaffold (we also need to check if the api was not scaffolded with for example a specific plugin like deploy-image/alphav1)
-> call create webhook to create the webhooks scaffold as well

That also can lead to future changes/additions to the PROJECT file in case we discover that we are missing info to be tracked there.

[camilamacedo86]

Hi @rumstead,

See a draft about how I thought that we could achieve this goal: #3007

[camilamacedo86]

Close this one because we are working a design proposal for this scenario: #3221

we can have an issue as follow-up afterwords where we can better describe what / how that should be done.