fix v3.5 links (etcd-io#457)

content/en/docs/v3.5/benchmarks/etcd-2-2-0-rc-benchmarks.md

@@ -73,6 +73,6 @@ Bootstrap another machine and use the [hey HTTP benchmark tool][hey] to send req
 - write QPS to all servers is increased by 30~80% because follower could receive latest commit index earlier and commit proposals faster.
 
 [c7146bd5]: https://github.com/etcd-io/etcd/commits/c7146bd5f2c73716091262edc638401bb8229144
-[etcd-2.1-benchmark]: etcd-2-1-0-alpha-benchmarks
+[etcd-2.1-benchmark]: ../etcd-2-1-0-alpha-benchmarks/
 [hack-benchmark]: https://github.com/etcd-io/etcd/tree/v2.3.8/hack/benchmark
 [hey]: https://github.com/rakyll/hey

content/en/docs/v3.5/branch_management.md

@@ -19,13 +19,13 @@ The `main` branch is our development branch. All new features land here first.
 
 To try new and experimental features, pull `main` and play with it. Note that `main` 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#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 ([semver.org](https://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.
+After every minor release ([semver.org](https://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.
 
 [main]: https://github.com/etcd-io/etcd/tree/main
 

content/en/docs/v3.5/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
+[api-ref]: ../api_reference_v3/
 [etcdctl]: https://github.com/etcd-io/etcd/tree/master/etcdctl
 [go-client]: https://github.com/etcd-io/etcd/tree/master/client/v3
 [grpc]: https://www.grpc.io/

content/en/docs/v3.5/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].
 
-[clustering]: ../op-guide/clustering
-[interacting]: ./interacting_v3
+[clustering]: ../../op-guide/clustering/
+[interacting]: ../interacting_v3/

content/en/docs/v3.5/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.
 
 
-[api-mvcc]: learning/api#revisions
-[backend_commit_metrics]: metrics#disk
-[backup]: op-guide/recovery#snapshotting-the-keyspace
+[api-mvcc]: ../learning/api/#revisions
+[backend_commit_metrics]: ../metrics/#disk
+[backup]: ../op-guide/recovery/#snapshotting-the-keyspace
 [benchmark]: https://github.com/etcd-io/etcd/tree/master/tools/benchmark
-[benchmark-result]: op-guide/performance
+[benchmark-result]: ../op-guide/performance/
 [chubby]: http://static.googleusercontent.com/media/research.google.com/en//archive/chubby-osdi06.pdf
 [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
-[hardware-setup]: op-guide/hardware
-[maintenance-compact]:  op-guide/maintenance#history-compaction-v3-api-key-value-database
-[maintenance-defragment]: op-guide/maintenance#defragmentation
+[hardware-setup]: ../op-guide/hardware/
+[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
 [new_issue]: https://github.com/etcd-io/etcd/issues/new
 [raft]: https://raft.github.io/raft.pdf
-[runtime reconfiguration]: op-guide/runtime-configuration
-[supported-platform]: op-guide/supported-platform
-[tuning]: tuning
-[wal_fsync_duration_seconds]: metrics#disk
+[runtime reconfiguration]: ../op-guide/runtime-configuration/
+[supported-platform]: ../op-guide/supported-platform/
+[tuning]: ../tuning/
+[wal_fsync_duration_seconds]: ../metrics/#disk

content/en/docs/v3.5/learning/api.md

@@ -477,7 +477,7 @@ message LeaseKeepAliveResponse {
 * TTL - the new time-to-live, in seconds, that the lease has remaining.
 
 [elections]: https://github.com/etcd-io/etcd/blob/master/client/v3/concurrency/election.go
-[grpc-api]: ../dev-guide/api_reference_v3
+[grpc-api]: ../../dev-guide/api_reference_v3/
 [grpc-service]: https://github.com/etcd-io/etcd/blob/master/api/etcdserverpb/rpc.proto
 [kv-proto]: https://github.com/etcd-io/etcd/blob/master/api/mvccpb/kv.proto
 [locks]: https://github.com/etcd-io/etcd/blob/master/client/v3/concurrency/mutex.go

content/en/docs/v3.5/learning/api_guarantees.md

@@ -64,5 +64,5 @@ etcd provides [a lease mechanism][lease]. The primary use case of a lease is imp
 [linearizability]: https://cs.brown.edu/~mph/HerlihyW90/p463-herlihy.pdf
 [serializable_isolation]: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable
 [strict_serializability]: http://jepsen.io/consistency/models/strict-serializable
-[txn]: api#transaction
-[why]: why#notes-on-the-usage-of-lock-and-lease
+[txn]: ../api/#transaction
+[why]: ../why/#notes-on-the-usage-of-lock-and-lease

content/en/docs/v3.5/learning/why.md

@@ -111,19 +111,19 @@ Note that in the case of etcd keys, it can be locked efficiently because of the
 [container-linux]: https://coreos.com/why
 [curator]: http://curator.apache.org/
 [dbtester-comparison-results]: https://github.com/coreos/dbtester/tree/master/test-results/2018Q1-02-etcd-zookeeper-consul
-[etcd-commonname]: ../op-guide/authentication#using-tls-common-name
+[etcd-commonname]: ../../op-guide/authentication/#using-tls-common-name
 [etcd-etcdctl-elect]: https://github.com/etcd-io/etcd/blob/master/etcdctl/README.md#elect-options-election-name-proposal
 [etcd-etcdctl-lock]: https://github.com/etcd-io/etcd/blob/master/etcdctl/README.md#lock-options-lockname-command-arg1-arg2-
-[etcd-json]: ../dev-guide/api_grpc_gateway
-[etcd-linread]: api_guarantees#isolation-level-and-consistency-of-replicas
-[etcd-mvcc]: data_model
-[etcd-rbac]: ../op-guide/authentication#working-with-roles
+[etcd-json]: ../../dev-guide/api_grpc_gateway/
+[etcd-linread]: ../api_guarantees/#isolation-level-and-consistency-of-replicas
+[etcd-mvcc]: ../data_model/
+[etcd-rbac]: ../../op-guide/authentication/#working-with-roles
 [etcd-recipe]: https://godoc.org/github.com/etcd-io/etcd/client/v3/experimental/recipes
-[etcd-reconfig]: ../op-guide/runtime-configuration
-[etcd-txn]: api#transaction
+[etcd-reconfig]: ../../op-guide/runtime-configuration
+[etcd-txn]: ../api/#transaction
 [etcd-v3election]: https://godoc.org/github.com/etcd-io/etcd/server/etcdserver/api/v3election/v3electionpb
 [etcd-v3lock]: https://godoc.org/github.com/etcd-io/etcd/server/etcdserver/api/v3lock/v3lockpb
-[etcd-watch]: api#watch-streams
+[etcd-watch]: ../api/#watch-streams
 [etcdlease]: https://godoc.org/github.com/etcd-io/etcd/client/v3/leasing
 [fencing]: https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
 [fencing-zk]: https://fpj.me/2016/02/10/note-on-fencing-and-distributed-locks/

content/en/docs/v3.5/op-guide/clustering.md

@@ -487,14 +487,14 @@ 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].
 
 [clustering_etcd2]: https://github.com/etcd-io/etcd/blob/release-2.3/Documentation/clustering.md
-[conf-adv-client]: configuration#--advertise-client-urls
-[conf-listen-client]: configuration#--listen-client-urls
-[discovery-proto]: ../dev-internal/discovery_protocol
-[gateway]: gateway
+[conf-adv-client]: ../configuration/#--advertise-client-urls
+[conf-listen-client]: ../configuration/#--listen-client-urls
+[discovery-proto]: ../../dev-internal/discovery_protocol/
+[gateway]: ../gateway/
 [proxy]: https://github.com/etcd-io/etcd/blob/release-2.3/Documentation/proxy.md
 [rfc-srv]: http://www.ietf.org/rfc/rfc2052.txt
-[runtime-conf]: runtime-configuration
-[runtime-reconf-design]: runtime-reconf-design
-[security-guide-dns-srv]: security#notes-for-dns-srv
-[security-guide]: security
+[runtime-conf]: ../runtime-configuration/
+[runtime-reconf-design]: ../runtime-reconf-design/
+[security-guide-dns-srv]: ../security/#notes-for-dns-srv
+[security-guide]: ../security/
 [tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup

content/en/docs/v3.5/op-guide/configuration.md

@@ -465,15 +465,15 @@ a private certificate authority using `--peer-cert-file`, `--peer-key-file`, `--
 + default: false
 + env variable: ETCD_EXPERIMENTAL_PEER_SKIP_CLIENT_SAN_VERIFICATION
 
-[build-cluster]: clustering#static
-[discovery]: clustering#discovery
+[build-cluster]: ../clustering/#static
+[discovery]: ../clustering/#discovery
 [iana-ports]: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
-[proxy]: /docs/v2.3/proxy
-[reconfig]: runtime-configuration
-[recovery]: ../recovery
-[restore]: /docs/v2/admin_guide#restoring-a-backup
+[proxy]: /docs/v2.3/proxy/
+[reconfig]: ../runtime-configuration/
+[recovery]: ../recovery/
+[restore]: /docs/v2/admin_guide/#restoring-a-backup
 [sample-config-file]: https://github.com/etcd-io/etcd/blob/master/etcd.conf.yml.sample
-[security]: ../security
-[static bootstrap]: clustering#static
+[security]: ../security/
+[static bootstrap]: ../clustering/#static
 [systemd-intro]: http://freedesktop.org/wiki/Software/systemd/
-[tuning]: ../tuning#time-parameters
+[tuning]: ../../tuning/#time-parameters

content/en/docs/v3.5/op-guide/container.md

@@ -4,7 +4,7 @@ weight: 4200
 description: Running etcd with rkt and Docker using static bootstrapping
 ---
 
-The following guide shows how to run etcd with rkt and Docker using the [static bootstrap process](clustering#static).
+The following guide shows how to run etcd with rkt and Docker using the [static bootstrap process](../clustering/#static).
 
 ## rkt
 

content/en/docs/v3.5/op-guide/failures.md

@@ -44,5 +44,5 @@ A cluster bootstrap is only successful if all required members successfully star
 
 Of course, it is possible to recover a failed bootstrapped cluster like recovering a running cluster. However, it almost always takes more time and resources to recover that cluster than bootstrapping a new one, since there is no data to recover.
 
-[backup]: maintenance#snapshot-backup
-[unrecoverable]: recovery
+[backup]: ../maintenance/#snapshot-backup
+[unrecoverable]: ../recovery/

content/en/docs/v3.5/op-guide/grpc_proxy.md

@@ -103,7 +103,7 @@ bar
 
 ## Client endpoint synchronization and name resolution
 
-The proxy supports registering its endpoints for discovery by writing to a user-defined endpoint. This serves two purposes. First, it allows clients to synchronize their endpoints against a set of proxy endpoints for high availability. Second, it is an endpoint provider for etcd [gRPC naming](../dev-guide/grpc_naming.md).
+The proxy supports registering its endpoints for discovery by writing to a user-defined endpoint. This serves two purposes. First, it allows clients to synchronize their endpoints against a set of proxy endpoints for high availability. Second, it is an endpoint provider for etcd [gRPC naming](../../dev-guide/grpc_naming/).
 
 Register proxy(s) by providing a user-defined prefix:
 

content/en/docs/v3.5/op-guide/hardware.md

@@ -94,4 +94,4 @@ Example application workload: A 3,000 node Kubernetes cluster
 [diskbench]: https://github.com/ongardie/diskbenchmark
 [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
-[tuning]: ../tuning.md
+[tuning]: ../../tuning/

content/en/docs/v3.5/op-guide/runtime-configuration.md

@@ -38,7 +38,7 @@ If the majority of the cluster is lost or all of the nodes have changed IP addre
 
 ### Recover cluster from minority failure
 
-If a specific member is lost, then it is equivalent to replacing a failed machine. The steps are mentioned in [Replace a failed machine](runtime-configuration#replace-a-failed-machine).
+If a specific member is lost, then it is equivalent to replacing a failed machine. The steps are mentioned in [Replace a failed machine](../runtime-configuration/#replace-a-failed-machine).
 
 ## Cluster reconfiguration operations
 
@@ -238,15 +238,15 @@ It is enabled by default.
 
 [add member]: #add-a-new-member
 [cluster-reconf]: #cluster-reconfiguration-operations
-[conf-adv-peer]: configuration#clustering-flags
-[conf-name]: configuration#member-flags
-[design-learner]: ../learning/design-learner
-[disaster recovery]: recovery
+[conf-adv-peer]: ../configuration#clustering-flags
+[conf-name]: ../configuration#member-flags
+[design-learner]: ../../learning/design-learner
+[disaster recovery]: ../recovery
 [error cases when promoting a member]: #error-cases-when-promoting-a-learner-member
-[fault tolerance table]: /docs/v2.3/admin_guide#fault-tolerance-table
+[fault tolerance table]: /docs/v2.3/admin_guide/#fault-tolerance-table
 [majority failure]: #restart-cluster-from-majority-failure
-[member migration]: /docs/v2.3/admin_guide#member-migration
-[member-api]: /docs/v2.3/members_api
-[member-api-grpc]: ../dev-guide/api_reference_v3
+[member migration]: /docs/v2.3/admin_guide/#member-migration
+[member-api]: /docs/v2.3/members_api/
+[member-api-grpc]: ../../dev-guide/api_reference_v3/
 [remove member]: #remove-a-member
-[runtime-reconf]: runtime-reconf-design
+[runtime-reconf]: ../runtime-reconf-design/

content/en/docs/v3.5/op-guide/runtime-reconf-design.md

@@ -50,5 +50,5 @@ It seems that using public discovery service is a convenient way to do runtime r
 
 To have a discovery service that supports runtime reconfiguration, the best choice is to build a private one.
 
-[add-member]: runtime-configuration#add-a-new-member
-[disaster-recovery]: recovery
+[add-member]: ../runtime-configuration/#add-a-new-member
+[disaster-recovery]: ../recovery/

content/en/docs/v3.5/op-guide/security.md

@@ -438,7 +438,7 @@ No. etcd doesn't encrypt key/value data stored on disk drives. If a user need to
 When etcd create certain new directories it sets file permission to 700 to prevent unprivileged access as possible. However, if user has already created a directory with own preference, etcd uses the existing directory and logs a warning message if the permission is different than 700.
 
 [alt-name]: http://wiki.cacert.org/FAQ/subjectAltName
-[auth]: authentication
+[auth]: ../authentication/
 [cfssl]: https://github.com/cloudflare/cfssl
 [dm-crypt]: https://en.wikipedia.org/wiki/Dm-crypt
 [tls-guide]: https://github.com/coreos/docs/blob/master/os/generate-self-signed-certificates.md

content/en/docs/v3.5/platforms/aws.md

@@ -10,12 +10,12 @@ This guide assumes operational knowledge of Amazon Web Services (AWS), specifica
 
 As a critical building block for distributed systems it is crucial to perform adequate capacity planning in order to support the intended cluster workload. As a highly available and strongly consistent data store increasing the number of nodes in an etcd cluster will generally affect performance adversely. This makes sense intuitively, as more nodes means more members for the leader to coordinate state across. The most direct way to increase throughput and decrease latency of an etcd cluster is allocate more disk I/O, network I/O, CPU, and memory to cluster members. In the event it is impossible to temporarily divert incoming requests to the cluster, scaling the EC2 instances which comprise the etcd cluster members one at a time may improve performance. It is, however, best to avoid bottlenecks through capacity planning.
 
-The etcd team has produced a [hardware recommendation guide](../op-guide/hardware.md) which is very useful for “ballparking” how many nodes and what instance type are necessary for a cluster.
+The etcd team has produced a [hardware recommendation guide](../../op-guide/hardware/) which is very useful for “ballparking” how many nodes and what instance type are necessary for a cluster.
 
 AWS provides a service for creating groups of EC2 instances which are dynamically sized to match load on the instances. Using an Auto Scaling Group ([ASG](http://docs.aws.amazon.com/autoscaling/latest/userguide/AutoScalingGroup.html)) to dynamically scale an etcd cluster is not recommended for several reasons including:
 
 * etcd performance is generally inversely proportional to the number of members in a cluster due to the synchronous replication which provides strong consistency of data stored in etcd
-* the operational complexity of adding [lifecycle hooks](http://docs.aws.amazon.com/autoscaling/latest/userguide/lifecycle-hooks.html) to properly add and remove members from an etcd cluster by modifying the [runtime configuration](../op-guide/runtime-configuration.md)
+* the operational complexity of adding [lifecycle hooks](http://docs.aws.amazon.com/autoscaling/latest/userguide/lifecycle-hooks.html) to properly add and remove members from an etcd cluster by modifying the [runtime configuration](../../op-guide/runtime-configuration/)
 
 Auto Scaling Groups do provide a number of benefits besides cluster scaling which include:
 
@@ -60,7 +60,7 @@ A highly available etcd cluster is resilient to member loss, however, it is impo
 
 ### Performance/Throughput
 
-The performance of an etcd cluster is roughly quantifiable through latency and throughput metrics which are primarily affected by disk and network performance. Detailed performance planning information is provided in the [performance section](../op-guide/performance.md) of the etcd operations guide.
+The performance of an etcd cluster is roughly quantifiable through latency and throughput metrics which are primarily affected by disk and network performance. Detailed performance planning information is provided in the [performance section](../../op-guide/performance/) of the etcd operations guide.
 
 #### Network