From 8e15a8d841ee7855c428ba4805c411cc7fa1afd6 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Mon, 21 May 2018 21:38:17 -0700 Subject: [PATCH] *: Assorted internal-reference cleanups This is mostly replacing https://github.com/kubernetes/community/blob/master/... links with relative links, because relative links are easier to maintain. For example, if you rename a.md to b.md in a feature branch, updating an /a.md to /b.md target will work immediately (e.g. during pull-request review), while updating https://github.com/kubernetes/community/blob/master/a.md to https://github.com/kubernetes/community/blob/master/b.md will only work after your branch lands the rename in master. I'm not sure why the #L1454 fragment was part of the old sig-governance template sigs.yaml link, but it's been there since the template landed in 68658bff (Provide short template for SIG governance, 2018-02-23, #1830). I've removed it in this commit. The Kubernetes Charter README link in the sig-governance template could just be: [Kubernetes Charter README]: README.md but I've based it on the project root and back to make life easier on new SIGs which copy/paste the file to a new location in this repository. I personally prefer targets that use ../ for referencing other directories within a project, because those also work with generic Markdown tools (e.g. Emacs' Markdown mode). I've gone with /-rooted targets in this commit as requested in /sig-contributor-experience/markdown-link-style-guide.md. I've also chased a few files and anchors as they've moved around, e.g. the OBSOLETE_templates.md rename from 18958f82 (addressing Brians comments, 2017-09-06, #1010) and the "and maintenance" header addition from f471f6b6 (Add new contact info for Paris and me, 2017-10-17, This commit isn't complete, but it's a step in the right direction and all I had time for tonight ;). The sig-list.md changes were generated automatically from the generator/list.tmpl changes with: $ make generate --- committee-steering/governance/README.md | 4 ++-- .../governance/sig-governance-template-short.md | 8 ++++---- communication/README.md | 2 -- communication/zoom-guidelines.md | 4 ++-- .../architecture/declarative-application-management.md | 10 +++++----- contributors/guide/README.md | 2 +- generator/list.tmpl | 4 ++-- github-management/kubernetes-repositories.md | 2 +- .../0007-20180403-community-forum.md | 2 +- ...08-20180430-promote-sysctl-annotations-to-fields.md | 8 ++++---- sig-creation-procedure.md | 2 +- sig-list.md | 4 ++-- .../processes/formal-scalability-processes.md | 2 +- sig-storage/volume-plugin-faq.md | 3 +-- sig-windows/README.md | 2 +- 15 files changed, 28 insertions(+), 31 deletions(-) diff --git a/committee-steering/governance/README.md b/committee-steering/governance/README.md index 7321c0551e3..c93df7c9876 100644 --- a/committee-steering/governance/README.md +++ b/committee-steering/governance/README.md @@ -71,5 +71,5 @@ See [frequently asked questions] [Recommendations and requirements]: sig-governance-requirements.md [Short Template]: sig-governance-template-short.md [frequently asked questions]: FAQ.md -[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml -[sig-architecture example]: ../../sig-architecture/charter.md +[sigs.yaml]: /sigs.yaml +[sig-architecture example]: /sig-architecture/charter.md diff --git a/committee-steering/governance/sig-governance-template-short.md b/committee-steering/governance/sig-governance-template-short.md index 620d764a0bc..5cef70ef19f 100644 --- a/committee-steering/governance/sig-governance-template-short.md +++ b/committee-steering/governance/sig-governance-template-short.md @@ -140,7 +140,7 @@ Issues impacting multiple subprojects in the SIG should be resolved by either: [lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus [super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote -[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md -[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L1454 -[OWNERS]: contributors/devel/owners.md -[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md +[KEP]: /keps/0000-kep-template.md +[sigs.yaml]: /sigs.yaml +[OWNERS]: /contributors/guide/owners.md +[Kubernetes Charter README]: /committee-steering/governance/README.md diff --git a/communication/README.md b/communication/README.md index fd6f0a52a0e..29aa0a844ff 100644 --- a/communication/README.md +++ b/communication/README.md @@ -88,8 +88,6 @@ Kubernetes is the main focus of CloudNativeCon/KubeCon, held every spring in Eur [Blog]: http://blog.kubernetes.io [calendar.google.com]: https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles [CNCF code of conduct]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md -[communication]: /communication.md -[community meeting]: /communication.md#weekly-meeting [events]: https://www.cncf.io/events/ [file an issue]: https://github.com/kubernetes/kubernetes/issues/new [Google+]: https://plus.google.com/u/0/b/116512812300813784482/116512812300813784482 diff --git a/communication/zoom-guidelines.md b/communication/zoom-guidelines.md index 18aec1e1003..26e58fe988f 100644 --- a/communication/zoom-guidelines.md +++ b/communication/zoom-guidelines.md @@ -1,7 +1,7 @@ # Zoom Guidelines Zoom is the main video communication platform for Kubernetes. -It is used for running the [community meeting](https://github.com/kubernetes/community/blob/master/events/community-meeting.md) and SIG meetings. +It is used for running the [community meeting](/events/community-meeting.md) and SIG meetings. Since the Zoom meetings are open to the general public, a Zoom host has to moderate a meeting if a person is in violation of the code of conduct. These guidelines are meant as a tool to help Kubernetes members manage their Zoom resources. @@ -36,7 +36,7 @@ Contact [SIG Contributor Experience](https://github.com/kubernetes/community/tre - @castrojo Each SIG should have at least one person with a paid Zoom account. -See the [SIG Creation procedure](https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procedure) document on how to set up an initial account. +See the [SIG Creation procedure](/sig-governance.md#sig-creation-and-maintenance-procedure) document on how to set up an initial account. The Zoom licenses are managed by the [CNCF Service Desk](https://github.com/cncf/servicedesk). diff --git a/contributors/design-proposals/architecture/declarative-application-management.md b/contributors/design-proposals/architecture/declarative-application-management.md index 14b3677c71b..72888df9d45 100644 --- a/contributors/design-proposals/architecture/declarative-application-management.md +++ b/contributors/design-proposals/architecture/declarative-application-management.md @@ -6,7 +6,7 @@ Most users will deploy a combination of applications they build themselves, also In the case of the latter, users sometimes have the choice of using hosted SaaS products that are entirely managed by the service provider and are therefore opaque, also known as **_blackbox_** *services*. However, they often run open-source components themselves, and must configure, deploy, scale, secure, monitor, update, and otherwise manage the lifecycles of these **_whitebox_** *COTS applications*. -This document proposes a unified method of managing both bespoke and off-the-shelf applications declaratively using the same tools and application operator workflow, while leveraging developer-friendly CLIs and UIs, streamlining common tasks, and avoiding common pitfalls. The approach is based on observations of several dozen configuration projects and hundreds of configured applications within Google and in the Kubernetes ecosystem, as well as quantitative analysis of Borg configurations and work on the Kubernetes [system architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md), [API](https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md), and command-line tool ([kubectl](https://github.com/kubernetes/community/wiki/Roadmap:-kubectl)). +This document proposes a unified method of managing both bespoke and off-the-shelf applications declaratively using the same tools and application operator workflow, while leveraging developer-friendly CLIs and UIs, streamlining common tasks, and avoiding common pitfalls. The approach is based on observations of several dozen configuration projects and hundreds of configured applications within Google and in the Kubernetes ecosystem, as well as quantitative analysis of Borg configurations and work on the Kubernetes [system architecture](architecture.md), [API](/contributors/devel/api-conventions.md), and command-line tool ([kubectl](https://github.com/kubernetes/community/wiki/Roadmap:-kubectl)). The central idea is that a toolbox of composable configuration tools should manipulate configuration data in the form of declarative API resource specifications, which serve as a [declarative data model](https://docs.google.com/document/d/1RmHXdLhNbyOWPW_AtnnowaRfGejw-qlKQIuLKQWlwzs/edit#), not express configuration as code or some other representation that is restrictive, non-standard, and/or difficult to manipulate. @@ -208,7 +208,7 @@ In case it’s not clear from the above, I do not consider configuration schemas Given the pitfalls of parameterization and configuration DSLs, as mentioned at the beginning of this document, configuration tooling should manipulate configuration **data**, not convert configuration to code nor other marked-up syntax, and, in the case of Kubernetes, this data should primarily contain specifications of the **literal Kubernetes API resources** required to deploy the application in the manner desired by the user. The Kubernetes API and CLI (kubectl) were designed to support this model, and our documentation and examples use this approach. -[Kubernetes’s API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md#cluster-control-plane-aka-master) provides IaaS-like container-centric primitives such as Pods, Services, and Ingress, and also lifecycle controllers to support orchestration (self-healing, scaling, updates, termination) of common types of workloads, such as ReplicaSet (simple fungible/stateless app manager), Deployment (orchestrates updates of stateless apps), Job (batch), CronJob (cron), DaemonSet (cluster services), StatefulSet (stateful apps), and [custom third-party controllers/operators](https://coreos.com/blog/introducing-operators.html). The workload controllers, such as Deployment, support declarative upgrades using production-grade strategies such as rolling update, so that the client doesn’t need to perform complex orchestration in the common case. (And we’re moving [proven kubectl features to controllers](https://github.com/kubernetes/kubernetes/issues/12143), generally.) We also deliberately decoupled service naming/discovery and load balancing from application implementation in order to maximize deployment flexibility, which should be preserved by the configuration mechanism. +[Kubernetes’s API](architecture.md#cluster-control-plane-aka-master) provides IaaS-like container-centric primitives such as Pods, Services, and Ingress, and also lifecycle controllers to support orchestration (self-healing, scaling, updates, termination) of common types of workloads, such as ReplicaSet (simple fungible/stateless app manager), Deployment (orchestrates updates of stateless apps), Job (batch), CronJob (cron), DaemonSet (cluster services), StatefulSet (stateful apps), and [custom third-party controllers/operators](https://coreos.com/blog/introducing-operators.html). The workload controllers, such as Deployment, support declarative upgrades using production-grade strategies such as rolling update, so that the client doesn’t need to perform complex orchestration in the common case. (And we’re moving [proven kubectl features to controllers](https://github.com/kubernetes/kubernetes/issues/12143), generally.) We also deliberately decoupled service naming/discovery and load balancing from application implementation in order to maximize deployment flexibility, which should be preserved by the configuration mechanism. [Kubectl apply](https://github.com/kubernetes/kubernetes/issues/15894) [was designed](https://github.com/kubernetes/kubernetes/issues/1702) ([original proposal](https://github.com/kubernetes/kubernetes/issues/1178)) to support declarative updates without clobbering operationally and/or automatically set desired state. Properties not explicitly specified by the user are free to be changed by automated and other out-of-band mechanisms. Apply is implemented as a 3-way merge of the user’s previous configuration, the new configuration, and the live state. @@ -252,7 +252,7 @@ Deployment of bespoke applications involves multiple steps: Step 1, building the image, is out of scope for Kubernetes. Step 3 is covered by kubectl apply. Some tools in the ecosystem, such as [Draft](https://github.com/Azure/draft), combine the 3 steps. -Kubectl contains ["generator" commands](https://github.com/kubernetes/community/blob/master/contributors/devel/kubectl-conventions.md#generators), such as [kubectl run](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#run), expose, various create commands, to create commonly needed Kubernetes resource configurations. However, they also don’t help users understand current best practices and conventions, such as proper label and annotation usage. This is partly a matter of updating them and partly one of making the generated resources suitable for consumption by new users. Options supporting declarative output, such as dry run, local, export, etc., don’t currently produce clean, readable, reusable resource specifications ([example](https://blog.heptio.com/using-kubectl-to-jumpstart-a-yaml-file-heptioprotip-6f5b8a63a3ea))**.** We should clean them up. +Kubectl contains ["generator" commands](/contributors/devel/kubectl-conventions.md#generators), such as [kubectl run](https://kubernetes.io/docs/user-guide/kubectl/v1.7/#run), expose, various create commands, to create commonly needed Kubernetes resource configurations. However, they also don’t help users understand current best practices and conventions, such as proper label and annotation usage. This is partly a matter of updating them and partly one of making the generated resources suitable for consumption by new users. Options supporting declarative output, such as dry run, local, export, etc., don’t currently produce clean, readable, reusable resource specifications ([example](https://blog.heptio.com/using-kubectl-to-jumpstart-a-yaml-file-heptioprotip-6f5b8a63a3ea))**.** We should clean them up. Openshift provides a tool, [oc new-app](https://docs.openshift.com/enterprise/3.1/dev_guide/new_app.html), that can pull source-code templates, [detect](https://github.com/kubernetes/kubernetes/issues/14801)[ application types](https://github.com/kubernetes/kubernetes/issues/14801) and create Kubernetes resources for applications from source and from container images. [podex](https://github.com/kubernetes/contrib/tree/master/podex) was built to extract basic information from an image to facilitate creation of default Kubernetes resources, but hasn’t been kept up to date. Similar resource generation tools would be useful for getting started, and even just [validating that the image really exists](https://github.com/kubernetes/kubernetes/issues/12428) would reduce user error. @@ -322,13 +322,13 @@ Benefits of these approaches: An area where more investigation is needed is explicit inline parameter substitution, which, while overused and should be rendered unnecessary by the capabilities described above, is [frequently requested](https://stackoverflow.com/questions/44832085/passing-variables-to-args-field-in-a-yaml-file-kubernetes) and has been reinvented many times by the community. -A [simple parameterization approach derived from Openshift’s design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md) was approved because it was constrained in functionality and solved other problems (e.g., instantiation of resource variants by other controllers, [project templates in Openshift](https://github.com/openshift/training/blob/master/content/default-project-template.yaml)). That proposal explains some of the reasoning behind the design tradeoffs, as well as the [use cases](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md#use-cases). Work started, but was abandoned, though there is an independent [client-based implementation](https://github.com/InQuicker/ktmpl). However, the Template resource wrapped the resource specifications in another object, which is suboptimal, since transformations would then need to be able to deal with standalone resources, Lists of resources, and Templates, or would need to be applied post-instantiation, and it couldn’t be represented using multiple files, as users prefer. +A [simple parameterization approach derived from Openshift’s design](/contributors/design-proposals/apps/OBSOLETE_templates.md) was approved because it was constrained in functionality and solved other problems (e.g., instantiation of resource variants by other controllers, [project templates in Openshift](https://github.com/openshift/training/blob/master/content/default-project-template.yaml)). That proposal explains some of the reasoning behind the design tradeoffs, as well as the [use cases](/contributors/design-proposals/apps/OBSOLETE_templates.md#use-cases). Work started, but was abandoned, though there is an independent [client-based implementation](https://github.com/InQuicker/ktmpl). However, the Template resource wrapped the resource specifications in another object, which is suboptimal, since transformations would then need to be able to deal with standalone resources, Lists of resources, and Templates, or would need to be applied post-instantiation, and it couldn’t be represented using multiple files, as users prefer. What is more problematic is that our client libraries, schema validators, yaml/json parsers/decoders, initializers, and protobuf encodings all require that all specified fields have valid values, so parameters cannot currently be left in non-string (e.g., int, bool) fields in actual resources. Additionally, the API server requires at least complete/final resource names to be specified, and strategic merge also requires all merge keys to be specified. Therefore, some amount of pre-instantiation (though not necessarily client-side) transformation is necessary to create valid resources, and we may want to explicitly store the output, or the fields should just contain the default values initially. Parameterized fields could be automatically converted to patches to produce valid resources. Such a transformation could be made reversible, unlike traditional substitution approaches, since the patches could be preserved (e.g., using annotations). The Template API supported the declaration of parameter names, display names, descriptions, default values, required/optional, and types (string, int, bool, base64), and both string and raw json substitutions. If we were to update that specification, we could use the same mechanism for both parameter validation and ConfigMap validation, so that the same mechanism could be used for env substitution and substitution of values of other fields. As mentioned in the [env validation issue](https://github.com/kubernetes/kubernetes/issues/4210#issuecomment-305555589), we should consider a subset of [JSON schema](http://json-schema.org/example1.html), which we’ll probably use for CRD. The only [unsupported attribute](https://tools.ietf.org/html/draft-wright-json-schema-validation-00) appears to be the display name, which is non-critical. [Base64 could be represented using media](http://json-schema.org/latest/json-schema-hypermedia.html#rfc.section.5.3.2). That could be useful as a common parameter schema to facilitate parameter discovery and documentation that is independent of the substitution syntax and mechanism ([example from Deployment Manager](https://github.com/GoogleCloudPlatform/deploymentmanager-samples/blob/master/templates/replicated_service.py.schema)). Without parameters how would we support a click-to-deploy experience? People who are kicking the tires, have undemanding use cases, are learning, etc. are unlikely to know what customization they want to perform initially, if they even need any. The main information users need to provide is the name prefix they want to apply. Otherwise, choosing among a few alternatives would suit their needs better than parameters. The overlay approach should support that pretty well. Beyond that, I suggest kicking users over to a Kubernetes-specific configuration wizard or schema-aware IDE, and/or support a fork workflow. -The other application-definition [use cases mentioned in the Template proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/templates.md#use-cases) are achievable without parameterization, as well. +The other application-definition [use cases mentioned in the Template proposal](/contributors/design-proposals/apps/OBSOLETE_templates.md#use-cases) are achievable without parameterization, as well. #### What about application configuration generation? diff --git a/contributors/guide/README.md b/contributors/guide/README.md index 1b9d12ce12f..6ef1b277dd6 100644 --- a/contributors/guide/README.md +++ b/contributors/guide/README.md @@ -133,7 +133,7 @@ For quick reference on contributor resources, we have a handy [contributor cheat It is best to contact your [SIG](#learn-about-sigs) for issues related to the SIG's topic. Your SIG will be able to help you much more quickly than a general question would. -For general questions and troubleshooting, use the [kubernetes standard lines of communication](/communication.md) and work through the [kubernetes troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/). +For general questions and troubleshooting, use the [kubernetes standard lines of communication](/communication/README.md) and work through the [kubernetes troubleshooting guide](https://kubernetes.io/docs/tasks/debug-application-cluster/troubleshooting/). ## GitHub workflow diff --git a/generator/list.tmpl b/generator/list.tmpl index d09989da25e..3ebf7a1a46b 100644 --- a/generator/list.tmpl +++ b/generator/list.tmpl @@ -2,14 +2,14 @@ # SIGs and Working Groups Most community activity is organized into Special Interest Groups (SIGs), -time bounded Working Groups, and the [community meeting](communication.md#weekly-meeting). +time bounded Working Groups, and the [community meeting](communication/README.md#weekly-meeting). SIGs follow these [guidelines](governance.md) although each of these groups may operate a little differently depending on their needs and workflow. Each group's material is in its subdirectory in this project. -When the need arises, a [new SIG can be created](sig-creation-procedure.md) +When the need arises, a [new SIG can be created](sig-governance.md#sig-creation-and-maintenance-procedure). ### Master SIG List diff --git a/github-management/kubernetes-repositories.md b/github-management/kubernetes-repositories.md index 7b1faf3b098..05b4a646390 100644 --- a/github-management/kubernetes-repositories.md +++ b/github-management/kubernetes-repositories.md @@ -38,7 +38,7 @@ To provide a place for SIGs to collaborate on projects endorsed by and actively * Must adopt the CNCF CLA bot, merge bot and Kubernetes PR commands/bots. * All OWNERS of the project must also be active SIG members. * SIG membership must vote using lazy consensus to create a new repository - * SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in [`sigs.yaml`](https://github.com/kubernetes/community/blob/master/sigs.yaml) + * SIG must already have identified all of their existing subprojects and code, with valid OWNERS files, in [`sigs.yaml`](sigs.yaml). #### Rules for donated repositories diff --git a/keps/sig-contributor-experience/0007-20180403-community-forum.md b/keps/sig-contributor-experience/0007-20180403-community-forum.md index a274f3ee110..f888f849222 100644 --- a/keps/sig-contributor-experience/0007-20180403-community-forum.md +++ b/keps/sig-contributor-experience/0007-20180403-community-forum.md @@ -43,7 +43,7 @@ status: provisional Kubernetes is large enough that we should take a more active role in growing our community. We need a place to call our own that can encompass users, contributors, meetups, and other groups in the community. Is there a need for something between email and real time chat that can fulfill this? The primary purpose of this KEP is to determine whether we can provide a better community forum experience and perhaps improve our mailing list workflow. -The site would be forum.k8s.io, and would be linked to from the homepage and major properties. [See KEP005](https://github.com/kubernetes/community/blob/master/keps/sig-contributor-experience/0005-contributor-site.md) for related information on a contributor website. +The site would be forum.k8s.io, and would be linked to from the homepage and major properties. [See KEP005](0005-contributor-site.md) for related information on a contributor website. ## Motivation diff --git a/keps/sig-node/0008-20180430-promote-sysctl-annotations-to-fields.md b/keps/sig-node/0008-20180430-promote-sysctl-annotations-to-fields.md index 8966b81867e..f4cf3d8ca71 100644 --- a/keps/sig-node/0008-20180430-promote-sysctl-annotations-to-fields.md +++ b/keps/sig-node/0008-20180430-promote-sysctl-annotations-to-fields.md @@ -82,11 +82,11 @@ in the following way: ... ``` -The `sysctl` design document with more details and rationals is available at [design-proposals/node/sysctl.md](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/sysctl.md#pod-api-changes) +The `sysctl` design document with more details and rationals is available at [`design-proposals/node/sysctl.md`](/contributors/design-proposals/node/sysctl.md#pod-api-changes). ## Motivation -As mentioned in [contributors/devel/api_changes.md#alpha-field-in-existing-api-version](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field-in-existing-api-version): +As mentioned in [`contributors/devel/api_changes.md#alpha-field-in-existing-api-version`](/contributors/devel/api_changes.md#alpha-field-in-existing-api-version): > Previously, annotations were used for experimental alpha features, but are no longer recommended for several reasons: > @@ -129,7 +129,7 @@ of the feature. - net.* ``` - More examples at [design-proposals/node/sysctl.md#allowing-only-certain-sysctls](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/sysctl.md#allowing-only-certain-sysctls) + More examples at [`design-proposals/node/sysctl.md#allowing-only-certain-sysctls`](/contributors/design-proposals/node/sysctl.md#allowing-only-certain-sysctls) ### Promote `--experimental-allowed-unsafe-sysctls` kubelet flag to kubelet config api option @@ -201,7 +201,7 @@ type PodSecurityPolicySpec struct { } ``` -Following steps in [devel/api_changes.md#alpha-field-in-existing-api-version](https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field-in-existing-api-version) +Following steps in [`contributors/devel/api_changes.md#alpha-field-in-existing-api-version`](/contributors/devel/api_changes.md#alpha-field-in-existing-api-version) during implemention. Validation checks implemented as part of [#27180](https://github.com/kubernetes/kubernetes/pull/27180). diff --git a/sig-creation-procedure.md b/sig-creation-procedure.md index ad2a9942473..fb1b952e26c 100644 --- a/sig-creation-procedure.md +++ b/sig-creation-procedure.md @@ -1,3 +1,3 @@ ## SIG creation procedure -Moved to [sig governance](/sig-governance.md#sig-creation-procedure) +Moved to [sig governance](/sig-governance.md#sig-creation-and-maintenance-procedure) diff --git a/sig-list.md b/sig-list.md index 731989423b8..cba413f3314 100644 --- a/sig-list.md +++ b/sig-list.md @@ -9,14 +9,14 @@ To understand how this file is generated, see https://git.k8s.io/community/gener # SIGs and Working Groups Most community activity is organized into Special Interest Groups (SIGs), -time bounded Working Groups, and the [community meeting](communication.md#weekly-meeting). +time bounded Working Groups, and the [community meeting](communication/README.md#weekly-meeting). SIGs follow these [guidelines](governance.md) although each of these groups may operate a little differently depending on their needs and workflow. Each group's material is in its subdirectory in this project. -When the need arises, a [new SIG can be created](sig-creation-procedure.md) +When the need arises, a [new SIG can be created](sig-governance.md#sig-creation-and-maintenance-procedure). ### Master SIG List diff --git a/sig-scalability/processes/formal-scalability-processes.md b/sig-scalability/processes/formal-scalability-processes.md index 1c1f7289cad..f407e8c0cf3 100644 --- a/sig-scalability/processes/formal-scalability-processes.md +++ b/sig-scalability/processes/formal-scalability-processes.md @@ -65,7 +65,7 @@ These are scalability jobs that would run against the PR at the head of the subm - Kubemark-500 (time to run: [~50m](https://k8s-gubernator.appspot.com/builds/kubernetes-jenkins/logs/ci-kubernetes-kubemark-500-gce?before=10000), flakiness: [0%](https://k8s-gubernator.appspot.com/builds/kubernetes-jenkins/logs/ci-kubernetes-kubemark-500-gce?before=11251) in last 100 runs (as of 15/1/18) - GCE-100 (time to run: [~40m](https://k8s-gubernator.appspot.com/builds/kubernetes-jenkins/logs/ci-kubernetes-e2e-gci-gce-scalability?before=8366), flakiness: [1%](https://k8s-gubernator.appspot.com/builds/kubernetes-jenkins/logs/ci-kubernetes-e2e-gci-gce-scalability?before=9970) in last 100 runs (as of 15/1/18) -About 60% of scalability regressions are caught by these medium-scale jobs ([source](https://github.com/kubernetes/community/blob/master/sig-scalability/blogs/scalability-regressions-case-studies.md)) and having them run as presubmits will greatly help by preventing those from entering. +About 60% of scalability regressions are caught by these medium-scale jobs ([source](/sig-scalability/blogs/scalability-regressions-case-studies.md)) and having them run as presubmits will greatly help by preventing those from entering. ### Testing / Post-submit phase diff --git a/sig-storage/volume-plugin-faq.md b/sig-storage/volume-plugin-faq.md index 1dc66a9a056..8502a130a3b 100644 --- a/sig-storage/volume-plugin-faq.md +++ b/sig-storage/volume-plugin-faq.md @@ -67,8 +67,7 @@ For more information on how to write and deploy a CSI Driver on Kubernetes, see FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes since version 1.2 (before CSI). It uses an exec-based model to interface with drivers. FlexVolume driver binaries must be installed on host machines. Kubernetes performs volume operations by executing pre-defined commands in the FlexVolume API against the driver on the host. FlexVolume is GA as of Kubernetes 1.8. -For more information about Flex, see: -* https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md +For more information about Flex, see [the FlexVolume docs](/contributors/devel/flexvolume.md). **What are the limitations of FlexVolume?** diff --git a/sig-windows/README.md b/sig-windows/README.md index 58219c9bcd7..96f93e94baf 100644 --- a/sig-windows/README.md +++ b/sig-windows/README.md @@ -62,7 +62,7 @@ We're currently using a public [Trello board](https://trello.com/b/rjTqrwjl/wind As always, you can also find the active list of open issues and proposals [Open Code Issues and PRs for SIG/Windows](https://github.com/kubernetes/kubernetes/labels/sig%2Fwindows) on GitHub. ## API tracking -We also have an [API tracking](https://github.com/kubernetes/community/blob/master/sig-windows/api-tracking.md) document that we're building out to track areas where the APIs may not be implemented or need to change for Windows. +We also have an [API tracking](api-tracking.md) document that we're building out to track areas where the APIs may not be implemented or need to change for Windows. ## Meeting Recordings