fix links in 3.3

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

@@ -71,6 +71,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]: /docs/v3.3/benchmarks/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.3/benchmarks/etcd-3-demo-benchmarks.md

@@ -43,4 +43,4 @@ The performance is nearly the same as the one with empty server handler.
 The performance with empty server handler is not affected by one put. So the
 performance downgrade should be caused by storage package.
 
-[etcd-v3-benchmark]: ../op-guide/performance/#benchmarks
+[etcd-v3-benchmark]: /docs/v3.3/op-guide/performance/#benchmarks

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

@@ -17,12 +17,12 @@ 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#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.
 
 [master]: https://github.com/etcd-io/etcd/tree/master

content/en/docs/v3.3/dev-guide/api_grpc_gateway.md

@@ -127,7 +127,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]: /docs/v3.3/dev-guide/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.3/dev-guide/local_cluster.md

@@ -147,5 +147,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]: /docs/v3.3/op-guide/clustering
+[interacting]: /docs/v3.3/dev-guide/interacting_v3

content/en/docs/v3.3/faq.md

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

content/en/docs/v3.3/install.md

@@ -79,6 +79,6 @@ If OK is printed, then etcd is working!
 
 [build-script]: ../build
 [cmd-directory]: ../cmd
-[example-hardware-configurations]: op-guide/hardware#example-hardware-configurations
+[example-hardware-configurations]: ../op-guide/hardware#example-hardware-configurations
 [github-release]: https://github.com/etcd-io/etcd/releases/
 [go]: https://golang.org/doc/install

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

@@ -475,7 +475,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]: /docs/v3.3/dev-guide/api_reference_v3
 [grpc-service]: https://github.com/etcd-io/etcd/blob/{{< param git_version_tag >}}/etcdserver/etcdserverpb/rpc.proto
 [kv-proto]: https://github.com/etcd-io/etcd/blob/{{< param git_version_tag >}}/mvcc/mvccpb/kv.proto
 [locks]: https://github.com/etcd-io/etcd/blob/master/client/v3/concurrency/mutex.go

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

@@ -63,4 +63,4 @@ etcd ensures linearizability for all other operations by default. Linearizabilit
 [seq_consistency]: https://en.wikipedia.org/wiki/Consistency_model#Sequential_consistency
 [serializable_isolation]: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable
 [strict_consistency]: https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency
-[txn]: api#transaction
+[txn]: /docs/v3.3/learning/api#transaction

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

@@ -93,21 +93,21 @@ For distributed coordination, choosing etcd can help prevent operational headach
 [etcd-commonname]: ../op-guide/authentication#using-tls-common-name
 [etcd-etcdctl-elect]: https://github.com/etcd-io/etcd/tree/master/etcdctl/README.md#elect-options-election-name-proposal
 [etcd-etcdctl-lock]: https://github.com/etcd-io/etcd/tree/master/etcdctl/README.md#lock-lockname-command-arg1-arg2-
-[etcd-json]: ../dev-guide/api_grpc_gateway
-[etcd-linread]: api_guarantees#linearizability
-[etcd-mvcc]: data_model
-[etcd-rbac]: ../op-guide/authentication#working-with-roles
+[etcd-json]: /docs/v3.3/dev-guide/api_grpc_gateway
+[etcd-linread]: /docs/v3.3/learning/api_guarantees#linearizability
+[etcd-mvcc]: /docs/v3.3/learning/data_model
+[etcd-rbac]: /docs/v3.3/op-guide/authentication#working-with-roles
 [etcd-recipe]: https://godoc.org/github.com/etcd-io/etcd/contrib/recipes
-[etcd-reconfig]: ../op-guide/runtime-configuration
-[etcd-txn]: api#transaction
+[etcd-reconfig]: /docs/v3.3/op-guide/runtime-configuration
+[etcd-txn]: /docs/v3.3/learning/api#transaction
 [etcd-v3election]: https://godoc.org/github.com/coreos/etcd-io/etcdserver/api/v3election/v3electionpb
 [etcd-v3lock]: https://godoc.org/github.com/etcd-io/etcd/etcdserver/api/v3lock/v3lockpb
-[etcd-watch]: api#watch-streams
+[etcd-watch]: /docs/v3.3/learning/api#watch-streams
 [grpc]: https://www.grpc.io
 [kubernetes]: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
 [locksmith]: https://github.com/coreos/locksmith
 [newsql-leader]: http://dl.acm.org/citation.cfm?id=2960999
-[production-users]: ../production-users
+[production-users]: /docs/v3.3/production-users
 [spanner-roles]: https://cloud.google.com/spanner/docs/iam#roles
 [spanner]: https://cloud.google.com/spanner/
 [tidb]: https://github.com/pingcap/tidb

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

@@ -6,7 +6,7 @@ title: Clustering Guide
 
 Starting an etcd cluster statically requires that each member knows another in the cluster. In a number of cases, the IPs of the cluster members may be unknown ahead of time. In these cases, the etcd cluster can be bootstrapped with the help of a discovery service.
 
-Once an etcd cluster is up and running, adding or removing members is done via [runtime reconfiguration][runtime-conf]. To better understand the design behind runtime reconfiguration, we suggest reading [the runtime configuration design document][runtime-reconf-design].
+Once an etcd cluster is up and running, adding or removing members is done via [runtime reconfiguration][runtime-conf]. To better understand the design behind runtime reconfiguration, we suggest reading [the runtime configuration design document][../../runtime-reconf-design].
 
 This guide will cover the following mechanisms for bootstrapping an etcd cluster:
 
@@ -485,14 +485,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]: /docs/v3.3/op-guide/configuration#--advertise-client-urls
+[conf-listen-client]: /docs/v3.3/op-guide/configuration#--listen-client-urls
+[discovery-proto]: /docs/v3.3/dev-internal/discovery_protocol
+[gateway]: /docs/v3.3/op-guide/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]: /docs/v3.3/op-guide/runtime-configuration
+[runtime-reconf-design]: /docs/v3.3/op-guide/runtime-reconf-design
+[security-guide-dns-srv]: /docs/v3.3/op-guide/security#notes-for-dns-srv
+[security-guide]: /docs/v3.3/op-guide/security
 [tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup

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

@@ -418,15 +418,15 @@ Follow the instructions when using these flags.
 + default: 0s
 + env variable: ETCD_EXPERIMENTAL_CORRUPT_CHECK_TIME
 
-[build-cluster]: clustering#static
-[discovery]: clustering#discovery
+[build-cluster]: /docs/v3.3/op-guide/clustering#static
+[discovery]: /docs/v3.3/op-guide/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
+[reconfig]: /docs/v3.3/op-guide/runtime-configuration
 [recovery]: ../recovery
 [restore]: /docs/v2.3/admin_guide#restoring-a-backup
 [sample-config-file]: https://github.com/etcd-io/etcd/blob/release-3.4/etcd.conf.yml.sample
-[security]: security
-[static bootstrap]: clustering#static
+[security]: /docs/v3.3/op-guide/security
+[static bootstrap]: /docs/v3.3/op-guide/clustering#static
 [systemd-intro]: http://freedesktop.org/wiki/Software/systemd/
-[tuning]: ../tuning#time-parameters
+[tuning]: /docs/v3.3/tuning#time-parameters

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

@@ -2,7 +2,7 @@
 title: Run etcd clusters inside containers
 ---
 
-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](/docs/v3.3/op-guide/clustering#static).
 
 ## rkt
 

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

@@ -42,5 +42,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]: /docs/v3.3/op-guide/maintenance#snapshot-backup
+[unrecoverable]: /docs/v3.3/op-guide/recovery

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

@@ -101,7 +101,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](/docs/v3.3/dev-guide/grpc_naming).
 
 Register proxy(s) by providing a user-defined prefix:
 

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

@@ -91,4 +91,4 @@ Example application workload: A 3,000 node Kubernetes cluster
 
 [diskbench]: https://github.com/ongardie/diskbenchmark
 [fio]: https://github.com/axboe/fio
-[tuning]: ../tuning
+[tuning]: /docs/v3.3/tuning

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

@@ -6,7 +6,7 @@ etcd comes with support for incremental runtime reconfiguration, which allows us
 
 Reconfiguration requests can only be processed when a majority of cluster members are functioning. It is **highly recommended** to always have a cluster size greater than two in production. It is unsafe to remove a member from a two member cluster. The majority of a two member cluster is also two. If there is a failure during the removal process, the cluster might not be able to make progress and need to [restart from majority failure][majority failure].
 
-To better understand the design behind runtime reconfiguration, please read [the runtime reconfiguration document][runtime-reconf].
+To better understand the design behind runtime reconfiguration, please read [the runtime reconfiguration document][../../runtime-reconf].
 
 ## Reconfiguration use cases
 
@@ -163,13 +163,13 @@ It is enabled by default.
 
 [add member]: #add-a-new-member
 [cluster-reconf]: #cluster-reconfiguration-operations
-[conf-adv-peer]: configuration#--initial-advertise-peer-urls
-[conf-name]: configuration#--name
-[disaster recovery]: recovery
+[conf-adv-peer]: /docs/v3.3/op-guide/configuration#--initial-advertise-peer-urls
+[conf-name]: /docs/v3.3/op-guide/configuration#--name
+[disaster recovery]: /docs/v3.3/op-guide/recovery
 [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#service-cluster-etcdserveretcdserverpbrpcproto
+[member-api-grpc]: /docs/v3.3/dev-guide/api_reference_v3#service-cluster-etcdserveretcdserverpbrpcproto
 [remove member]: #remove-a-member
 [runtime-reconf]: runtime-reconf-design

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

@@ -48,5 +48,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]: /docs/v3.3/op-guide/runtime-configuration#add-a-new-member
+[disaster-recovery]: /docs/v3.3/op-guide/recovery

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

@@ -427,7 +427,7 @@ Make sure to sign the certificates with a Subject Name the member's public IP ad
 The certificate needs to be signed for the member's FQDN in its Subject Name, use Subject Alternative Names (short IP SANs) to add the IP address. The `etcd-ca` tool provides `--domain=` option for its `new-cert` command, and openssl can make [it][alt-name] too.
 
 [alt-name]: http://wiki.cacert.org/FAQ/subjectAltName
-[auth]: authentication
+[auth]: /docs/v3.3/op-guide/authentication
 [cfssl]: https://github.com/cloudflare/cfssl
 [tls-guide]: https://github.com/coreos/docs/blob/master/os/generate-self-signed-certificates.md
 [tls-setup]: https://github.com/etcd-io/etcd/tree/master/hack/tls-setup

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

@@ -8,12 +8,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:
 
@@ -58,7 +58,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