Skip to content

Commit

Permalink
Merge branch 'master' into release-1.8
Browse files Browse the repository at this point in the history
  • Loading branch information
steveperry-53 committed Aug 25, 2017
2 parents 9403dc3 + 44f3aca commit 895a607
Show file tree
Hide file tree
Showing 34 changed files with 311 additions and 118 deletions.
11 changes: 1 addition & 10 deletions .travis.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
language: go
go:
- 1.8.1
- 1.8.3

# Don't want default ./... here:
install:
Expand All @@ -15,15 +15,6 @@ install:
- cp -L -R $GOPATH/src/k8s.io/kubernetes/vendor/ $GOPATH/src/
- rm -r $GOPATH/src/k8s.io/kubernetes/vendor/

# (2) Fetch md-check along with all its dependencies.
- git clone --depth=50 --branch=master https://github.com/kubernetes/md-check $HOME/gopath/src/k8s.io/md-check
- go get -t -v k8s.io/md-check

# (3) Fetch mungedocs
- go get -v k8s.io/kubernetes/cmd/mungedocs

script:
- go test -v k8s.io/kubernetes.github.io/test
- $GOPATH/bin/md-check --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io
- ./verify-docs-format.sh
- $GOPATH/bin/mungedocs --verbose --verify --upstream=origin --root-dir=$HOME/gopath/src/k8s.io/kubernetes.github.io/docs/ --repo-root=$HOME/gopath/src/k8s.io/kubernetes.github.io --skip-munges=remove-whitespace,blank-lines-surround-preformatted,header-lines,sync-examples,analytics,analytics,kubectl-dash-f,table-of-contents,md-links,kubectl-dash-f
1 change: 0 additions & 1 deletion CNAME

This file was deleted.

2 changes: 1 addition & 1 deletion Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -15,4 +15,4 @@ serve: ## Boot the development server.
jekyll serve

stage: ## Run the Jekyll staging container.
docker run -ti --rm -v "$PWD":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.1
docker run -ti --rm -v "${PWD}":/k8sdocs -p 4000:4000 gcr.io/google-samples/k8sdocs:1.1
12 changes: 12 additions & 0 deletions _data/canonical-tags.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
- Fundamental
- API Object
- Metadata
- Configuration
- Security
- Networking
- Storage
- Operation
- Workload
- Component
- API
- Extension
30 changes: 0 additions & 30 deletions _data/canonical-terms-tags.yml

This file was deleted.

17 changes: 17 additions & 0 deletions _data/glossary/_example.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
id: _example
name: Example K8s Term
formerly:
- Slang K8s Term
- Misnomer
- Formerly Known as Prince
related:
- Less Fancy K8s Term
- Tangential Term
- Commonly Used With
tags:
- Some Tag
short-description: |
Required. One or two lines that provide a minimum definition. Do not repeat the term. Write about the plural of the term. Prefer fragments. Model after tooltips. End with a period.
long-description: |
Optional. Longer additional text to appear after (in conjunction with) short description. Provide where the short description is not sufficient as the intro paragraph to a topic. Write complete but concise sentences.
**See /_includes/templates/glossary/README.md for the official style guide.**
18 changes: 18 additions & 0 deletions _data/glossary/statefulset.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
id: statefulset
name: StatefulSet
formerly:
- PetSet
related:
- Deployment
- Pod
tags:
- Storage
- Workload
- API Object
short-description: |
Manage the deployment and scaling of a set of Pods, *and provide guarantees about ordering*. They do so by maintaining a *unique*, sticky identity for each of their Pods.
long-description: |
Like Deployments, StatefulSets manage Pods that are based on an identical container spec. However, although their specs are the same, the Pods in a StatefulSet are not interchangeable. Each Pod has a persistent identifier that it maintains across any rescheduling.
StatefulSets also operate according to the Controller pattern. You define your desired state in a StatefulSet *object*, and the StatefulSet *controller* makes any necessary updates to the get there from the current state.
24 changes: 0 additions & 24 deletions _includes/glossary/_glossary-template.md

This file was deleted.

15 changes: 15 additions & 0 deletions _includes/tag-map.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
<!-- Use include_cached when incorporating this file, in order to reduce computation/build time -->

{% assign glossary_terms = site.data.glossary | where_exp: "term", "term.id != '_example'" %}

{% assign tag_map = "" | split: " " %}

{% for tag in site.data.canonical-tags %}

{% assign term_list = glossary_terms | where_exp:"term", "term.tags contains tag" | map: "id" %}

{% assign tag_obj = "" | split: " " | push: tag | push: term_list %}

{% assign tag_map = tag_map | push: tag_obj %}

{% endfor %}
62 changes: 62 additions & 0 deletions _includes/templates/glossary/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Kubernetes Glossary

To write a glossary snippet, start with a copy of the template, [`/_data/glossary/_example.yml`](/_data/glossary/_example.yml). Make sure to provide (or omit) values for the following fields:

* (Required) `id`.
* This field must match the name of the glossary file itself (without the `*.yml` extension). It is *not* intended to be displayed to users, and is only used programmatically.
* (Required) `name`.
* The name of the term.
* (Required) `tags`.
* Must be one of the tags listed in kubernetes.github.io/_data/canonical-terms-tags.yml.
* (Required) `short description`.
* Make sure to replace the instructional text in the template with your content.
* (Optional) `formerly` and `related`.
* If you do not provide these values, remove the fields.
* (Optional) `long description`.
* If you do not provide a long description, remove the field -- that is, the complete key-value pair.

The `_example.yml` template also contains basic information about how to write your snippet. For additional guidance, continue reading this readme.

## Glossary snippet style guide

This style guide supplements the guidance provided in the glossary template. It's intended to help you think about what and how to write glossary definitions. For more general guidance on style, consult [the core docs style guide](https://kubernetes.io/docs/home/contribute/style-guide/).

### Minimum viable snippet:

Every snippet must include at least the short description. The long description is optional, but should be provided for terms that need additional clarification. For consistency with existing *Concept* definitions, *write your definitions as if the term is plural*.

**short-description** (Required): One line (or two short lines) that provides a minimum definition. Do not repeat the term. Prefer fragments. Model after tooltips. End with a period.

**long-description** (Optional): Longer additional text to appear after (in conjunction with) short description. Provide in cases where the short description is not sufficient for the intro paragraph to a topic. Write complete but concise sentences.

### Examples

```yaml
- name: Pod
- tags:
- Fundamental
- Workload
- API Object
- short-description: The smallest and simplest Kubernetes objects. Represent a set of running processes on your cluster.
- long-description: Pods most often run only a single container, and are managed by a Deployment.
```
```yaml
- name: Deployment
- tags:
- Fundamental
- Workload
- API Object
- short-description: Controllers that provide declarative updates for Pods and ReplicaSets.
- long-description: Deployments are responsible for creating and updating instances of an application.
```
### Thinking about definitions
* **Think of the short description as it would appear in a tooltip.** Is it sufficient to get the reader started? Is it short enough to be read inside a small UI element?
*Tip*: look at the API reference doc content (for example, https://kubernetes.io/docs/api-reference/v1.7/). Note, however, that this content should be used with care. The concept docs for Pod, for example, are clearer than the reference docs.
* **The long description should follow the short description to make a complete introduction to a topic.** (This is the content that appears at the top of the content, before any generated TOC.) Does it provide information that's not already clear from the short description? Does it provide information that readers should have a general sense of before they dive into the details of the topic it helps introduce?
*Tip:* the long description does not need to be long; it's intended to extend but not replace the short description. Look through current related docs for ideas. (The Deployment long description is taken from a tutorial, for example.)
10 changes: 10 additions & 0 deletions _includes/templates/glossary/_error.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
### ERROR: You must define a <span style="font-family: monospace">`{{ include.missing_block }}`</span> field
{: style="color:red" }

The glossary template requires that you provide text that {{ include.purpose }}.

To get rid of this message and take advantage of this template, define the `{{ include.missing_block }}`
field for the `{{ include.term }}` glossary term and populate it with content.

See `_data/glossary/_example.yml` for reference.
<!-- TEMPLATE_ERROR -->
25 changes: 25 additions & 0 deletions _includes/templates/glossary/snippet.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
{% assign term_data = site.data.glossary.[include.term] %}

{% if term_data.short-description %}

{{ term_data.short-description | markdownify }}

{% else %}

{% include templates/glossary/_error.md term=term_data.name missing_block='short-description' purpose='concisely describes the key term in 1-2 lines' %}

{% endif %}

{% if include.length == "long" %}

{% if term_data.long-description %}

{{ term_data.long-description | markdownify }}

{% else %}

{% include templates/glossary/_error.md term=term_data.name missing_block='long-description' purpose='describes the key term in greater depth, supplementing the short-description' %}

{% endif %}

{% endif %}
2 changes: 1 addition & 1 deletion case-studies/ancestry.html
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ <h2>Solution</h2>
The company is transitioning to cloud native infrastructure, using <a href="https://www.docker.com">Docker</a> containerization, <a href="https://kubernetes.io">Kubernetes</a> orchestration and <a href="https://prometheus.io">Prometheus</a> for cluster monitoring.<br>
<br>
<h2>Impact</h2>
"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced a significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
"Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We’ve truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."
</div>
</div>
</section>
Expand Down
Loading

0 comments on commit 895a607

Please sign in to comment.