Updating all internal links. (etcd-io#174)

Signed-off-by: Nate W <[email protected]>

.htmltest.external.yml

@@ -1,3 +1,6 @@
 DirectoryPath: public
 IgnoreDirectoryMissingTrailingSlash: true
 IgnoreAltMissing: true
+IgnoreEmptyHref: true
+IgnoreURLs:
+- example.com

.htmltest.yml

@@ -1,4 +1,5 @@
 DirectoryPath: public
 IgnoreDirectoryMissingTrailingSlash: true
-CheckExternal: false
 IgnoreAltMissing: true
+IgnoreEmptyHref: true
+CheckExternal: false

Makefile

@@ -16,8 +16,11 @@ run-link-checker:
 
 check-links: production-build link-checker-setup run-link-checker
 
+ci-check-links: link-checker-setup run-link-checker
+
 # Adding additional link checks based on https://github.com/grpc/grpc.io/blob/main/Makefile
 check-internal-links: production-build link-checker-setup run-link-checker
+	bin/htmltest --conf .htmltest.yml
 
 check-all-links: production-build link-checker-setup
 	bin/htmltest --conf .htmltest.external.yml

config.toml

@@ -26,7 +26,7 @@ Applications of any complexity, from a simple web app to [Kubernetes](https://ku
 
 Your applications can read from and write data into etcd. A simple use case is storing database connection details or feature flags in etcd as key-value pairs. These values can be watched, allowing your app to reconfigure itself when they change. Advanced uses take advantage of etcd's consistency guarantees to implement database leader elections or perform distributed locking across a cluster of workers.
 
-etcd is open source, available [on GitHub](https://github.com/etcd-io/etcd), and backed by the [Cloud Native Computing Foundation](https://cncf.io).
+etcd is open source, available [on GitHub](https://github.com/etcd-io/etcd), and backed by the [Cloud Native Computing Foundation](https://www.cncf.io).
 """
 
 overview           = """
@@ -122,7 +122,7 @@ link = "https://eng.uber.com/m3/"
 description = "M3, a large-scale metrics platform for Prometheus created by Uber, uses etcd for rule storage and other functions"
 
 [[params.adopters]]
-link = "https://openstack.org"
+link = "https://www.openstack.org/"
 logo = "/img/openstack-logo.svg"
 description = "OpenStack supports etcd as an optional provider of configuration storage, distributed key locking, and more"
 

content/blog/jepsen-343-results.md

@@ -11,7 +11,7 @@ Jepsen tested and analyzed etcd 3.4.3, and had both good results and useful feed
 
 A key part of etcd's design is strong consistency guarantees across the distributed key-value store. Kubernetes, Rook, OpenStack, and countless other critical software projects rely on etcd, in part, because of the etcd project's focus on reliability and correctness.
 
-Over the years, the etcd team has put tremendous effort on building [testing](https://coreos.com/blog/testing-distributed-systems-in-go.html) and [chaos engineering frameworks](https://coreos.com/blog/new-functional-testing-in-etcd.html).  We feel that we've improved our consistency, and have asked Jepsen for validation.
+Over the years, the etcd team has put tremendous effort on building [testing](https://web.archive.org/web/20200811103145/https://coreos.com/blog/testing-distributed-systems-in-go.html) and [chaos engineering frameworks](https://web.archive.org/web/20200420035739/https://coreos.com/blog/new-functional-testing-in-etcd.html).  We feel that we've improved our consistency, and have asked Jepsen for validation.
 
 [Jepsen](https://jepsen.io/) is the leading company testing open source distributed systems to check if they fulfill their consistency guarantees. They first tested etcd in version 0.4.1, and we have been using these findings ever since to improve our consistency. In this blog post, we share the overall positive results of the Jepsen analysis of etcd v3.4.3 as well as our plans to resolve the issues found in the analysis.
 
@@ -53,7 +53,7 @@ The Jepsen analysis not only covers software correctness but also verifies the d
 
 Our documentation describes the consistency model based on [the Wikipedia definition](https://en.wikipedia.org/wiki/Consistency_model), which is also the classification some etcd engineers [learned in University](http://www.cs.cmu.edu/~srini/15-446/S09/lectures/10-consistency.pdf). It also separates the isolation level from consistency level, as there is no general agreement on [how the two should be defined together](https://fauna.com/blog/demystifying-database-systems-part-4-isolation-levels-vs-consistency-levels).
 
-The Jepsen author suggests etcd documentation adopt the term "strict serializability" originally defined in the [Linearizability paper published by Herlihy and Wing](https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf). After reading the documentation on other open source projects, as well as listening to feedback from our users, the etcd team agrees with the Jepsen author that the [suggested model and term](https://jepsen.io/consistency) are clearer and easier to understand.
+The Jepsen author suggests etcd documentation adopt the term "strict serializability" originally defined in the [Linearizability paper published by Herlihy and Wing](https://web.archive.org/web/20201203054309/https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf). After reading the documentation on other open source projects, as well as listening to feedback from our users, the etcd team agrees with the Jepsen author that the [suggested model and term](https://jepsen.io/consistency) are clearer and easier to understand.
 
 Next, the lock API use case example is misleading and might cause runtime issues.
 

content/docs/next/benchmarks/_index.md

@@ -18,7 +18,7 @@ It records expected memory usage in different scenarios.
 
 - [etcd v2.2.0-rc][2.2-mem]
 
-[2.1]: etcd-2-1-0-alpha-benchmarks.md
-[2.2]: etcd-2-2-0-rc-benchmarks.md
-[2.2-mem]: etcd-2-2-0-rc-memory-benchmarks.md
-[3.0]: etcd-3-demo-benchmarks.md
+[2.1]: etcd-2-1-0-alpha-benchmarks
+[2.2]: etcd-2-2-0-rc-benchmarks
+[2.2-mem]: etcd-2-2-0-rc-memory-benchmarks
+[3.0]: etcd-3-demo-benchmarks

content/docs/next/benchmarks/etcd-2-2-0-benchmarks.md

@@ -28,7 +28,7 @@ Go OS/Arch: linux/amd64
 
 ## Testing
 
-Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](https://github.com/etcd-io/etcd/tree/master/hack/benchmark) for the patch and the steps to reproduce our procedures.
+Bootstrap another machine, outside of the etcd cluster, and run the [`hey` HTTP benchmark tool](https://github.com/rakyll/hey) with a connection reuse patch to send requests to each etcd cluster member. See the [benchmark instructions](https://github.com/etcd-io/etcd/tree/v2.3.8/hack/benchmark) for the patch and the steps to reproduce our procedures.
 
 The performance is calculated through results of 100 benchmark rounds.
 

content/docs/next/benchmarks/etcd-2-2-0-rc-benchmarks.md

@@ -74,5 +74,5 @@ Bootstrap another machine and use the [hey HTTP benchmark tool][hey] to send req
 
 [hey]: https://github.com/rakyll/hey
 [c7146bd5]: https://github.com/coreos/etcd/commits/c7146bd5f2c73716091262edc638401bb8229144
-[etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks.md
-[hack-benchmark]: https://github.com/etcd-io/etcd/tree/master/hack/benchmark
+[etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks
+[hack-benchmark]: https://github.com/etcd-io/etcd/tree/v2.3.8/hack/benchmark

content/docs/next/branch_management.md

@@ -19,13 +19,13 @@ The `master` branch is our development branch. All new features land here first.
 
 To try new and experimental features, pull `master` and play with it. Note that `master` may not be stable because new features may introduce bugs.
 
-Before the release of the next stable version, feature PRs will be frozen. A [release manager](./dev-internal/release.md#release-management) will be assigned to major/minor version and will lead the etcd community in test, bug-fix and documentation of the release for one to two weeks.
+Before the release of the next stable version, feature PRs will be frozen. A [release manager](./dev-internal/release#release-management) will be assigned to major/minor version and will lead the etcd community in test, bug-fix and documentation of the release for one to two weeks.
 
 ### Stable branches
 
 All branches with prefix `release-` are considered _stable_ branches.
 
-After every minor release (http://semver.org/), we will have a new stable branch for that release, managed by a [patch release manager](./dev-internal/release.md#release-management). We will keep fixing the backwards-compatible bugs for the latest two stable releases. A _patch_ release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.
+After every minor release (http://semver.org/), we will have a new stable branch for that release, managed by a [patch release manager](./dev-internal/release#release-management). We will keep fixing the backwards-compatible bugs for the latest two stable releases. A _patch_ release to each supported release branch, incorporating any bug fixes, will be once every two weeks, given any patches.
 
 [master]: https://github.com/etcd-io/etcd/tree/master
 

content/docs/next/dev-guide/api_grpc_gateway.md

@@ -129,7 +129,7 @@ curl -L http://localhost:2379/v3/kv/put \
 
 Generated [Swagger][swagger] API definitions can be found at [rpc.swagger.json][swagger-doc].
 
-[api-ref]: ./api_reference_v3.md
+[api-ref]: ./api_reference_v3
 [go-client]: https://github.com/etcd-io/etcd/tree/master/client/v3
 [etcdctl]: https://github.com/coreos/etcd/tree/master/etcdctl
 [grpc]: https://www.grpc.io/

content/docs/next/dev-guide/local_cluster.md

@@ -149,5 +149,5 @@ To exercise etcd's fault tolerance, kill a member and attempt to retrieve the ke
 
     Restarting the member re-establish the connection. `etcdctl` will now be able to retrieve the key successfully. To learn more about interacting with etcd, read [interacting with etcd section][interacting].
 
-[interacting]: ./interacting_v3.md
-[clustering]: ../op-guide/clustering.md
+[interacting]: ./interacting_v3
+[clustering]: ../op-guide/clustering

content/docs/next/dev-internal/discovery_protocol.md

@@ -111,7 +111,7 @@ The status for this discovery token, including the machines that have been regis
 
 The repository is located at https://github.com/coreos/discovery.etcd.io. It could be used to build a custom discovery service.
 
-[api]: /docs/v2/api#waiting-for-a-change
-[cluster-size]: /docs/v2/admin_guide#optimal-cluster-size
+[api]: /docs/v2.3/api#waiting-for-a-change
+[cluster-size]: /docs/v2.3/admin_guide#optimal-cluster-size
 [expected-cluster-size]: #specifying-the-expected-cluster-size
 [new-discovery-token]: #creating-a-new-discovery-token

content/docs/next/dl-build.md

@@ -66,4 +66,4 @@ If OK is printed, then etcd is working!
 
 [github-release]: https://github.com/etcd-io/etcd/releases/
 [go]: https://golang.org/doc/install
-[example-hardware-configurations]: op-guide/hardware.md#example-hardware-configurations
+[example-hardware-configurations]: op-guide/hardware#example-hardware-configurations

content/docs/next/faq.md

@@ -155,21 +155,21 @@ If none of the above suggestions clear the warnings, please [open an issue][new_
 etcd sends a snapshot of its complete key-value store to refresh slow followers and for [backups][backup]. Slow snapshot transfer times increase MTTR; if the cluster is ingesting data with high throughput, slow followers may livelock by needing a new snapshot before finishing receiving a snapshot. To catch slow snapshot performance, etcd warns when sending a snapshot takes more than thirty seconds and exceeds the expected transfer time for a 1Gbps connection.
 
 
-[hardware-setup]: op-guide/hardware.md
-[supported-platform]: op-guide/supported-platform.md
+[hardware-setup]: op-guide/hardware
+[supported-platform]: op-guide/supported-platform
 [wal_fsync_duration_seconds]: metrics#disk
-[tuning]: tuning.md
+[tuning]: tuning
 [new_issue]: https://github.com/etcd-io/etcd/issues/new
-[backend_commit_metrics]: metrics.md#disk
+[backend_commit_metrics]: metrics#disk
 [raft]: https://raft.github.io/raft.pdf
-[backup]: op-guide/recovery.md#snapshotting-the-keyspace
+[backup]: op-guide/recovery#snapshotting-the-keyspace
 [chubby]: http://static.googleusercontent.com/media/research.google.com/en//archive/chubby-osdi06.pdf
 [runtime reconfiguration]: op-guide/runtime-configuration
 [benchmark]: https://github.com/coreos/etcd/tree/master/tools/benchmark
 [benchmark-result]: op-guide/performance
-[api-mvcc]: learning/api.md#revisions
-[maintenance-compact]:  op-guide/maintenance.md#history-compaction-v3-api-key-value-database
-[maintenance-defragment]: op-guide/maintenance.md#defragmentation
+[api-mvcc]: learning/api#revisions
+[maintenance-compact]:  op-guide/maintenance#history-compaction-v3-api-key-value-database
+[maintenance-defragment]: op-guide/maintenance#defragmentation
 [maintenance-disarm]: https://github.com/etcd-io/etcd/blob/master/etcdctl/README.md#alarm-disarm
 [fio]: https://github.com/axboe/fio
 [fio-blog-post]: https://www.ibm.com/cloud/blog/using-fio-to-tell-whether-your-storage-is-fast-enough-for-etcd

content/docs/next/learning/api.md

@@ -478,7 +478,7 @@ message LeaseKeepAliveResponse {
 
 [elections]: https://github.com/etcd-io/etcd/blob/master/client/v3/concurrency/election.go
 [kv-proto]: https://github.com/etcd-io/etcd/blob/master/api/mvccpb/kv.proto
-[grpc-api]: ../dev-guide/api_reference_v3.md
+[grpc-api]: ../dev-guide/api_reference_v3
 [grpc-service]: https://github.com/etcd-io/etcd/blob/master/api/etcdserverpb/rpc.proto
 [locks]: https://github.com/etcd-io/etcd/blob/master/client/v3/concurrency/mutex.go
 [mvcc]: https://en.wikipedia.org/wiki/Multiversion_concurrency_control

content/docs/next/learning/api_guarantees.md

@@ -60,10 +60,10 @@ etcd ensures linearizability for all other operations by default. Linearizabilit
 
 etcd provides [a lease mechanism][lease]. The primary use case of a lease is implementing distributed coordination mechanisms like distributed locks. The lease mechanism itself is simple: a lease can be created with the grant API, attached to a key with the put API, revoked with the revoke API, and will be expired by the wall clock time to live (TTL). However, users need to be aware about [the important properties of the APIs and usage][why] for implementing correct distributed coordination mechanisms.
 
-[txn]: api.md#transaction
+[txn]: api#transaction
 [linearizability]: https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf
 [strict_serializability]: http://jepsen.io/consistency/models/strict-serializable
 [serializable_isolation]: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable
 [Linearizability]: #Linearizability
 [lease]: https://web.stanford.edu/class/cs240/readings/89-leases.pdf
-[why]: why.md#notes-on-the-usage-of-lock-and-lease
+[why]: why#notes-on-the-usage-of-lock-and-lease

content/docs/next/learning/lock/README.md

@@ -55,7 +55,7 @@ failed to write to storage: error: given version (4703569812595502721) differ fr
 ### Notes on the parameters related to stop the world GC pause
 `client` program includes two constant values: `nrGarbageObjects` and `sessionTTL`. These parameters are configured for causing lease expiration with stop the world GC pause of go runtime. They heavily rely on resources of a machine for executing the example. If lease expiration doesn't happen on your machine, update these parameters and try again.
 
-[why.md]: ../why.md#Notes-on-the-usage-of-lock-and-lease
+[why.md]: ../why#notes-on-the-usage-of-lock-and-lease
 [fencing]: https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
 [unsafe-lock]: https://martin.kleppmann.com/2016/02/unsafe-lock.png
 [fencing-tokens]: https://martin.kleppmann.com/2016/02/fencing-tokens.png

content/docs/next/learning/why.md

@@ -108,25 +108,25 @@ Note that in the case of etcd keys, it can be locked efficiently because of the
 [etcd-v3election]: https://godoc.org/github.com/etcd-io/etcd/server/etcdserver/api/v3election/v3electionpb
 [etcd-etcdctl-lock]: https://github.com/etcd-io/etcd/blob/master/etcdctl/README.md#lock-options-lockname-command-arg1-arg2-
 [etcd-etcdctl-elect]: https://github.com/etcd-io/etcd/blob/master/etcdctl/README.md#elect-options-election-name-proposal
-[etcd-mvcc]: data_model.md
+[etcd-mvcc]: data_model
 [etcd-recipe]: https://godoc.org/github.com/etcd-io/etcd/client/v3/experimental/recipes
 [consul-lock]: https://www.consul.io/commands/lock
 [newsql-leader]: http://dl.acm.org/citation.cfm?id=2960999
-[etcd-reconfig]: ../op-guide/runtime-configuration.md
+[etcd-reconfig]: ../op-guide/runtime-configuration
 [zk-reconfig]: https://zookeeper.apache.org/doc/current/zookeeperReconfig.html
 [consul-reconfig]: https://www.consul.io/docs/guides/servers.html
-[etcd-linread]: api_guarantees.md#isolation-level-and-consistency-of-replicas
+[etcd-linread]: api_guarantees#isolation-level-and-consistency-of-replicas
 [consul-linread]: https://www.consul.io/docs/agent/http.html#consistency
-[etcd-json]: ../dev-guide/api_grpc_gateway.md
+[etcd-json]: ../dev-guide/api_grpc_gateway
 [consul-json]: https://www.consul.io/docs/agent/http.html#formatted-json-output
-[etcd-txn]: api.md#transaction
+[etcd-txn]: api#transaction
 [zk-txn]: https://zookeeper.apache.org/doc/r3.4.3/api/org/apache/zookeeper/ZooKeeper.html#multi(java.lang.Iterable)
 [consul-txn]: https://www.consul.io/docs/agent/http/kv.html#txn
-[etcd-watch]: api.md#watch-streams
+[etcd-watch]: api#watch-streams
 [zk-watch]: https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkWatches
 [consul-watch]: https://www.consul.io/docs/agent/watches.html
-[etcd-commonname]: ../op-guide/authentication.md#using-tls-common-name
-[etcd-rbac]: ../op-guide/authentication.md#working-with-roles
+[etcd-commonname]: ../op-guide/authentication#using-tls-common-name
+[etcd-rbac]: ../op-guide/authentication#working-with-roles
 [zk-acl]: https://zookeeper.apache.org/doc/r3.1.2/zookeeperProgrammers.html#sc_ZooKeeperAccessControl
 [consul-acl]: https://www.consul.io/docs/internals/acl.html
 [cockroach-grant]: https://www.cockroachlabs.com/docs/stable/grant.html

content/docs/next/op-guide/clustering.md

@@ -486,15 +486,15 @@ When the `--proxy` flag is set, etcd runs in [proxy mode][proxy]. This proxy mod
 
 To setup an etcd cluster with proxies of v2 API, please read the the [clustering doc in etcd 2.3 release][clustering_etcd2].
 
-[conf-adv-client]: configuration.md#--advertise-client-urls
-[conf-listen-client]: configuration.md#--listen-client-urls
-[discovery-proto]: ../dev-internal/discovery_protocol.md
+[conf-adv-client]: configuration#--advertise-client-urls
+[conf-listen-client]: configuration#--listen-client-urls
+[discovery-proto]: ../dev-internal/discovery_protocol
 [rfc-srv]: http://www.ietf.org/rfc/rfc2052.txt
-[runtime-conf]: runtime-configuration.md
-[runtime-reconf-design]: runtime-reconf-design.md
+[runtime-conf]: runtime-configuration
+[runtime-reconf-design]: runtime-reconf-design
 [proxy]: https://github.com/coreos/etcd/blob/release-2.3/Documentation/proxy.md
 [clustering_etcd2]: https://github.com/coreos/etcd/blob/release-2.3/Documentation/clustering.md
-[security-guide]: security.md
-[security-guide-dns-srv]: security.md#notes-for-dns-srv
+[security-guide]: security
+[security-guide-dns-srv]: security#notes-for-dns-srv
 [tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup
-[gateway]: gateway.md
+[gateway]: gateway