No more dead links in serving md files (#3146)

* No more dead links in serving md files

* updated test-infra to get the new markdown link checker
* fixed all dead links in the docs
* ran the link checker on all docs

* Fix markdown files

* Update docs/roadmap/scaling-2018.md

Co-Authored-By: adrcunha <[email protected]>

docs/roadmap/scaling-2018.md

@@ -4,11 +4,11 @@ This is what we hope to accomplish in 2018.
 
 ## References
 
-[Autoscaling Design Goals](README.md#design-goals):
+[Autoscaling Design Goals](../scaling/DEVELOPMENT.md#design-goals):
 
 1. _Make it fast_
-2. _Make it light_
-3. _Make everything better_
+1. _Make it light_
+1. _Make everything better_
 
 In 2018 we will focus primarily on making autoscaling correct, fast and light.
 
@@ -17,25 +17,26 @@ In 2018 we will focus primarily on making autoscaling correct, fast and light.
 1. **Correctness**. When scaling from 0-to-1, 1-to-N and back down, error rates
    must not increase. We must have visibility of correctness over time at small
    and large scales.
-2. **Performance**. When scaling from 1-to-N and back down, autoscaling must
+1. **Performance**. When scaling from 1-to-N and back down, autoscaling must
    maintain reasonable latency. The Knative Serving implementation of
    autoscaling must be competitive in its ability to serve variable load.
-3. **Scale to zero**. Idle ([Reserve](README.md#behavior)) Revisions must cost
-   nothing. Reserve Revisions must serve the first request in 1 second or less.
-4. **Development**. Autoscaler development must follow a clear roadmap. Getting
+1. **Scale to zero**. Idle ([Reserve](../scaling/DEVELOPMENT.md#behavior))
+   Revisions must cost nothing. Reserve Revisions must serve the first request
+   in 1 second or less.
+1. **Development**. Autoscaler development must follow a clear roadmap. Getting
    started as a developer must be easy and the team must scale horizontally.
-5. **Integration**. Autoscaler should be pluggable and support multiple
+1. **Integration**. Autoscaler should be pluggable and support multiple
    strategies and workloads.
 
 ### Correctness
 
 1. **Write autoscaler end-to-end tests** to cover low-scale regressions,
    runnable by individual developers before checkin.
    ([#420](https://github.com/knative/serving/issues/420))
-2. **Test error rates at high scale** to cover regressions at larger scales
+1. **Test error rates at high scale** to cover regressions at larger scales
    (~1000 QPS and ~1000 clients).
    ([#421](https://github.com/knative/serving/issues/421))
-3. **Test error rates around idle states** to cover various scale-to-zero edge
+1. **Test error rates around idle states** to cover various scale-to-zero edge
    cases. ([#422](https://github.com/knative/serving/issues/422))
 
 ### Performance
@@ -44,11 +45,11 @@ In 2018 we will focus primarily on making autoscaling correct, fast and light.
    and guide development. We need to establish the code to run, the request load
    to generate, and the performance expected. This will tell us where we need to
    improve.
-2. **Reproducable load tests** which can be run by anyone with minimal setup.
+1. **Reproducible load tests** which can be run by anyone with minimal setup.
    These must be transparent and easy to run. They must be meaningful tests
    which prove autoscaler performance.
    ([#424](https://github.com/knative/serving/pull/424))
-3. **Vertical pod autoscaling** to allow revisions to adapt the differing
+1. **Vertical pod autoscaling** to allow revisions to adapt the differing
    requirements of user's code. Rather than applying the same resource requests
    to all revision deployments, use vertical pod autoscaler (or something) to
    adjust the resources required. Resource requirements for one revision should
@@ -61,7 +62,7 @@ In 2018 we will focus primarily on making autoscaling correct, fast and light.
    after a period of inactivity. And scale back up from zero to one with the
    first request. The first requests should succeed (even if latency is high)
    and then latency should return to normal levels once the revision is active.
-2. **Reduce Reserve Revision start time** from 4 seconds to 1 second or less.
+1. **Reduce Reserve Revision start time** from 4 seconds to 1 second or less.
    Maybe we can keep some resources around like the Replica Set or pre-cache
    images so that Pods are spun up faster.
 
@@ -76,14 +77,14 @@ In 2018 we will focus primarily on making autoscaling correct, fast and light.
 1. **Autoscaler multitenancy** will allow the autoscaler to remain "always on".
    It will also reduce the overhead of running one single-tenant autoscaler pod
    per revision.
-2. **Consume custom metrics API** as an abstraction to allow pluggability. This
+1. **Consume custom metrics API** as an abstraction to allow pluggability. This
    may require another metrics aggregation component to get the queue-proxy
    produced concurrency metrics behind a custom metrics API. It will also allow
    autoscaling based on Prometheus metrics through an adapter. A good acceptance
    criteria is the ability to plug in the vanilla Horizontal Pod Autoscaler
    (HPA) in lieu of the Knative Serving autoscaler (minus scale-to-zero
    capabilities).
-3. **Autoscale queue-based workloads** in addition to request/reply workloads.
+1. **Autoscale queue-based workloads** in addition to request/reply workloads.
    The first use-case is the integration of Riff autoscaling into the
    multitenant autoscaler. The autoscaler must be able to select the appropriate
    strategy for scaling the revision.
@@ -98,12 +99,12 @@ to Design Goal #3: _make everything better_.
    enforce serialization of requests to the application container. This only
    applies in single-threaded mode. It would allow us to remove the Queue Proxy
    entirely. But it would probably require feature work in Envoy/Istio.
-2. **Remove metrics reporting from the Queue Proxy** in order to rely on a
+1. **Remove metrics reporting from the Queue Proxy** in order to rely on a
    common, Knative Serving metrics pipeline. This could mean polling the Pods to
    get the same metrics as are reported to Prometheus. Or going to Prometheus to
    get the metrics it has aggregated. It means removing the metrics push from
-   the [Queue Proxy to the Autoscaler](README.md#context).
-3. **[Slow Brain](README.md#slow-brain--fast-brain) implementation** to
-   automatically adjust target concurrency to the application's behavior.
+   the [Queue Proxy to the Autoscaler](../scaling/DEVELOPMENT.md#context).
+1. **[Slow Brain](../scaling/DEVELOPMENT.md#slow-brain--fast-brain) implementation**
+   to automatically adjust target concurrency to the application's behavior.
    Instead, we can rely on vertical pod autoscaling for now to size the pod to
    an average of one request at a time.

docs/scaling/DEVELOPMENT.md

@@ -28,8 +28,8 @@ incoming traffic.
 Revisions have three autoscaling states which are:
 
 1. **Active** when they are actively serving requests,
-2. **Reserve** when they are scaled down to 0 Pods but is still in service, and
-3. **Retired** when they will no longer receive traffic.
+1. **Reserve** when they are scaled down to 0 Pods but is still in service, and
+1. **Retired** when they will no longer receive traffic.
 
 When a Revision is actively serving requests it will increase and decrease the
 number of Pods to maintain the desired average concurrent requests per Pod. When
@@ -95,9 +95,9 @@ The following diagram illustrates the mechanics of the autoscaler:
 
 1. **Make it fast**. Revisions should be able to scale from 0 to 1000 concurrent
    requests in 30 seconds or less.
-2. **Make it light**. Wherever possible the system should be able to figure out
+1. **Make it light**. Wherever possible the system should be able to figure out
    the right thing to do without the user's intervention or configuration.
-3. **Make everything better**. Creating custom components is a short-term
+1. **Make everything better**. Creating custom components is a short-term
    strategy to get something working now. The long-term strategy is to make the
    underlying components better so that custom code can be replaced with
    configuration. E.g. Autoscaler should be replaced with the K8s
@@ -111,7 +111,7 @@ The Knative Serving Autoscaler is split into two parts:
 
 1. **Fast Brain** that maintains the desired level of concurrent requests per
    Pod (satisfying [Design Goal #1](#design-goals)), and the
-2. **Slow Brain** that comes up with the desired level based on CPU, memory and
+1. **Slow Brain** that comes up with the desired level based on CPU, memory and
    latency statistics (satisfying [Design Goal #2](#design-goals)).
 
 ## Fast Brain Implementation
@@ -123,8 +123,7 @@ This is subject to change as the Knative Serving implementation changes.
 - [Autoscaler Library](../../pkg/autoscaler/autoscaler.go)
 - [Autoscaler Binary](../../cmd/autoscaler/main.go)
 - [Queue Proxy Binary](../../cmd/queue/main.go)
-- [Autoscaling Controller](../../pkg/controller/autoscaling/autoscaling.go)
-- [Statistics Server](../../pkg/server/stats/server.go)
+- [Statistics Server](../../pkg/autoscaler/statserver/server.go)
 
 ### Autoscaler
 
@@ -140,7 +139,7 @@ pushes a gob serialized struct with the observed number of concurrent requests
 at that moment.
 
 The Autoscaler runs a controller which monitors
-["KPA"](../../pkg/apis/autoscaling/v1alpha1/kpa_types.go) resources and monitors
+["KPA"](../../pkg/apis/autoscaling/v1alpha1/pa_types.go) resources and monitors
 and scales the embedded object reference via the `/scale` sub-resource.
 
 The Autoscaler provides a websocket-enabled Statistics Server. Queue proxies

docs/spec/normative_examples.md

@@ -594,8 +594,8 @@ simple development flows, the Service can also reference Revisions directly in
 been running, and the new revision the user would like test or canary a portion
 of traffic to, prior to rolling out entirely. This mode is also useful to roll
 back to a known-good previous revision. (Note: see
-[Appendix B](complex_examples.md) for a semi-automatic variation of managed
-rollouts).
+[example 3](#3-managed-release-of-a-new-revision---config-change-only)
+for a semi-automatic variation of managed rollouts).
 
 The client updates the service to switch to release mode.
 

pkg/apis/roadmap-2018.md

@@ -20,7 +20,7 @@ resource specification.
    Knative Serving API.
 1. **Schema**. [The Knative Serving API schema](../../docs/spec/spec.md) matches
    [our implementation.](./serving/).
-1. **Semantics**. The [semantics](../controller/) of Knative Serving API
+1. **Semantics**. The [semantics](../../cmd/controller/) of Knative Serving API
    interactions match
    [our specification](../../docs/spec/normative_examples.md), and are well
    covered by [conformance testing](../../test/conformance/README.md).

test/presubmit-tests.sh

@@ -21,9 +21,6 @@
 # Use the flags --build-tests, --unit-tests and --integration-tests
 # to run a specific set of tests.
 
-# See https://github.com/knative/test-infra/issues/451
-export DISABLE_MD_LINK_CHECK=1
-
 source $(dirname $0)/../vendor/github.com/knative/test-infra/scripts/presubmit-tests.sh
 
 # We use the default build, unit and integration test runners.

test/test_images/environment/README.md

@@ -6,13 +6,13 @@ Knative [run-time contract](/docs/runtime-contract.md)
 
 The image contains a simple Go webserver, `environment.go`, which by default,
 listens on port defined in the constant
-[EnvImageServerPort](/test/conformance/constants.go).
+[EnvImageServerPort](/test/image_constants.go).
 
 Currently the server exposes:
 
 - /envvars : To provide a JSON payload containing all the environment variables
   set inside the container
-- /filepath?path=<path-to-file>: Provides FileInfo for the <path-to-file>
+- /filepath?path=_path-to-file_: Provides FileInfo for the _path-to-file_
   query-param. The JSON payload returned as response is specified in
   [runtime_contract_types](../../conformance/runtime_contract_types.go)