delete api command line

[fanux]

/kind feature

We need to delete CRD kubebuilder delete api --group infra --version v1 --kind Router

[hpandeycodeit]

/assign

[DirectXMan12]

It's a lot harder to safely delete things than it is to create them, so I'd like to have a more concrete usecase for this first.

[fanux]

I define a CRD called Subnet, but I think Bridge is more suitable，so I want to delete the old one. But I don't know-how

It caused my code not clean...

[DirectXMan12]

right, but it's hard for kubebuilder to know if you've added or modified anything else in the meantime, especially in shared files. Are there cases where git revert or something similar aren't sufficient?

[Adirio]

It's a lot harder to safely delete things than it is to create them, so I'd like to have a more concrete usecase for this first.

If you

• [ ] Delete the api/VERSION/KIND_types.go
• [ ] Regenerate the api/VERSION/zz_generated.deepcopy.go
• [ ] Delete the controllers/KIND_controller.go
• [ ] Remove the corresponding test from controller/suite_test.go
• [ ] Remove the import, init and setup from main.go
• [ ] Remove the resources corresponding element from PROJECT

wouldn't you completely delete the API? Only api/VERSION/KIND_types.go and controllers/KIND_controller.go are expected to be modified by the user and those files would be deleted completely. The rest of the files are not expected to be modified, and changing them may mean that kubebuilder create API ... is unable to finish.

[DirectXMan12]

people can happily add common types to either of those files, split things off into multiple files, etc afterwards. Scaffolding is a starting point.

[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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[camilamacedo86]

Hi @DirectXMan12,

By following your comments here shows that we should not move forward with. Am I right? If yes, could we close this one as not accepted/deferred?

Please, let me know if we should try to address this request.

[ryanzhang-oss]

It's a lot harder to safely delete things than it is to create them, so I'd like to have a more concrete usecase for this first.

If you

• [ ] Delete the api/VERSION/KIND_types.go
• [ ] Regenerate the api/VERSION/zz_generated.deepcopy.go
• [ ] Delete the controllers/KIND_controller.go
• [ ] Remove the corresponding test from controller/suite_test.go
• [ ] Remove the import, init and setup from main.go
• [ ] Remove the resources corresponding element from PROJECT

wouldn't you completely delete the API? Only api/VERSION/KIND_types.go and controllers/KIND_controller.go are expected to be modified by the user and those files would be deleted completely. The rest of the files are not expected to be modified, and changing them may mean that kubebuilder create API ... is unable to finish.

It's actually a lot more involved than this, there are a bunch of Kustomize scripts to clean up and more. I guess it's ok as Kubebuilder is mostly a toy tool.

[Adirio]

It's actually a lot more involved than this, there are a bunch of Kustomize scripts to clean up and more. I guess it's ok as Kubebuilder is mostly a toy tool.

@ryanzhang-oss you are right that there are more files involved. But toy tool does not describe kubebuilder. It is an scaffolder, it is not a full code generator but an squeleton generator for you to shape to your needs.

[ryanzhang-oss]

It is an scaffolder, it is not a full code generator but an squeleton generator for you to shape to your needs.

Can you imagine using a scaffolding tool that generates tons of human unfriendly files in your production environment that you know every resource you created can't be easily removed later? Not sure what else can I call such a tool, a POC?

[fanux]

@ryanzhang-oss kubebuilder solved many problems but not all, it let us more efficiency，a toy tool is inappropriate I think. But we really hope kubebuilder better.

[DirectXMan12]

So, I'm sympathetic with the "I don't know which kustomize files to delete" argument. Those are a bit easier to remove. We can perhaps try to find some way to make that easier. However, under our current setup, undoing code changes is not particularly feasible. Perhaps this'll change in the future. For now, please try not to be antagonistic.

[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-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

[fejta-bot]

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-testing, kubernetes/test-infra and/or fejta. /close

[k8s-ci-robot]

@fejta-bot: 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-testing, kubernetes/test-infra and/or fejta. /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.

[pbxqdown]

Maybe some detailed documents can at least make it easier for people to delete an generated API manually.

[ryanzhang-oss]

+1

Sent from my T-Mobile 5G Device Get Outlook for Androidhttps://aka.ms/AAb9ysg

---

From: Qian_Xiao @.> Sent: Friday, January 7, 2022 3:01:41 PM To: kubernetes-sigs/kubebuilder @.> Cc: Ryan Zhang @.>; Mention @.> Subject: Re: [kubernetes-sigs/kubebuilder] delete api command line (#907)

Maybe some detailed documents can at least make it easier for people to delete an generated API manually.

— Reply to this email directly, view it on GitHubhttps://github.com/kubernetes-sigs/kubebuilder/issues/907#issuecomment-1007805637, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AODXOHBWBVW5SSBKAJLY37DUU5WFLANCNFSM4IIB7OTA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>

[ShavaShav]

Is there still no way to delete a CRD?

[cesarandr]

Would also need a feature like this or at least some documentation on what to delete manually. Is one of those things available at this time?

[meter-peter]

It's a lot harder to safely delete things than it is to create them, so I'd like to have a more concrete usecase for this first.

If you

• [ ] Delete the api/VERSION/KIND_types.go
• [ ] Regenerate the api/VERSION/zz_generated.deepcopy.go
• [ ] Delete the controllers/KIND_controller.go
• [ ] Remove the corresponding test from controller/suite_test.go
• [ ] Remove the import, init and setup from main.go
• [ ] Remove the resources corresponding element from PROJECT

wouldn't you completely delete the API? Only api/VERSION/KIND_types.go and controllers/KIND_controller.go are expected to be modified by the user and those files would be deleted completely. The rest of the files are not expected to be modified, and changing them may mean that kubebuilder create API ... is unable to finish.

Indeed kubebuilder create API is unable to finish. The problem is solved by adding --force

[camilamacedo86]

I think it would be nice we add delete commands for all interfaces and not only create api one We can easily just warning when is not possible revert/delete something if that is the case so users a aware of. +1 for this I think we can plan those changes

It might be a nice good first issue for who is looking for something within a L size and already pushed a couple of PRs.

Following the details

• Add DeleteAPI and DeleteWebhooks in the interface: https://github.com/kubernetes-sigs/kubebuilder/blob/master/pkg/plugin/plugin.go
• Implement those for kustomize/v2, go/v4 plugin
• We will need to also evaluate those changes with deploy-image and grafana plugins, see: https://book.kubebuilder.io/plugins/plugins
• You will must check all that is scaffold for each case scenario and ensure that we are deleting or commenting to revert the changes
• You will need to WARNING when is not possible delete or commenting to inform users
• It must either be covered by the e2e tests, see: https://github.com/kubernetes-sigs/kubebuilder/tree/master/test/e2e (Feel create to create a new suite of tests to check this new feature). The tests should create and and delete and have asserts to ensure the changes

[ashishkpathak-connect]

@camilamacedo86 I am super interested to work on this. Thank you very much for sharing the above information. Can I assign this to myself?

[ashishkpathak-connect]

/assign

[ashishkpathak-connect]

Hi Team,

I've assigned this to myself. Before I get started, I just wanted to confirm if there’s anything specific I should be aware of for this task? Any suggestions apart from the above mentioned?

[camilamacedo86]

I don't think this qualifies as a good first issue, so I have removed the label.

If you're interested in working on this, it's crucial to propose a maintainable solution (if feasible). We also need to ensure that all commands delete interfaces and implement them correctly.

This task may pose challenges, not only in maintaining a clean and sustainable implementation but also due to the complexities involving the markers.

I recommend starting by creating the interfaces and ensuring that your implementation removes everything scaffolded by the commands in each case, along with the associated tests.

A good starting point would be working on the create API (in this case delete API) command to demonstrate that this approach is achievable.

[ashishkpathak-connect]

Thank you very much @camilamacedo86 for the suggestion. I will follow it and come up with a delete API at first to show case it can clear everything which createAPI scaffolds.

[annis-souames]

Hello,

Adding a delete feature to kubebuilder API would be a very nice addition to the scaffolder. I opened a similar issue a couple of days ago (issue #5101) but since this issue has been going on for sometime now, I will move the discussion to here.

There was several situations where I needed a delete feature, particularly when I was working on a complex operator where we didn't have all the CRDs in mind before starting the implementation, and would sometimes need to delete a CRD and create a new one. By deleting, this usually means:

1. Delete the KIND_types.go generated
2. Delete the generated controller and it's associated test.
3. Delete the call to the controller reconcile loop in cmd/main.go.
4. Manually delete entries in the different YAML manifests (most tricky part) generated by kubebuilder.

Doing this process manually is quite cumbersome and error-prone. After reading the discussion in this thread, I understand that deleting files is MUCH MUCH harder than creating them, as the user might permanently lose changes.

Here are some rough ideas I have so far:

• The easiest way is to just show a warning to the user and a list of the deleted files before deleting them, the user would need to double confirm the action (sort of y/n input). The deleted files would just be the files mentioned above that were generated from kubebuilder + any parts that were injected in other files such as main.go, PROJECT, etc.
• Another approach which is more complex but more reliable in the long run, would be to build some sort of diffing logic, a bit similar to how git diff works, we would need to have the old state stored somewhere: a very lightweight database like SQLite (pre-packaged with kubebuilder, or figure out somewhere else where to store the current state after kubebuild create api .... and then does a diff. I reckon that this is a beast of an implementation because we would need to change create api/webhook logic to store the state.

Overall, I think this is an interesting problem to solve and I would love to take this issue and experiment with some ideas discussed in this thread and maybe work towards contributing a delete subcommand feature, I would love to get other ideas as well :)

In any case, I believe it would be best to start small with simple ideas . I will re-assign this issue to myself.

[annis-souames]

/assign