kubernetes-sigs / cluster-addons

Addon operators for Kubernetes clusters.
Apache License 2.0
155 stars 47 forks source link

kubeproxy operator #35

Closed johnsonj closed 4 years ago

johnsonj commented 5 years ago

TODO:

timothysc commented 4 years ago

cc @neolit123

fejta-bot commented 4 years ago

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

fejta-bot commented 4 years ago

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

neolit123 commented 4 years ago

/lifecycle frozen

johnsonj commented 4 years ago

/remove-lifecycle frozen /retitle kubeproxy operator

johnsonj commented 4 years ago

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.

neolit123 commented 4 years ago

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

johnsonj commented 4 years ago

@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?)

neolit123 commented 4 years ago

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.

johnsonj commented 4 years ago

sounds great @neolit123 !

somtochiama commented 4 years ago

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?)

I am definitely interested

johnsonj commented 4 years ago

/assign @stealthybox

justinsb commented 4 years ago

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

k8s-ci-robot commented 4 years ago

[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

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubernetes-sigs/cluster-addons/blob/master/OWNERS)~~ [johnsonj,justinsb] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment