kubebuilder
kubebuilder copied to clipboard
kubernetes-sigs
Make explicit that we would like to have the migration from v3 to v4 helped by tooling
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
- 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
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
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
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-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.
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.
Hi @rumstead,
See a draft about how I thought that we could achieve this goal: https://github.com/kubernetes-sigs/kubebuilder/pull/3007
Close this one because we are working a design proposal for this scenario: https://github.com/kubernetes-sigs/kubebuilder/pull/3221
we can have an issue as follow-up afterwords where we can better describe what / how that should be done.