Use kubebuilder 1.16 instead of the code generator directly for CRDs #16
Labels
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
Comments
|
So, even we have CRDs, but our current usage is quite simple - we do not really need a CRD controller, but just get and update the CRDs in K8s API. The CRDs are mainly for exposing Antrea runtime information to users and UI for debugging puroposes. |
|
we may build CRDs in future which might not be as simple as this.. probably better to switch considering future? |
antoninbas
added a commit
to antoninbas/antrea
that referenced
this issue
Jan 10, 2020
This is still very much a work-in-progress, I'm opening this PR to gather feedback on the approach. For someone deleting Antrea, the steps would be as follows: * `kubectl delete -f <path to antrea.yml>` * `kubectl apply -f <path to antrea-cleanup.yml>` * check that job has completed with `kubectl -n kube-system get jobs` * `kubectl delete -f <path to antrea-cleanup.yml>` The cleanup manifest creates a DaemonSet that will perform the necessary deletion tasks on each Node. After the tasks have been completed, the "status" is reported to the cleanup controller through a custom resource. Once the controller has received enough statuses (or after a timeout of 1 minutes) the controller job completes and the user can delete the cleanup manifest. Known remaining items: * place cleanup binaries (antrea-cleanup-agent and antrea-cleanup-controller) in a separate docker image to avoid increasing the size of the main Antrea docker image * generate manifest with kustomize? * find a way to test this as part of CI? * update documentation * additional cleanup tasks: as of now we only take care of deleting the OVS bridge * place cleanup CRD in non-default namespace * use kubebuilder instead of the code generator directly (related to antrea-io#16); we probably want to punt this task to a future PR. See antrea-io#181
antoninbas
added a commit
to antoninbas/antrea
that referenced
this issue
Jan 10, 2020
This is still very much a work-in-progress, I'm opening this PR to gather feedback on the approach. For someone deleting Antrea, the steps would be as follows: * `kubectl delete -f <path to antrea.yml>` * `kubectl apply -f <path to antrea-cleanup.yml>` * check that job has completed with `kubectl -n kube-system get jobs` * `kubectl delete -f <path to antrea-cleanup.yml>` The cleanup manifest creates a DaemonSet that will perform the necessary deletion tasks on each Node. After the tasks have been completed, the "status" is reported to the cleanup controller through a custom resource. Once the controller has received enough statuses (or after a timeout of 1 minutes) the controller job completes and the user can delete the cleanup manifest. Known remaining items: * place cleanup binaries (antrea-cleanup-agent and antrea-cleanup-controller) in a separate docker image to avoid increasing the size of the main Antrea docker image * generate manifest with kustomize? * find a way to test this as part of CI? * update documentation * additional cleanup tasks: as of now we only take care of deleting the OVS bridge * place cleanup CRD in non-default namespace * use kubebuilder instead of the code generator directly (related to antrea-io#16); we probably want to punt this task to a future PR. See antrea-io#181
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment, or this will be closed in 180 days |
github-actions
bot
added
the
lifecycle/stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: