-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
SIG Multicluster charter #2561
SIG Multicluster charter #2561
Conversation
/approve |
lgtm |
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.
@pmorie - Thanks for updating!
Would it be possible to try and add more specifics? We're trying hard to make certain we're explicit and well scoped in the charters, because otherwise responsibilities get all muddled.
/assign @quinton-hoole
sig-multicluster/charter.md
Outdated
|
||
The scope of SIG Multicluster includes: | ||
|
||
- Solving common challenges related to management of multiple Kubernetes clusters and the applications that exist therein |
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.
This is really broad, could you scope it down?
e.g. - what aspects?
- Networking, application mgmt, disaster recovery, etc.
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 think the most sensible thing to say here is probably to be really specific about the scopes of the existing projects, which are:
- cluster-registry
- federation-v2
- kubemci
I don't think it's especially useful to have a vague prose description of the scope - since this SIG is essentially focused entirely around these projects at this point.
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 think the most sensible thing to say here is probably to be really specific about the scopes of the existing projects
Agreed, we want to make certain the areas of responsibility translate to specific areas of ownership so we can start to rationalize the SIGs across the project.
/cc @spiffxp |
/unassign @quinton-hoole |
/committee steering |
/assign @timothysc |
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.
Looking forward to more specifics
sig-multicluster/charter.md
Outdated
|
||
#### Code, Binaries and Services | ||
|
||
- Mechanisms in Kubernetes that track information about multiple clusters |
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.
Needs to be less vague. spartakus tracks information about multiple clusters, in the sense that they all ping it... but I doubt that's under your purview
|
||
### Out of scope | ||
|
||
- Software that creates or manages the lifecycle of Kubernetes clusters |
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.
Which SIG (if any) would own reconciliation between cluster-api and cluster-registry?
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 had hoped to address that by narrowly defining the scope of the SIG. I will add a note that specifically addresses the situation where another part of the community plans an integration between another piece of software and one that is in scope for the SIG.
Ping, any updates on this? |
@spiffxp @timothysc changes pushed, tried to be very specific. |
@pmorie am I missing something, I don't see an updated PR? |
@timothysc it sure helps if you push to the right branch; apologies! |
/hold Pending @spiffxp feedback. I don't really have issues with the current form, but it may be a bit limiting. I'd leave that to the chairs to decide. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: csbell, timothysc 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 |
This looks like over-specification to me, especially compared to the description in sigs.yaml. Things mentioned there I don't see here:
/lgtm |
Please |
@spiffxp @timothysc I agree that it is very specific at this point, I found it hard to determine exactly what the right level of detail was and decided to err on being overly specific rather than overly broad. I'm fine iterating on this in follow-ups, canceling hold. Thanks for the reviews! /hold cancel |
The /hold command wasn't picked up due to an ongoing github incident. Linking to see if this gets picked back up when github recovers |
Replaces #1989 as a WIP for SIG multicluster charter.