-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Minimal addon and declarative pattern implementations for addon operators #241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimal addon and declarative pattern implementations for addon operators #241
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: justinsb If they are not already assigned, you can assign the PR to them by writing 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:
Approvers can indicate their approval by writing |
for the record: I would very much like to have this be managed in a separate pattern repo, and then migrate stuff as needed. I makes management, determining staleness, releasing, etc much easier in my experience. |
bffc2c9
to
f4122e8
Compare
I think that makes sense @DirectXMan12 ... we're doing it under the alpha/patterns directory, but clearly that would be better as a That said, if sig-apimachinery's stance is that fewer repos is better, we can work with that, and just have bigger repos that are less focused. (Fixed up the tests as well!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would echo the overall sentiments about this living under a different repo/org controller-patterns
. Took a quick look and have a few observations/questions.
@@ -0,0 +1,27 @@ | |||
package addon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is copyright missing ?
// +k8s:deepcopy-gen=true | ||
type CommonStatus struct { | ||
Healthy bool `json:"healthy,omitempty"` | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should document what these type definition are and how are they suppose to be used.
Also, would be good to include pkg level comments which makes Godoc useful in this case. I think some content from walkthrough be used in the pkg level doc.go in this case.
@@ -0,0 +1,27 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if we should move the examples
outside the alpha/patterns/...
to maintain separation between the packages user import and the examples that they refer. This will also help tools because tools like dep
considers examples to be part of the imported code.
|
||
[[constraint]] | ||
name="sigs.k8s.io/controller-tools" | ||
version="v0.1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the presence of this file introduces deps on controller-tools ? That can introduce the deadlock between controller-tools and controller-runtime.
|
||
func init() { | ||
// TODO: Yuk - global flags are ugly | ||
flag.StringVar(&FlagChannel, "channel", FlagChannel, "location of channel to use") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no!!!!
@@ -0,0 +1,151 @@ | |||
package declarative |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add pkg level doc.go
explaining this pattern and the types defined below.
|
||
var _ reconcile.Reconciler = &Reconciler{} | ||
|
||
type Reconciler struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should explain this in detail.
Code review-wise I think we have a few comments to address that should be straightforward. The open question is if this PR is destin for this repo or another. Any progress on that decisions @DirectXMan12 @droot ? |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
closing this now since we have a separate repo for the add-on pattern. |
Add parsing for required field and corresponding test
@johnsonj and I are working to create operators for kubernetes addons - we aim to use kubebuilder to replace the addon-manager in https://github.com/kubernetes/kubernetes/tree/master/cluster/addons.
We would like to contribute it to controller-runtime & kubebuilder. This PR is the minimal first step, starting on an example for dashboard, and including the minimal functionality of the supporting library. We are putting this into an
alpha/patterns
directory, but hopefully we can figure out if this is indeed the most appropriate place, and/or whether this is a good place to start.We have three main components:
declarative
pattern for implementing a reconciler based on a manifest that is manipulated and thekubectl apply
d (later this will likely use server-side-apply)addon
pattern building ondeclarative
which is opinionated as to how those manifests should be found, and some standard manipulations of the objects and surfacing of status that makes sense for addons.Future PRs will include:
It might be that declarative ends up as core functionality of controller-runtime, as the goal is to have it be much less opinionated than the
addon
pattern.However, we though this was a good place to share the first step and figure out how best to proceed - input is greatly appreciated!
cc @DirectXMan12 @droot @mengqiy @pwittrock