Add sig-aws charter #2733
Add sig-aws charter #2733
Conversation
k8s-ci-robot
added
size/M
|
@cblecker @jbeda @philips @kris-nova @justinsb -- review requested. |
There was a problem hiding this comment.
This looks good off the cuff! Happy we are about to have a charter.
The three large items I did not see in here that we might want to address before merging.
1) Kops
Following up on the email with @jbeda @philips @justinsb and @countspongebob I don't think we need it on first pass. But at some point we should call out where kops is going to be supported. For the record, I think the AWS components in kops (the majority of use cases) should be supported by sig-aws. The majority of our business logic with interacting with AWS resources is encapsulated in the kops resource tree. That feels like something we should support.
2) EKS
Again following up on the email - we want to let users know that sig-aws is friendly with EKS and it's perfectly fine to bring up topics and questions about the offering - but that the sig will in no way support the offering and will act merely as a knowledge resource for Kubernetes users trying to find help. Basically, the sig can be viewed as a router with EKS support as one of the known destinations.
3) Sig Chairs
Earlier this quarter we ran into some hassle trying to get Nishi officially seated as a sig-aws chair. Should we call our our process here? Just want to make sure if and when we inevitably make another change it goes as smooth as possible.
sig-aws/charter.md
Outdated
|
|
||
| ## Scope | ||
|
|
||
| SIG AWS is responsible for the creation and maintenance of subprojects (features/innovations) necessary to operate Kubernetes on AWS (see below). SIG AWS acts as a forum for Kubernetes on AWS users/developers to raise their feature requests and support issues with. SIG AWS in collaboration with SIG-Testing, SIG-Scalability and SIG-Docs is responsible for integration and maintenance of tests, scale-tests and documentation for all things Kubernetes on AWS. |
There was a problem hiding this comment.
necessary to operate Kubernetes on AWS
I know we call out further down that we are doing more than this - but the first time I read it, it didn't seem that the word operate was inclusive enough. Suggestion to change the wording here to include more than just operating kubernetes on AWS:
necessary to integrate services on AWS, and operate and manage Kubernetes on AWS
sig-aws/charter.md
Outdated
|
|
||
| ## Scope | ||
|
|
||
| SIG AWS is responsible for the creation and maintenance of subprojects (features/innovations) necessary to operate Kubernetes on AWS (see below). SIG AWS acts as a forum for Kubernetes on AWS users/developers to raise their feature requests and support issues with. SIG AWS in collaboration with SIG-Testing, SIG-Scalability and SIG-Docs is responsible for integration and maintenance of tests, scale-tests and documentation for all things Kubernetes on AWS. |
There was a problem hiding this comment.
maintenance of tests, scale-tests
Can we call out explicitly what tests we are responsible for?
There was a problem hiding this comment.
for all things Kubernetes on AWS
This seems a bit nebulous. Can we just rephrase to whatever our scope is?
for all things in scope according to the charter.
sig-aws/charter.md
Outdated
|
|
||
| ## Scope | ||
|
|
||
| SIG AWS is responsible for the creation and maintenance of subprojects (features/innovations) necessary to operate Kubernetes on AWS (see below). SIG AWS acts as a forum for Kubernetes on AWS users/developers to raise their feature requests and support issues with. SIG AWS in collaboration with SIG-Testing, SIG-Scalability and SIG-Docs is responsible for integration and maintenance of tests, scale-tests and documentation for all things Kubernetes on AWS. |
There was a problem hiding this comment.
We don't call out expectations for our maintenance expectation. I don't want to shoot ourselves in the foot, but I think explicitly calling out our best effort of support so we can manage expectations is important.
The SIG members will make a best effort to triage known problems within 1 release cycle of reporting the problem.
I care more about the fact that we call something out - more than I care about the actual time it will take. I just picked a release cycle arbitrarily - that might be hasty.
sig-aws/charter.md
Outdated
|
|
||
| ### Out of scope | ||
|
|
||
| SIG AWS is not for discussing bugs or feature requests outside the scope of Kubernetes. For example, the SIG AWS should not be used to discuss or resolve support requests related to AWS Services. It should also not be used to discuss topics that other, more specialized SIGs own (to avoid overlap). Examples of such scenarios include: |
There was a problem hiding this comment.
I agree 100% that we should not be using sig-aws as a surface for AWS support - but the reality here is that one of the big value adds for sig aws is the access Kubernetes contributors have to the "behind the scenes" information members of AWS and EKS engineering have. We have largely benefited in the past from discussing the undocumented behavior or AWS services to help use further mature the Kubernetes code bases.
Suggestion:
SIG AWS should not be used to discuss or resolve support requests related to AWS Services for non-Kubernetes related issues.
There was a problem hiding this comment.
Also we probably don't need the say the SIG AWS
sig-aws/charter.md
Outdated
| - Container runtime (prefer: sig-node and sig-networking) | ||
| - Resource quota (prefer: sig-scheduling) | ||
| - Resource availability (prefer: sig-apimachinery, sig-network, sig-node) | ||
| - Testing and scale testing scope (prefer: sig-testing, sig-scalability) |
There was a problem hiding this comment.
We call this out above as part of our scope. Can we be a little more granular both here and above around what testing is and isn't in and out of scope.
sig-aws/charter.md
Outdated
|
|
||
| ### In scope | ||
|
|
||
| Link to SIG section in [sigs.yaml](https://github.com/kubernetes/community/blob/master/sigs.yaml) and SIG [subprojects](https://github.com/kubernetes/community/tree/master/sig-aws#subprojects) |
There was a problem hiding this comment.
I'm not really sure what this means - particularly the 1st link. Is this copy-pasta from a template?
There was a problem hiding this comment.
@justinsb - this means that all the listing of subprojects in sigs.yaml are within scope. This is the format from the charter template. I will improve the verbiage as it may confuse a new member.
There was a problem hiding this comment.
Personally I would nuke this explicit sentence entirely. I've preferred charters that explicitly list scope without punting to other documents.
SIG VMWare is a good example as another cloud-focused SIG. Other good examples include SIG Cluster Lifecycle and SIG Instrumentation
sig-aws/charter.md
Outdated
| - Tools for Kubernetes APIs to work with AWS services including Amazon EKS | ||
| - Prow, testgrid, perf dashboard integrations to expand and maintain testing and scale-testing | ||
| - Support users on their issues and feature requests | ||
| - Socumentation for all things Kubernetes on AWS |
| ### Out of scope | ||
|
|
||
| SIG AWS is not for discussing bugs or feature requests outside the scope of Kubernetes. For example, the SIG AWS should not be used to discuss or resolve support requests related to AWS Services. It should also not be used to discuss topics that other, more specialized SIGs own (to avoid overlap). Examples of such scenarios include: | ||
| - Specification of CSI, CRI interfaces, cloudprovider binary (prefer: sig-storage, sig-node and sig-cloudprovider) |
There was a problem hiding this comment.
The cloudprovider one is tricky - assuming we keep sig-aws, sig-openstack etc (and don't fold them in to sig-cloudprovider), would aws-cloud-controller-manager come under sig-aws or sig-cloudprovider (cc @andrewsykim )? My gut feel is that once the cloudprovider extraction is complete, sig-cloudprovider will end up specifying required changes, but sig-aws, sig-gcp, sig-openstack etc will be the right forum for implementation issues.
Or is that the "specification" distinction (in which case I was confused by the binary in "cloudprovider binary")?
There was a problem hiding this comment.
Yeah I think your assumption here is correct, but Nishi please correct me if I'm wrong. When we refer to "cloudprovider binary" we are mostly refering to how cloud-controller-manager is developed/built which includes: generic interfaces (pkg/cloudprovider/cloud.go), controllers, components configs, etc which all fall under SIG cloud provider. Provider SIGs (or more ideally subprojects in the future) are responsible for implementation.
There was a problem hiding this comment.
historically we have referred the ccm in-tree as a subproject of sig-aws
ccm out-of-tree beta/GA should sit under sig-cloudprovider
yes we can keep generic interfaces/configs that may be needed for cloudprovider aws out-of-tree build under sig-aws for now and move everything to sig-cloudprovider in the future.
prefer to get to ccm out-of-tree 1st and then make all necessary changes subsequently if that is ok.
sig-aws/charter.md
Outdated
|
|
||
| ## Roles and Organization Management | ||
|
|
||
| This sig follows adheres to the Roles and Organization Management outlined in [sig-governance] |
There was a problem hiding this comment.
nit: I think delete "follows": "This sig adheres to the ..."
sig-aws/charter.md
Outdated
| SIG AWS delegates subproject approval to Technical Leads. See [Subproject creation - Option 1]. | ||
|
|
||
| [sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md | ||
| [sig-subprojects]: https://github.com/kubernetes/community/blob/master/sig-YOURSIG/README.md#subprojects |
There was a problem hiding this comment.
s/YOURSIG/aws/g (though AFAICT this link is not used)
There was a problem hiding this comment.
oops. Thanks for the catch.
|
I'm generally fine with this, it is tricky to delineate where the lines are with other sigs, because we are horizontal and many other sigs are vertical, so there will always be some overlap. I'm also fine with kops not being called out as a sig-aws project, it is under sig-cluster-lifecycle and probably belongs there. Though there is a lot of AWS code in kops, I do expect a lot of that will surface in the cluster-api effort and similar efforts. But ... I do think we should call out that an AWS cluster-api implementation would likely come under sig-aws. Though there's obvious parallels to the cloudprovider, as well as to CSI implementations for EBS (sig-aws or sig-storage) and CNI implementations for AWS-VPC (sig-aws or sig-networking). If we think that actually |
|
@kris-nova - Thanks for the comments!
|
|
@justinsb for cluster-api-aws I have a pending AI to make it a subproject of sig-aws - we already discussed this with @kris-nova in 1 of the meetings previously. Also given the expansion of the scope to testing, this needs to be done imho. |
|
Broadly speaking I think @kris-nova raised most of the points I would have. SIG VMware and SIG IBMCloud are good examples to refer to when it comes to putting commercial support out of scope, while being an obvious forum for interested users. re: chair swapping, this is spelled out in the sig-governance doc you're linking to, so unless you want to deviate from it, you're fine |
|
/ok-to-test |
k8s-ci-robot
added
size/L
|
@idvoretskyi @philips @jbeda -- can we close this? |
sig-aws/charter.md
Outdated
| Kubernetes integrations specific to AWS including: | ||
| - Integrations, interfaces, libraries and extension points for all AWS services such as IAM, storage, networking, loadbalancers, registry, security, monitoring/logging at the instance or container level | ||
| - Tools for Kubernetes APIs to work with AWS services including Amazon EKS | ||
| - Prow, testgrid, perf dashboard integrations to expand and maintain testing (e2e, jobs) and scale-testing (load, density) |
There was a problem hiding this comment.
@spiffxp -- can you clarify what "which ones" means? previously I was asked to expand on the scope of what testing and scale testing integration meant hence this line.
There was a problem hiding this comment.
In terms of jobs this feels too general... are you responsible for any job that happens to run on AWS?
If I read between the lines this sounds like owning the recent eks kubetest deployer, and potentially owning adapters/integrations that allow tools like prow and the perf dashboard to use s3 instead of gcs.. is that the sort of stuff you're trying to imply?
There was a problem hiding this comment.
@spiffxp today we have ~3% coverage (of total no of jobs) that run on AWS. Yes we will work on integrations to Prow, testgrid, perf dashboard for all the k8s-sigs subprojects as well as in-tree ccm that is in the core. the eks kubetest deployer is one piece yes. We want to expand load and density tests that currently only run on gce and gke such as kubemark, clusterloader tests, scheduler benchmark, multi-node scale tests.
please suggest how I should word this scope.
There was a problem hiding this comment.
Discussed during steering.
My sticking point is on jobs: it seems like you agree you're not responsible for every job that happens to run on AWS, so maybe you could enumerate or describe the ones are you are responsible for? This isn't intended to restrict what you can do, but reduce your support surface area.
eg: you don't own troubleshooting and maintenance of jobs related to kops, SIG Cluster Lifecycle does, since that's where the subproject falls
eg: you're not directly responsible for the AWS accounts or credits that our jobs run on, those are provided to us by the CNCF
There was a problem hiding this comment.
@spiffxp as discussed, added the examples in the "out-of-scpe" section and added "on AWS and Amazon EKS" when describing scope of integrations for Prow, Testgrid and Perf Dashboard.
Let me know!
| - Detailed design and scope of scale tests or tooling to run scale tests (prefer: sig-scalability) | ||
| - Reporting specific vulnerabilities in Kubernetes. Please report using these instructions: https://kubernetes.io/security/ | ||
|
|
||
| ## Roles and Organization Management |
There was a problem hiding this comment.
There are a number of modifications below I'm not sure I understand.
I appreciate the additional specificity in the origins of SIG AWS chairs for example, but I'm not sure what gaps this covers in the original sig-governance doc.
You also omit a number of specifics, ie: the Security Contact Role, roles and responsibilities of SIG Members, some of the Organizational Management bullet points, etc.
I like the idea of subproject retirement, but am unsure what things like "renewed scope" mean in this context.
There was a problem hiding this comment.
Basically I'm trying to understand what led you to copy and modify a bunch, rather than overlay just the things you want to add
There was a problem hiding this comment.
I agree. Why are we copying all of these details? Is there something you don't want to opt-in to?
There was a problem hiding this comment.
Also confused here - I would opt in to as much "inheritance" as we can and only define the deltas were needed.
Also - I don't think we have many (any?) deltas?
sig-aws/charter.md
Outdated
|
|
||
| ## Organization Management | ||
|
|
||
| - Six months after this charter is first ratified, it MUST be reviewed and re-approved by the SIG in order to evaluate the assumptions made in its initial drafting |
There was a problem hiding this comment.
This is awesome and something I would like to suggest we pull into sig-governance if you're OK with it
There was a problem hiding this comment.
Can we bump to a year - sig-aws moves slow 😄
There was a problem hiding this comment.
@spiffxp - awesome sure. I deleted this. and referred to sig-governance
|
/committee steering |
k8s-ci-robot
added
the
committee/steering
|
Discussed during steering @jbeda to followup |
|
Reached out to chairs to get this moving. Will summarize back here (or redirect discussion here). |
|
@philips @spiffxp - I got suggestions from other SIG leads hence added the Roles and Org. section. Specifically I used https://github.com/kubernetes/community/blob/master/sig-cloud-provider/CHARTER.md when making changes. Happy to revert back to the older format to close. |
k8s-ci-robot
added
size/M
|
@d-nishi I apologize for this all being so confusing. At one point we had a template for the charter that we asked folks to copy as a starting point. But after getting some experience with that, we are now encouraging people to refer back to a "base" charter and just list deltas from that that are specific to that SIG. By no means is it necessary that a SIG do so but it just makes things easier for everyone if you do. Hopefully the latest starting point/template for a charter is clear(er). See https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-charter-template.md |
sig-aws/charter.md
Outdated
|
|
||
| ### Subproject Creation | ||
|
|
||
| SIG Auth delegates subproject approval to Technical Leads. See [Subproject creation - Option 1]. |
|
@jbeda - Appreciate it. Please check the updated charter and let me know if we are good to close. |
|
This looks good to me. I'll poke steering and start a lazy consensus clock. Let's aim to merge by EOD Thursday. |
sig-aws/charter.md
Outdated
|
|
||
| ### Subproject Creation | ||
|
|
||
| SIG AWS delegates subproject approval to Technical Leads. See [Subproject creation - Option 1]. |
There was a problem hiding this comment.
Note that at present you have no Tech Leads spelled out in sigs.yaml, only Chairs. Many sigs opt to say that Chairs also fulfill the duties of Tech Leads (or vice-versa) to use this option.
|
/lgtm |
k8s-ci-robot
added
do-not-merge/hold
|
/lgtm cancel |
k8s-ci-robot
removed
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: spiffxp 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 |
k8s-ci-robot
added
the
approved
|
I'm good. /hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
lgtm
No description provided.