Merge pull request #3928 from carlory/fix-01

fix broken links because design proposals have been archived

Author: k8s-ci-robot

keps/sig-api-machinery/2334-graduate-server-side-get-and-partial-objects-to-GA/kep.yaml

@@ -17,7 +17,7 @@ creation-date: 2019-03-22
 last-updated: 2019-03-22
 status: implementable
 see-also:
-  - "https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/server-get.md"
+  - "https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/server-get.md"
 replaces:
 superseded-by:
 

keps/sig-api-machinery/492-admission-webhooks/kep.yaml

@@ -14,6 +14,6 @@ creation-date: 2019-01-27
 last-updated: 2019-02-04
 status: implemented
 see-also:
-  - "[Admission Control Webhook Beta Design Doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/admission-control-webhooks.md)"
+  - "[Admission Control Webhook Beta Design Doc](https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/admission-control-webhooks.md)"
 latest-milestone: '0.0'
 stage: stable

keps/sig-api-machinery/598-crd-conversion-webhook/kep.yaml

@@ -17,6 +17,6 @@ creation-date: 2019-04-25
 last-updated: 2019-04-25
 status: implemented
 replaces:
-  - "(https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md)"
+  - "(https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/customresource-conversion-webhook.md)"
 latest-milestone: '0.0'
 stage: stable

keps/sig-api-machinery/692-crd-openapi-schema/README.md

@@ -20,7 +20,7 @@
 ## Summary
 
 In CustomResourceDefinition (CRD) we allow CRD author to define OpenAPI v3 schema, to
-enable server-side [validation for CustomResources (CR)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md).
+enable server-side [validation for CustomResources (CR)](https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/customresources-validation.md).
 The validation schema format is compatible for creating OpenAPI documentation for CRs,
 which can be used by clients like kubectl to perform client-side validation
 (e.g. `kubectl create` and `kubectl apply`),
@@ -34,7 +34,7 @@ Publishing CRD OpenAPI enables client-side validation, schema explanation and
 client generation for CRs. It covers the gap between CR and native Kubernetes
 APIs, which already support OpenAPI documentation.
 
-Publishing CRD OpenAPI is also noted as potential followup in [Validation for CustomResources Implementation Plan](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md#implementation-plan).
+Publishing CRD OpenAPI is also noted as potential followup in [Validation for CustomResources Implementation Plan](https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/customresources-validation.md#implementation-plan).
 
 ### Goals
 

keps/sig-api-machinery/692-crd-openapi-schema/kep.yaml

@@ -16,7 +16,7 @@ creation-date: 2019-02-07
 last-updated: 2019-02-13
 status: implemented
 see-also:
-  - "[Validation for CustomResources design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md)"
+  - "[Validation for CustomResources design doc](https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/customresources-validation.md)"
 
 latest-milestone: "1.19"
 stage: "stable"

keps/sig-api-machinery/95-custom-resource-definitions/README.md

@@ -106,7 +106,7 @@ CRD to GA graduation.
 The CRD `v1` API will be the same as the `v1beta1` but with all changes to the API from the GA tasks:
 
 * Rename misnamed json field [JSONPath](https://github.com/kubernetes/kubernetes/blob/06bc7e3e0026ea25065f59f4bd305c0b7dbbc145/staging/src/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1beta1/types.go#L226-L227) to `jsonPath`
-* [Replace top-level fields with per version fields](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresource-conversion-webhook.md#top-level-fields-to-per-version-fields)
+* [Replace top-level fields with per version fields](https://github.com/kubernetes/design-proposals-archive/blob/master/api-machinery/customresource-conversion-webhook.md#top-level-fields-to-per-version-fields)
 * Restrict OpenAPI per [Vanilla OpenAPI Subset Design](https://docs.google.com/document/d/1pcGlbmw-2Y0JJs9hsYnSBXamgG9TfWtHY6eh80zSTd8)
 
 ## Test Plan

keps/sig-apps/1591-daemonset-surge/README.md

@@ -49,7 +49,7 @@ It should be possible for a node level integration to offer zero-downtime upgrad
 
 ### Implementation Details/Notes/Constraints
 
-The design of Deployment rolling updates introduced the surge concept, and the initial design for DaemonSet updates considered the implications of adding the Surge strategy later (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/apps/daemonset-update.md#future-plans). [StatefulSets may also surge in a workload specific fashion](https://github.com/kubernetes/enhancements/pull/1863), so this design should be as consistent as possible with existing concepts but clearly denote where the workload concept differs from other controllers.
+The design of Deployment rolling updates introduced the surge concept, and the initial design for DaemonSet updates considered the implications of adding the Surge strategy later (https://github.com/kubernetes/design-proposals-archive/blob/master/apps/daemonset-update.md#future-plans). [StatefulSets may also surge in a workload specific fashion](https://github.com/kubernetes/enhancements/pull/1863), so this design should be as consistent as possible with existing concepts but clearly denote where the workload concept differs from other controllers.
 
 We would add `MaxSurge *intstr.IntOrString` to the RollingUpdate daemonset upgrade strategy. It would have a default value of 0, preserving current behavior. We would allow MaxUnavailable to be 0 when MaxSurge is set.
 

keps/sig-apps/19-Graduate-CronJob-to-Stable/kep.yaml

@@ -21,7 +21,7 @@ approvers:
   - "@wojtek-t"
 see-also:
 replaces:
-  - "https://github.com/kubernetes/community/blob/master/contributors/design-proposals/apps/cronjob.md"
+  - "https://github.com/kubernetes/design-proposals-archive/blob/master/apps/cronjob.md"
 
 # The target maturity stage in the current dev cycle for this KEP.
 stage: stable

keps/sig-cli/2379-kubectl-plugins/kep.yaml

@@ -20,7 +20,7 @@ status: implemented
 see-also:
   - "https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3638-kubectl-plugin-subcommands"
 replaces:
-  - "https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cli/kubectl-extension.md"
+  - "https://github.com/kubernetes/design-proposals-archive/blob/master/cli/kubectl-extension.md"
   - "https://github.com/kubernetes/community/pull/481"
 superseded-by:
   - n/a

keps/sig-cli/2906-kustomize-function-catalog/README.md

@@ -164,7 +164,7 @@ This new API will provide a standardized way to define a collection of one or mo
 
 ### Key terminology
 
-*KRM*: [Kubernetes Resource Model](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md)
+*KRM*: [Kubernetes Resource Model](https://github.com/kubernetes/design-proposals-archive/blob/master/architecture/resource-management.md)
 
  *Function*: A program conforming to the spec described in [this document](https://github.com/kubernetes-sigs/kustomize/blob/master/cmd/config/docs/api-conventions/functions-spec.md#krm-functions-specification).
 

keps/sig-cli/2953-kustomize-plugin-graduation/README.md

@@ -177,7 +177,7 @@ This KEP proposes converging Kustomize's various alpha extension mechanisms into
 
 ### Key terminology
 
-*KRM*: [Kubernetes Resource Model](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/resource-management.md)
+*KRM*: [Kubernetes Resource Model](https://github.com/kubernetes/design-proposals-archive/blob/master/architecture/resource-management.md)
 
 *Plugin*: User-authored generator, transformer or validator (refers to both the program that implements it and the "config" YAML required to use it).
 

keps/sig-cloud-provider/2392-cloud-controller-manager/README.md

@@ -230,7 +230,7 @@ config maps.
 
 There are two entirely different approach to refactoring volumes -
 [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) and
-[CSI Container Storage Interface](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md). There is an undergoing effort to move all
+[CSI Container Storage Interface](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/container-storage-interface.md). There is an undergoing effort to move all
 of the volume logic from the controller-manager into plugins called Flex Volumes. In the Flex volumes world, all of the
 vendor specific code will be packaged in a separate binary as a plugin. After discussing with @thockin, this was
 decidedly the best approach to remove all cloud provider dependency for volumes out of kubernetes core. Some of the discovery

keps/sig-cloud-provider/2436-controller-manager-leader-migration/README.md

@@ -89,7 +89,7 @@ the respective out-of-tree cloud-controller-manager.
 
 * Removing cloud provider code from the core Kubernetes tree, this effort is separate and is covered in [KEP-removing-in-tree-providers](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cloud-provider/20190125-removing-in-tree-providers.md)
 * Improving the scalability of controllers by running controllers across multiple components (with or without leader election).
-* Migrating cloud-based volume plugins to CSI. This is a separate effort led by SIG Storage. See [this proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-migration.md) for more details.
+* Migrating cloud-based volume plugins to CSI. This is a separate effort led by SIG Storage. See [this proposal](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/csi-migration.md) for more details.
 
 ## Proposal
 

keps/sig-cloud-provider/669-out-of-tree-openstack/README.md

@@ -52,7 +52,7 @@ This KEP is specifically tracking progress for the OpenStack cloud provider.
 The OpenStack Cloud Provider is implemented, tested and documented, It is being released with matching kubernetes version from [release v1.11](https://github.com/kubernetes/cloud-provider-openstack/releases). cloud-provider-openstack release 1.14, 1.15, 1.16 has been running in production.
 
 ### Implementation Details/Notes/Constraints [optional]
-OpenStack Cloud Provider is implemented [here](https://github.com/kubernetes/cloud-provider-openstack/releases). This repository also hosts other drivers like CSI, ingress-controller etc. Cloud Provider OpenStack is in feature parity with the intree version. Removal of intree cloud providers is dependent on [In-tree Storage Migration to CSI Plugin Migration](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-migration.md). The migration work for intree OpenStack Volume driver to CSI Driver is in progress.
+OpenStack Cloud Provider is implemented [here](https://github.com/kubernetes/cloud-provider-openstack/releases). This repository also hosts other drivers like CSI, ingress-controller etc. Cloud Provider OpenStack is in feature parity with the intree version. Removal of intree cloud providers is dependent on [In-tree Storage Migration to CSI Plugin Migration](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/csi-migration.md). The migration work for intree OpenStack Volume driver to CSI Driver is in progress.
 
 ### Risks and Mitigations
 

keps/sig-cloud-provider/670-out-of-tree-vsphere/README.md

@@ -57,7 +57,7 @@ The vSphere Cloud Provider is implemented, tested and partially documented. The
 ### Implementation Details/Notes/Constraints [optional]
 
 Main provider work is completed and feature parity with in-tree will be achieved with the beta version. Removing in-tree `vsphere_volume` code is underway in the same repo and will piggyback on and be tracked through the
-[In-tree Storage Migration to CSI Plugin Migration](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/csi-migration.md)
+[In-tree Storage Migration to CSI Plugin Migration](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/csi-migration.md)
 work. New features will need to follow the community KEP process.
 
 ### Risks and Mitigations

keps/sig-cloud-provider/azure/586-azure-availability-zones/README.md

@@ -182,11 +182,11 @@ func (l *persistentVolumeLabel) Admit(a admission.Attributes) (err error) {
 
 ### StorageClass
 
-Note that the above interfaces are only applied to AzureDisk persistent volumes, not StorageClass. For AzureDisk StorageClass, we should add a few new options for zone-aware and [topology-aware](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-topology-scheduling.md) provisioning. The following three new options will be added in AzureDisk StorageClass:
+Note that the above interfaces are only applied to AzureDisk persistent volumes, not StorageClass. For AzureDisk StorageClass, we should add a few new options for zone-aware and [topology-aware](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/volume-topology-scheduling.md) provisioning. The following three new options will be added in AzureDisk StorageClass:
 
 - `zoned`: indicates whether new disks are provisioned with AZ. Default is `true`.
 - `zone` and `zones`: indicates which zones should be used to provision new disks (zone-aware provisioning). Only can be set if `zoned` is not false and `allowedTopologies` is not set.
-- `allowedTopologies`: indicates which topologies are allowed for [topology-aware](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-topology-scheduling.md) provisioning. Only can be set if `zoned` is not false and `zone`/`zones` are not set.
+- `allowedTopologies`: indicates which topologies are allowed for [topology-aware](https://github.com/kubernetes/design-proposals-archive/blob/master/storage/volume-topology-scheduling.md) provisioning. Only can be set if `zoned` is not false and `zone`/`zones` are not set.
 
 An example of zone-aware provisioning storage class is:
 

keps/sig-cluster-lifecycle/clusterapi/2495-Kubernetes-Cluster-Management-API/README.md

@@ -58,7 +58,7 @@ When another component needs to create or destroy virtual machines, like the nod
 
 * Should a single Kubernetes cluster only house definitions for itself?
    * If so, that removes the ability to have a single cluster control the reconciliation of infrastructure for other clusters.
-   * However, with the concurrent [Cluster Registry](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multicluster/cluster-registry/api-design.md) project, a good separation of responsibilities would be that the Cluster Registry API is responsible for indexing multiple clusters, each of which would only have to know about itself. In order to achieve cross-cluster reconciliation, a controller would need to integrate with a Cluster Registry for discovery.
+   * However, with the concurrent [Cluster Registry](https://github.com/kubernetes/design-proposals-archive/blob/master/multicluster/cluster-registry/api-design.md) project, a good separation of responsibilities would be that the Cluster Registry API is responsible for indexing multiple clusters, each of which would only have to know about itself. In order to achieve cross-cluster reconciliation, a controller would need to integrate with a Cluster Registry for discovery.
 * Should a cluster’s control plane definition should be housed within that same cluster.
    * If the control plane becomes unhealthy, then it won’t be able to rectify itself without external intervention. If the control plane configuration lives elsewhere, and the controllers reconciling its state are able to act in the face of control plane failure, then this API could be used to fix a misconfigured control plane that is unresponsive.
 * Should our representation of Nodes allow declarative versioning of non-Kubernetes packages, like the container runtime, the Linux kernel, etc.?

keps/sig-cluster-lifecycle/kubeadm/1177-kubeadm-with-kustomize/README.md

@@ -126,7 +126,7 @@ As a cluster administrator, I want to upgrade my cluster preserving all the
 
 This proposal explores as a first option for implementing Kubeadm
 “advanced configurations“ the usage of Kustomize; please refer to
-[Declarative application management in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md)
+[Declarative application management in Kubernetes](https://github.com/kubernetes/design-proposals-archive/blob/master/architecture/declarative-application-management.md)
 and [Kustomize KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/0008-kustomize.md)
 for background information about Kustomize.
 
@@ -344,7 +344,7 @@ See risks and mitigations.
 
 ## Alternatives
 
-There are many alternatives to “Kustomize” in the ecosystem; see [Declarative application management in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md).
+There are many alternatives to “Kustomize” in the ecosystem; see [Declarative application management in Kubernetes](https://github.com/kubernetes/design-proposals-archive/blob/master/architecture/declarative-application-management.md).
 
 While there is great value in several different approaches “Kustomize” was selected as
 the first choice for this proposal because it already has first-class supported in

keps/sig-instrumentation/383-new-event-api-ga-graduation/README.md

@@ -71,7 +71,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 
 The KEP aims at fixing few issues in the current way Events are structured and implemented. This effort has two main goals - reduce the performance impact that Events have on the rest of the cluster and add more structure to the Event object which is the first and necessary step to make it possible to automate Event analysis.
 
-Most sections and design details are copied from the original design doc: [Make Kubernetes Events Useful and Safe](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/events-redesign.md).
+Most sections and design details are copied from the original design doc: [Make Kubernetes Events Useful and Safe](https://github.com/kubernetes/design-proposals-archive/blob/master/instrumentation/events-redesign.md).
 
 The new Event API has been promoted from v1beta1 to v1 in 1.19 and currently only scheduler was migrated to use it.
 
@@ -692,7 +692,7 @@ _This section must be completed when targeting beta graduation to a release._
 
 ## Implementation History
 
-- 2017-10-7 design proposal merged under [kubernetes/community](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/events-redesign.md)
+- 2017-10-7 design proposal merged under [kubernetes/community](https://github.com/kubernetes/design-proposals-archive/blob/master/instrumentation/events-redesign.md)
 - 2017-11-23 Event API group is [merged](https://github.com/kubernetes/kubernetes/pull/49112)
 - New Event API [staging/src/k8s.io/client-go/kubernetes/typed/events/v1beta1](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/client-go/kubernetes/typed/events/v1beta1)
 - Scheduler migration: [#78447](https://github.com/kubernetes/kubernetes/pull/78447/files), [#83692](https://github.com/kubernetes/kubernetes/pull/83692)

keps/sig-network/427-coredns/README.md

@@ -63,7 +63,7 @@ For other tools, each maintainer would have to add the upgrade to CoreDNS.
 
 ### Use Cases
 
-* CoreDNS supports all functionality of kube-dns and also addresses [several use-cases kube-dns lacks](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/network/coredns.md#use-cases). Some of the Use Cases are as follows: 
+* CoreDNS supports all functionality of kube-dns and also addresses [several use-cases kube-dns lacks](https://github.com/kubernetes/design-proposals-archive/blob/master/network/coredns.md#use-cases). Some of the Use Cases are as follows: 
     * Supporting [Autopath](https://coredns.io/plugins/autopath/), which reduces the high query load caused by the long DNS search path in Kubernetes.
     * Making an alias for an external name [#39792](https://github.com/kubernetes/kubernetes/issues/39792)
 

keps/sig-node/135-seccomp/README.md

@@ -703,4 +703,4 @@ If both seccomp annotations _and_ fields are specified in the updated PSP, the v
 
 ## References
 
-- [Original seccomp proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/seccomp.md)
+- [Original seccomp proposal](https://github.com/kubernetes/design-proposals-archive/blob/master/node/seccomp.md)