Closed johnsonj closed 4 years ago
cc @neolit123
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
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
/lifecycle frozen
/remove-lifecycle frozen /retitle kubeproxy operator
Thanks to @SomtochiAma this is 'feature complete'! There's follow up work (eg clean up go.mod, update to latest controller-runtime, integrate with prow tests in this repo) but I think that work should be done in this repo and not this PR.
hello,
this is 'feature complete'!
is there a roadmap for this operator? ideally long term we would like to use it a number of SIG Cluster Lifecycle tools including kubeadm, cluster-api.
cc @rosti @fabriziopandini
@neolit123 - there is no identified roadmap. This is just establishing that things work. There's definitely work to do to make this ready for kubeadm/cluster-api.
We can go through the same exercise as coredns operator: proposal, discussion in the cluster addons meeting minutes, then action (#40)! We do need an owner though. (not sure if @SomtochiAma is considering this?)
thanks for the details @johnsonj we just spoke with @rajansandeep and i proposed that he joins the kubeadm office hours so that we can discuss the coredns operator. arguably it is more urgent than the kube-proxy operator, so perhaps we can establish a pattern from it.
sounds great @neolit123 !
/assign @stealthybox
Looking at this PR, it sounds like there is generally agreement on the idea, with a desire to make additional changes (moving to componentconfig, splitting out e2e, etc), and it looks like there are several people making those changes sort of concurrently, including PRs to the PR.
As such, I think it's best to merge and then we can all make any additional changes as additional PRs (it is new code, so we're not breaking anyone!)
/approve /lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: johnsonj, justinsb
The full list of commands accepted by this bot can be found here.
The pull request process is described here
TODO: