documentation: initial metadata additions for website generation (#10596)

Signed-off-by: lucperkins <lucperkins@gmail.com>

Documentation/benchmarks/etcd-2-1-0-alpha-benchmarks.md

@@ -1,3 +1,7 @@
+---
+title: Benchmarking etcd v2.1.0
+---
+
 ## Physical machines
 
 GCE n1-highcpu-2 machine type

Documentation/benchmarks/etcd-2-2-0-benchmarks.md

@@ -1,4 +1,6 @@
-# Benchmarking etcd v2.2.0
+---
+title: Benchmarking etcd v2.2.0
+---
 
 ## Physical Machines
 

Documentation/benchmarks/etcd-2-2-0-rc-benchmarks.md

@@ -1,4 +1,8 @@
-## Physical machines
+---
+title: Benchmarking etcd v2.2.0-rc
+---
+
+## Physical machine
 
 GCE n1-highcpu-2 machine type
 

Documentation/benchmarks/etcd-2-2-0-rc-memory-benchmarks.md

@@ -1,3 +1,7 @@
+---
+title: Benchmarking etcd v2.2.0-rc-memory
+---
+
 ## Physical machine
 
 GCE n1-standard-2 machine type

Documentation/benchmarks/etcd-3-demo-benchmarks.md

@@ -1,3 +1,7 @@
+---
+title: Benchmarking etcd v3
+---
+
 ## Physical machines
 
 GCE n1-highcpu-2 machine type

Documentation/benchmarks/etcd-3-watch-memory-benchmark.md

@@ -1,4 +1,6 @@
-# Watch Memory Usage Benchmark
+---
+title: Watch Memory Usage Benchmark
+---
 
 *NOTE*: The watch features are under active development, and their memory usage may change as that development progresses. We do not expect it to significantly increase beyond the figures stated below.
 

Documentation/benchmarks/etcd-storage-memory-benchmark.md

@@ -1,4 +1,6 @@
-# Storage Memory Usage Benchmark
+---
+title: Storage Memory Usage Benchmark
+---
 
 <!---todo: link storage to storage design doc-->
 Two components of etcd storage consume physical memory. The etcd process allocates an *in-memory index* to speed key lookup. The process's *page cache*, managed by the operating system, stores recently-accessed data from disk for quick re-use.

Documentation/branch_management.md

@@ -1,4 +1,6 @@
-# Branch management
+---
+title: Branch management
+---
 
 ## Guide
 

Documentation/demo.md

@@ -1,4 +1,6 @@
-# Demo
+---
+title: Demo
+---
 
 This series of examples shows the basic procedures for working with an etcd cluster.
 

Documentation/dev-guide/api_concurrency_reference_v3.md

@@ -1,4 +1,6 @@
-### etcd concurrency API Reference
+---
+title: etcd concurrency API Reference
+---
 
 
 This is a generated documentation. Please read the proto files for more.

Documentation/dev-guide/api_grpc_gateway.md

@@ -1,5 +1,6 @@
-
-## Why gRPC gateway
+---
+title: Why gRPC gateway
+---
 
 etcd v3 uses [gRPC][grpc] for its messaging protocol. The etcd project includes a gRPC-based [Go client][go-client] and a command line utility, [etcdctl][etcdctl], for communicating with an etcd cluster through gRPC. For languages with no gRPC support, etcd provides a JSON [gRPC gateway][grpc-gateway]. This gateway serves a RESTful proxy that translates HTTP/JSON requests into gRPC messages.
 

Documentation/dev-guide/api_reference_v3.md

@@ -1,4 +1,6 @@
-### etcd API Reference
+---
+title: etcd API Reference
+---
 
 
 This is a generated documentation. Please read the proto files for more.

Documentation/dev-guide/experimental_apis.md

@@ -1,4 +1,6 @@
-# Experimental APIs and features
+---
+title: Experimental APIs and features
+---
 
 For the most part, the etcd project is stable, but we are still moving fast! We believe in the release fast philosophy. We want to get early feedback on features still in development and stabilizing. Thus, there are, and will be more, experimental features and APIs. We plan to improve these features based on the early feedback from the community, or abandon them if there is little interest, in the next few releases. Please do not rely on any experimental features or APIs in production environment.
 

Documentation/dev-guide/grpc_naming.md

@@ -1,4 +1,6 @@
-# gRPC naming and discovery
+---
+title: gRPC naming and discovery
+---
 
 etcd provides a gRPC resolver to support an alternative name system that fetches endpoints from etcd for discovering gRPC services. The underlying mechanism is based on watching updates to keys prefixed with the service name.
 

Documentation/dev-guide/interacting_v3.md

@@ -1,4 +1,6 @@
-# Interacting with etcd
+---
+title: Interacting with etcd
+---
 
 Users mostly interact with etcd by putting or getting the value of a key. This section describes how to do that by using etcdctl, a command line tool for interacting with etcd server. The concepts described here should apply to the gRPC APIs or client library APIs.
 

Documentation/dev-guide/limit.md

@@ -1,4 +1,6 @@
-# System limits
+---
+title: System limits
+---
 
 ## Request size limit
 

Documentation/dev-guide/local_cluster.md

@@ -1,4 +1,6 @@
-# Set up a local cluster
+---
+title: Set up a local cluster
+---
 
 For testing and development deployments, the quickest and easiest way is to configure a local cluster. For a production deployment, refer to the [clustering][clustering] section.
 

Documentation/dev-internal/discovery_protocol.md

@@ -1,4 +1,6 @@
-# Discovery service protocol
+---
+title: Discovery service protocol
+---
 
 Discovery service protocol helps new etcd member to discover all other members in cluster bootstrap phase using a shared discovery URL.
 

Documentation/dev-internal/logging.md

@@ -1,4 +1,6 @@
-# Logging conventions
+---
+title: Logging conventions
+---
 
 etcd uses the [capnslog][capnslog] library for logging application output categorized into *levels*. A log message's level is determined according to these conventions:
 

Documentation/dev-internal/release.md

@@ -1,4 +1,6 @@
-# etcd release guide
+---
+title: etcd release guide
+---
 
 The guide talks about how to release a new version of etcd.
 

Documentation/dl_build.md

@@ -1,4 +1,6 @@
-# Download and build
+---
+title: Download and build
+---
 
 ## System requirements
 

Documentation/faq.md

@@ -1,4 +1,6 @@
-# Frequently Asked Questions (FAQ)
+---
+title: Frequently Asked Questions (FAQ)
+---
 
 ## etcd, general
 

Documentation/integrations.md

@@ -1,4 +1,6 @@
-# Libraries and tools
+---
+title: Libraries and tools
+---
 
 **Tools**
 

Documentation/learning/api.md

@@ -1,4 +1,6 @@
-# etcd3 API
+---
+title: etcd3 API
+---
 
 This document is meant to give an overview of the etcd3 API's central design. It is by no means all encompassing, but intended to focus on the basic ideas needed to understand etcd without the distraction of less common API calls. All etcd3 API's are defined in [gRPC services][grpc-service], which categorize remote procedure calls (RPCs) understood by the etcd server. A full listing of all etcd RPCs are documented in markdown in the [gRPC API listing][grpc-api].
 

Documentation/learning/api_guarantees.md

@@ -1,4 +1,6 @@
-# KV API guarantees
+---
+title: KV API guarantees
+---
 
 etcd is a consistent and durable key value store with [mini-transaction][txn] support. The key value store is exposed through the KV APIs. etcd tries to ensure the strongest consistency and durability guarantees for a distributed system. This specification enumerates the KV API guarantees made by etcd.
 

Documentation/learning/auth_design.md

@@ -1,4 +1,6 @@
-# etcd v3 authentication design
+---
+title: etcd v3 authentication design
+---
 
 ## Why not reuse the v2 auth system?
 

Documentation/learning/data_model.md

@@ -1,4 +1,6 @@
-# Data model
+---
+title: Data model
+---
 
 etcd is designed to reliably store infrequently updated data and provide reliable watch queries. etcd exposes previous versions of key-value pairs to support inexpensive snapshots and watch history events (“time travel queries”). A persistent, multi-version, concurrency-control data model is a good fit for these use cases.
 

Documentation/learning/glossary.md

@@ -1,4 +1,6 @@
-# Glossary
+---
+title: Glossary
+---
 
 This document defines the various terms used in etcd documentation, command line and source code.
 

Documentation/learning/why.md

@@ -1,4 +1,6 @@
-# etcd versus other key-value stores
+---
+title: etcd versus other key-value stores
+---
 
 The name "etcd" originated from two ideas, the unix "/etc" folder and "d"istributed systems. The "/etc" folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a "d"istributed "/etc" is "etcd".
 

Documentation/metrics.md

@@ -1,4 +1,6 @@
-# Metrics
+---
+title: Metrics
+---
 
 etcd uses [Prometheus][prometheus] for metrics reporting. The metrics can be used for real-time monitoring and debugging. etcd does not persist its metrics; if a member restarts, the metrics will be reset.
 

Documentation/op-guide/authentication.md

@@ -1,4 +1,6 @@
-# Role-based access control
+---
+title: Role-based access control
+---
 
 ## Overview
 

Documentation/op-guide/clustering.md

@@ -1,4 +1,6 @@
-# Clustering Guide
+---
+title: Clustering Guide
+---
 
 ## Overview
 

Documentation/op-guide/configuration.md

@@ -1,4 +1,6 @@
-# Configuration flags
+---
+title: Configuration flags
+---
 
 etcd is configurable through a configuration file, various command-line flags, and environment variables.
 

Documentation/op-guide/container.md

@@ -1,4 +1,6 @@
-# Run etcd clusters inside containers
+---
+title: Run etcd clusters inside containers
+---
 
 The following guide shows how to run etcd with rkt and Docker using the [static bootstrap process](clustering.md#static).
 

Documentation/op-guide/failures.md

@@ -1,4 +1,6 @@
-# Failure modes
+---
+title: Failure modes
+---
 
 Failures are common in a large deployment of machines. A machine fails when its hardware or software malfunctions. Multiple machines fail together when there are power failures or network issues. Multiple kinds of failures can also happen at once; it is almost impossible to enumerate all possible failure cases. 
 

Documentation/op-guide/gateway.md

@@ -1,4 +1,6 @@
-# etcd gateway
+---
+title: etcd gateway
+---
 
 ## What is etcd gateway
 

Documentation/op-guide/grpc_proxy.md

@@ -1,4 +1,6 @@
-# gRPC proxy
+---
+title: gRPC proxy
+---
 
 The gRPC proxy is a stateless etcd reverse proxy operating at the gRPC layer (L7). The proxy is designed to reduce the total processing load on the core etcd cluster. For horizontal scalability, it coalesces watch and lease API requests. To protect the cluster against abusive clients, it caches key range requests.
 

Documentation/op-guide/hardware.md

@@ -1,4 +1,6 @@
-# Hardware recommendations
+---
+title: Hardware recommendations
+---
 
 etcd usually runs well with limited resources for development or testing purposes; it’s common to develop with etcd on a  laptop or a cheap cloud machine. However, when running etcd clusters in production, some hardware guidelines are useful for proper administration. These suggestions are not hard rules; they serve as a good starting point for a robust production deployment. As always, deployments should be tested with simulated workloads before running in production.
 

Documentation/op-guide/maintenance.md

@@ -1,4 +1,6 @@
-# Maintenance
+---
+title: Maintenance
+---
 
 ## Overview
 

Documentation/op-guide/monitoring.md

@@ -1,4 +1,6 @@
-# Monitoring etcd
+---
+title: Monitoring etcd
+---
 
 Each etcd server provides local monitoring information on its client port through http endpoints. The monitoring data is useful for both system health checking and cluster debugging.
 

Documentation/op-guide/performance.md

@@ -1,4 +1,6 @@
-# Performance
+---
+title: Performance
+---
 
 ## Understanding performance
 

Documentation/op-guide/recovery.md

@@ -1,4 +1,6 @@
-# Disaster recovery
+---
+title: Disaster recovery
+---
 
 etcd is designed to withstand machine failures. An etcd cluster automatically recovers from temporary failures (e.g., machine reboots) and tolerates up to *(N-1)/2* permanent failures for a cluster of N members. When a member permanently fails, whether due to hardware failure or disk corruption, it loses access to the cluster. If the cluster permanently loses more than *(N-1)/2* members then it disastrously fails, irrevocably losing quorum. Once quorum is lost, the cluster cannot reach consensus and therefore cannot continue accepting updates.
 

Documentation/op-guide/runtime-configuration.md

@@ -1,4 +1,6 @@
-# Runtime reconfiguration
+---
+title: Runtime reconfiguration
+---
 
 etcd comes with support for incremental runtime reconfiguration, which allows users to update the membership of the cluster at run time.
 

Documentation/op-guide/runtime-reconf-design.md

@@ -1,4 +1,6 @@
-# Design of runtime reconfiguration
+---
+title: Design of runtime reconfiguration
+---
 
 Runtime reconfiguration is one of the hardest and most error prone features in a distributed system, especially in a consensus based system like etcd.
 

Documentation/op-guide/security.md

@@ -1,4 +1,6 @@
-# Transport security model
+---
+title: Transport security model
+---
 
 etcd supports automatic TLS as well as authentication through client certificates for both clients to server as well as peer (server to server / cluster) communication.
 

Documentation/op-guide/supported-platform.md

@@ -1,4 +1,6 @@
-# Supported systems
+---
+title: Supported systems
+---
 
 ## Current support
 

Documentation/op-guide/v2-migration.md

@@ -1,4 +1,6 @@
-# Migrate applications from using API v2 to API v3
+---
+title: Migrate applications from using API v2 to API v3
+---
 
 The data store v2 is still accessible from the API v2 after upgrading to etcd3. Thus, it will work as before and require no application changes. With etcd 3, applications use the new grpc API v3 to access the mvcc store, which provides more features and improved performance. The mvcc store and the old store v2 are separate and isolated; writes to the store v2 will not affect the mvcc store and, similarly, writes to the mvcc store will not affect the store v2.
 

Documentation/op-guide/versioning.md

@@ -1,4 +1,6 @@
-# Versioning
+---
+title: Versioning
+---
 
 ## Service versioning
 

Documentation/platforms/aws.md

@@ -1,4 +1,6 @@
-# Amazon Web Services
+---
+title: Amazon Web Services
+---
 
 This guide assumes operational knowledge of Amazon Web Services (AWS), specifically Amazon Elastic Compute Cloud (EC2). This guide provides an introduction to design considerations when designing an etcd deployment on AWS EC2 and how AWS specific features may be utilized in that context.
 

Documentation/platforms/container-linux-systemd.md

@@ -1,4 +1,6 @@
-# Container Linux with systemd
+---
+title: Container Linux with systemd
+---
 
 The following guide shows how to run etcd with [systemd][systemd-docs] under [Container Linux][container-linux-docs].
 

Documentation/platforms/freebsd.md

@@ -1,4 +1,6 @@
-# FreeBSD
+---
+title: FreeBSD
+---
 
 Starting with version 0.1.2 both etcd and etcdctl have been ported to FreeBSD and can be installed either via packages or ports system. Their versions have been recently updated to 0.2.0 so now etcd and etcdctl can be enjoyed on FreeBSD 10.0 (RC4 as of now) and 9.x, where they have been tested. They might also work when installed from ports on earlier versions of FreeBSD, but it is untested; caveat emptor.
 

Documentation/production-users.md

@@ -1,4 +1,6 @@
-# Production users
+---
+title: Production users
+---
 
 This document tracks people and use cases for etcd in production. By creating a list of production use cases we hope to build a community of advisors that we can reach out to with experience using various etcd applications, operation environments, and cluster sizes. The etcd development team may reach out periodically to check-in on how etcd is working in the field and update this list.
 

Documentation/reporting_bugs.md

@@ -1,4 +1,6 @@
-# Reporting bugs
+---
+title: Reporting bugs
+---
 
 If any part of the etcd project has bugs or documentation mistakes, please let us know by [opening an issue][etcd-issue]. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist.
 

Documentation/rfc/v3api.md

@@ -1,4 +1,6 @@
-# Overview
+---
+title: Overview
+---
 
 The etcd v3 API is designed to give users a more efficient and cleaner abstraction compared to etcd v2. There are a number of semantic and protocol changes in this new API. For an overview [see Xiang Li's video](https://youtu.be/J5AioGtEPeQ?t=211).
 

Documentation/tuning.md

@@ -1,4 +1,6 @@
-# Tuning
+---
+title: Tuning
+---
 
 The default settings in etcd should work well for installations on a local network where the average network latency is low. However, when using etcd across multiple data centers or over networks with high latency, the heartbeat interval and election timeout settings may need tuning.
 

Documentation/upgrades/upgrade_3_0.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 2.3 to 3.0
+---
+title: Upgrade etcd from 2.3 to 3.0
+---
 
 In the general case, upgrading from etcd 2.3 to 3.0 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v2.3 processes and replace them with etcd v3.0 processes

Documentation/upgrades/upgrade_3_1.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 3.0 to 3.1
+---
+title: Upgrade etcd from 3.0 to 3.1
+---
 
 In the general case, upgrading from etcd 3.0 to 3.1 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v3.0 processes and replace them with etcd v3.1 processes

Documentation/upgrades/upgrade_3_2.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 3.1 to 3.2
+---
+title: Upgrade etcd from 3.1 to 3.2
+---
 
 In the general case, upgrading from etcd 3.1 to 3.2 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v3.1 processes and replace them with etcd v3.2 processes

Documentation/upgrades/upgrade_3_3.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 3.2 to 3.3
+---
+title: Upgrade etcd from 3.2 to 3.3
+---
 
 In the general case, upgrading from etcd 3.2 to 3.3 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v3.2 processes and replace them with etcd v3.3 processes

Documentation/upgrades/upgrade_3_4.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 3.3 to 3.4
+---
+title: Upgrade etcd from 3.3 to 3.4
+---
 
 In the general case, upgrading from etcd 3.3 to 3.4 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v3.3 processes and replace them with etcd v3.4 processes

Documentation/upgrades/upgrade_3_5.md

@@ -1,4 +1,6 @@
-## Upgrade etcd from 3.4 to 3.5
+---
+title: Upgrade etcd from 3.4 to 3.5
+---
 
 In the general case, upgrading from etcd 3.4 to 3.5 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v3.4 processes and replace them with etcd v3.5 processes

Documentation/upgrades/upgrading-etcd.md

@@ -1,8 +1,11 @@
-# Upgrading etcd clusters and applications
+---
+title: Upgrading etcd clusters and applications
+---
 
 This section contains documents specific to upgrading etcd clusters and applications.
 
 ## Moving from etcd API v2 to API v3
+
 * [Migrate applications from using API v2 to API v3][migrate-apps]
 
 ## Upgrading an etcd v3.x cluster

Documentation/v2/04_to_2_snapshot_migration.md

@@ -1,10 +1,11 @@
+---
+title: Snapshot Migration
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Snapshot Migration
-
 You can migrate a snapshot of your data from a v0.4.9+ cluster into a new etcd 2.2 cluster using a snapshot migration. After snapshot migration, the etcd indexes of your data will change. Many etcd applications rely on these indexes to behave correctly. This operation should only be done while all etcd applications are stopped.
 
 To get started get the newest data snapshot from the 0.4.9+ cluster:

Documentation/v2/README.md

@@ -1,4 +1,6 @@
-# Documentation
+---
+title: Documentation
+---
 
 etcd is a distributed key-value store designed to reliably and quickly preserve and provide access to critical data. It enables reliable distributed coordination through distributed locking, leader elections, and write barriers. An etcd cluster is intended for high availability and permanent data storage and retrieval.
 

Documentation/v2/admin_guide.md

@@ -1,10 +1,11 @@
+---
+title: Administration
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Administration
-
 ## Data Directory
 
 ### Lifecycle

Documentation/v2/api.md

@@ -1,10 +1,11 @@
+---
+title: etcd API
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# etcd API
-
 ## Running a Single Machine Cluster
 
 These examples will use a single member cluster to show you the basics of the etcd REST API.

Documentation/v2/api_v3.md

@@ -1,10 +1,11 @@
+---
+title: etcd3 API
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# etcd3 API
-
 TODO: API doc
 
 ## Data Model

Documentation/v2/auth_api.md

@@ -1,10 +1,11 @@
+---
+title: v2 Auth and Security
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# v2 Auth and Security
-
 ## etcd Resources
 There are three types of resources in etcd
 

Documentation/v2/authentication.md

@@ -1,10 +1,11 @@
+---
+title: Authentication Guide
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Authentication Guide
-
 ## Overview
 
 Authentication -- having users and roles in etcd -- was added in etcd 2.1. This guide will help you set up basic authentication in etcd.

Documentation/v2/backward_compatibility.md

@@ -1,10 +1,11 @@
+---
+title: Backward Compatibility
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Backward Compatibility
-
 The main goal of etcd 2.0 release is to improve cluster safety around bootstrapping and dynamic reconfiguration. To do this, we deprecated the old error-prone APIs and provide a new set of APIs.
 
 The other main focus of this release was a more reliable Raft implementation, but as this change is internal it should not have any notable effects to users.

Documentation/v2/branch_management.md

@@ -1,10 +1,11 @@
+---
+title: Branch Management
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Branch Management
-
 ## Guide
 
 * New development occurs on the [master branch][master].

Documentation/v2/clustering.md

@@ -1,10 +1,11 @@
+---
+title: Clustering Guide
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Clustering Guide
-
 ## Overview
 
 Starting an etcd cluster statically requires that each member knows another in the cluster. In a number of cases, you might not know the IPs of your cluster members ahead of time. In these cases, you can bootstrap an etcd cluster with the help of a discovery service.

Documentation/v2/configuration.md

@@ -1,10 +1,11 @@
+---
+title: Configuration Flags
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Configuration Flags
-
 etcd is configurable through command-line flags and environment variables. Options set on the command line take precedence over those from the environment.
 
 The format of environment variable for flag `--my-flag` is `ETCD_MY_FLAG`. It applies to all  flags.

Documentation/v2/discovery_protocol.md

@@ -1,10 +1,11 @@
+---
+title: Discovery Service Protocol
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Discovery Service Protocol
-
 Discovery service protocol helps new etcd member to discover all other members in cluster bootstrap phase using a shared discovery URL.
 
 Discovery service protocol is _only_ used in cluster bootstrap phase, and cannot be used for runtime reconfiguration or cluster monitoring.

Documentation/v2/docker_guide.md

@@ -1,9 +1,11 @@
-**This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
+---
+title: Running etcd under Docker
+---
 
-[v3-docs]: ../docs.md#documentation
 
+**This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
-# Running etcd under Docker
+[v3-docs]: ../docs.md#documentation
 
 The following guide will show you how to run etcd under Docker using the [static bootstrap process](clustering.md#static).
 

Documentation/v2/errorcode.md

@@ -1,11 +1,11 @@
+---
+title: Error Code
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Error Code
-======
-
 This document describes the error code used in key space '/v2/keys'. Feel free to import 'github.com/coreos/etcd/error' to use.
 
 It's categorized into four groups:

Documentation/v2/reporting_bugs.md

@@ -1,10 +1,11 @@
+---
+title: Reporting Bugs
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Reporting Bugs
-
 If you find bugs or documentation mistakes in the etcd project, please let us know by [opening an issue][etcd-issue]. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist.
 
 To make your bug report accurate and easy to understand, please try to create bug reports that are:

Documentation/v2/rfc/v3api.md

@@ -1,3 +1,7 @@
+---
+title: etcd v3 API
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../../docs.md#documentation

Documentation/v2/runtime-configuration.md

@@ -1,10 +1,11 @@
+---
+title: Runtime Reconfiguration
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Runtime Reconfiguration
-
 etcd comes with support for incremental runtime reconfiguration, which allows users to update the membership of the cluster at run time.
 
 Reconfiguration requests can only be processed when the majority of the 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 able to make progress and need to [restart from majority failure][majority failure].

Documentation/v2/runtime-reconf-design.md

@@ -1,10 +1,11 @@
+---
+title: Design of Runtime Reconfiguration
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Design of Runtime Reconfiguration
-
 Runtime reconfiguration is one of the hardest and most error prone features in a distributed system, especially in a consensus based system like etcd.
 
 Read on to learn about the design of etcd's runtime reconfiguration commands and how we tackled these problems.

Documentation/v2/security.md

@@ -1,10 +1,11 @@
+---
+title: Security Model
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Security Model
-
 etcd supports SSL/TLS as well as authentication through client certificates, both for clients to server as well as peer (server to server / cluster) communication.
 
 To get up and running you first need to have a CA certificate and a signed key pair for one member. It is recommended to create and sign a new key pair for every member in a cluster.

Documentation/v2/tuning.md

@@ -1,10 +1,11 @@
+---
+title: Tuning
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Tuning
-
 The default settings in etcd should work well for installations on a local network where the average network latency is low.
 However, when using etcd across multiple data centers or over networks with high latency you may need to tweak the heartbeat interval and election timeout settings.
 

Documentation/v2/upgrade_2_1.md

@@ -1,10 +1,11 @@
+---
+title: Upgrade etcd from 2.1 to 2.2
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Upgrade etcd to 2.1
-
 In the general case, upgrading from etcd 2.0 to 2.1 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v2.0 processes and replace them with etcd v2.1 processes
  - after you are running all v2.1 processes, new features in v2.1 are available to the cluster

Documentation/v2/upgrade_2_2.md

@@ -1,10 +1,11 @@
+---
+title: Upgrade etcd from 2.1 to 2.2
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-# Upgrade etcd from 2.1 to 2.2
-
 In the general case, upgrading from etcd 2.1 to 2.2 can be a zero-downtime, rolling upgrade:
 
  - one by one, stop the etcd v2.1 processes and replace them with etcd v2.2 processes

Documentation/v2/upgrade_2_3.md

@@ -1,10 +1,11 @@
+---
+title: Upgrade etcd from 2.2 to 2.3
+---
+
 **This is the documentation for etcd2 releases. Read [etcd3 doc][v3-docs] for etcd3 releases.**
 
 [v3-docs]: ../docs.md#documentation
 
-
-## Upgrade etcd from 2.2 to 2.3
-
 In the general case, upgrading from etcd 2.2 to 2.3 can be a zero-downtime, rolling upgrade:
  - one by one, stop the etcd v2.2 processes and replace them with etcd v2.3 processes
  - after running all v2.3 processes, new features in v2.3 are available to the cluster