Skip to content

Commit

Permalink
Merge remote-tracking branch 'upstream/master'
Browse files Browse the repository at this point in the history 
* upstream/master: (944 commits)
  Rename service port to http (helm#4442)
  [stable/neo4j] Change the image of the initContainer examples (helm#4269)
  move burrow to stable repo (helm#3481)
  Upgrade kube-state-metrics to 1.2.0, add new collectors (helm#4146)
  Add review guidelines around pvcs (helm#4223)
  [stable/parse] Release 0.3.10 (helm#4389)
  [stable/phabricator] Release 0.5.19 (helm#4433)
  Support exposing jmx and additional ports (helm#4072)
  Add default of "" for string comparison (helm#4420)
  [incubator/kafka] Makes readiness probe configurable (helm#3948)
  Published stash chart 0.7.0-rc.1 (helm#4410)
  Enable testing charts with test values (helm#4157)
  [incubator/kafka] Fix initContainer failure which did not error (helm#4400)
  [stable/etcd-operator] deployment typos and add tolerations (helm#4139)
  Typo fix in coscale/README.md (helm#4306)
  Typo fix in concourse/README.md (helm#4303)
  Typo fix in cockroachdb/README.md (helm#4302)
  [stable/jenkins] Bump appVersion (helm#4177)
  Typo fix in cluster-autoscaler/README.md (helm#4301)
  [stable/traefik] Bump appVersion to 1.5.4 (helm#4206)
  ...
  • Loading branch information
@joshuacox
joshuacox committed Mar 24, 2018
2 parents 31c6524 + 978daf5 commit c859f47
Show file tree
Hide file tree
Showing 1,469 changed files with 37,526 additions and 5,644 deletions.
5 changes: 2 additions & 3 deletions .circleci/config.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -2,13 +2,12 @@ version: 2
jobs:
build:
docker:
# TODO: Update to 3.6.3 when the image become available
- image: circleci/python:3.6.2
- image: circleci/python:3.6.4
steps:
- checkout
- run:
name: install tools
command: test/circle/install.sh
- run:
name: lint
command: test/circle/lint.sh
command: test/circle/lint.sh
21 changes: 16 additions & 5 deletions .github/PULL_REQUEST_TEMPLATE.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,4 @@
*****************************************************************************************

<!--
Thank you for contributing to kubernetes/charts. Before you submit this PR we'd like to
make sure you are aware of our technical requirements and best practices:
Expand All @@ -14,8 +13,20 @@ our review guidelines:
Following our best practices right from the start will accelerate the review process and
help get your PR merged quicker.
When updates to your PR are requested, please add new commits and do not squash the
history. This will make it easier to identify new changes. The PR will be squashed
When updates to your PR are requested, please add new commits and do not squash the
history. This will make it easier to identify new changes. The PR will be squashed
anyways when it is merged. Thanks.
*****************************************************************************************
For fast feedback, please @-mention maintainers that are listed in the Chart.yaml file.
Please make sure you test your changes before you push them. Once pushed, a CircleCI
will run across your changes and do some initial checks and linting. These checks run
very quickly. Please check the results. We would like these checks to pass before we
even continue reviewing your changes.
-->

**What this PR does / why we need it**:

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ Once the Chart has been merged, the release job will automatically run in the CI

Whether you are a user or contributor, official support channels include:

- GitHub issues: https://github.com/kubenetes/charts/issues
- GitHub issues: https://github.com/kubernetes/charts/issues
- Slack: Helm Users - #Helm-users room in the [Kubernetes Slack](http://slack.kubernetes.io/)
- Slack: Helm Developers - #Helm-dev room in the [Kubernetes Slack](http://slack.kubernetes.io/)

Expand Down
4 changes: 2 additions & 2 deletions OWNERS
View file
Original file line number Diff line number Diff line change
@@ -1,11 +1,11 @@
maintainers:
approvers:
- lachie83
- linki
- mgoodness
- prydonius
- sameersbn
- seanknox
- viglesias
- viglesiasce
- foxish
- unguiculus
- scottrigby
Expand Down
49 changes: 49 additions & 0 deletions PROCESSES.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Processes

This document outlines processes and procedures for some common tasks in the charts repository.

## Deprecating A Chart

When a chart is no longer maintained it can be [deprecated](https://en.wikipedia.org/wiki/Deprecation). Once a chart is deprecated the expectation is the chart will see no further development. The chart and its versions will still be accessible, though tools such as [monocular](https://github.com/kubernetes-helm/monocular) and [Kubeapps Hub](https://hub.kubeapps.com/) will no longer list the chart.

To deprecate a chart perform the following:

1. Increment the chart `version` in the `Chart.yaml` file. This is required as all charts are immutable.
1. Add a property to the `Chart.yaml` file of `deprecated: true` at the top level of the YAML structure.
1. Above the deprecated property add a comment noting that the chart is deprecated and linking to the deprecation policy.
1. Remove any maintainers from the chart as the chart is no longer maintained.
1. Prefix the description with "DEPRECATED"
1. Update READMEs and NOTES.txt to note that the chart is deprecated

For example, A `Chart.yaml` could start like:

```yaml
name: foo
# The foo chart is deprecated and no longer maintained. For details deprecation,
# including how to un-deprecate a chart see the PROCESSES.md file.
deprecated: true
description: DEPRECATED foo bar baz qux...
```
## Un-deprecating A Chart
When new maintainers are interested in bring a chart out of deprecation with
new features or new support that can be an option. To un-deprecate a chart:
1. Update the maintainers on the chart if any are listed. The previous maintainers should not be expected to maintain the chart unless they explicitly decide to do so.
1. If there is an OWNERS file in the chart that should be updated with the new reviewers and approvers.
1. The deprecated property from the `Chart.yaml` file should be removed along with any associated comment.
1. The chart `version` needs to be incremented accordingly. If the same functionality is kept the version can be a patch increase. Otherwise the minor or major version needs to be incremented. For more detail on changing the version number see the [semver specification](http://semver.org).

## Promoting A Chart From Incubator To Stable

When promoting a chart from incubator to stable there are several steps that need to be carried out.

1. Prior to promoting the chart verify that it does not depend on any other incubator charts. Stable charts cannot depend on incubator charts.
1. The chart should be copied, not moved, from the incubator directory to the stable directory.
1. The chart in the incubator directory should be deprecated with the `deprecated: true` property being set and a comment noting that the chart has been promoted to stable. The chart version will, also, need to have the patch level of the `version` incremented.
1. The version of the chart in the stable directory should be updated so that any documentation or other details points to stable rather than incubator. The chart `version` will, also, need to be incremented.

## Reviewing A Pull Request

There are two parts to reviewing a pull request in the process to do so and the guidelines to follow. Both of those are outlined in the [Review Guidelines](REVIEW_GUIDELINES.md).
29 changes: 20 additions & 9 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,12 @@
Use this repository to submit official Charts for Kubernetes Helm. Charts are curated application definitions for Kubernetes Helm. For more information about installing and using Helm, see its
[README.md](https://github.com/kubernetes/helm/tree/master/README.md). To get a quick introduction to Charts see this [chart document](https://github.com/kubernetes/helm/blob/master/docs/charts.md).

## Where to find us

For general Helm Chart discussions join the Helm Charts (#charts) room in the [Kubernetes](http://slack.kubernetes.io/).

For issues and support for Helm and Charts see [Support Channels](CONTRIBUTING.md#support-channels).

## How do I install these charts?

Just `helm install stable/<chart>`. This is the default repository for Helm which is located at https://kubernetes-charts.storage.googleapis.com/ and is installed by default.
Expand Down Expand Up @@ -35,6 +41,7 @@ The Charts in the `stable/` directory in the master branch of this repository ma
The purpose of this repository is to provide a place for maintaining and contributing official Charts, with CI processes in place for managing the releasing of Charts into the Chart Repository.

The Charts in this repository are organized into two folders:

* stable
* incubator

Expand All @@ -51,23 +58,27 @@ We'd love for you to contribute a Chart that provides a useful application or se
Note: We use the same [workflow](https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#workflow),
[License](LICENSE) and [Contributor License Agreement](CONTRIBUTING.md) as the main Kubernetes repository.

## Owning and Maintaining A Chart

Individual charts can be maintained by one or more members of the Kubernetes community. When someone maintains a chart they have the access to merge changes to that chart. To have merge access to a chart someone first needs to be listed on the chart, in the `Chart.yaml` file, as a maintainer. If that is the case there are two steps that need to happen:

1. Become a [member of the Kubernetes community](https://github.com/kubernetes/community/blob/master/community-membership.md). If you need sponsors and have contributed to charts please reach out to one of the [OWNERS](OWNERS) of the charts repository.
2. An OWNERS file needs to be added to a chart. That OWNERS file should list the maintainers GitHub Login names for both the reviewers and approvers sections. For an example see the [Drupal chart](stable/drupal/OWNERS). The `OWNERS` file should also be appended to the `.helmignore` file.

Once these two steps are done a chart approver can merge pull requests following the directions in the [REVIEW_GUIDELINES.md](REVIEW_GUIDELINES.md) file.

## Review Process

The following outlines the review procedure used by the Chart repository maintainers. Github labels are used to indicate state change during the review process.
For information related to the review procedure used by the Chart repository maintainers, see [Merge approval and release process](CONTRIBUTING.md#merge-approval-and-release-process).

* ***AWAITING REVIEW*** - Initial triage which indicates that the PR is ready for review by the maintainers team. The CLA must be signed and e2e tests must pass in-order to move to this state
* ***CHANGES NEEDED*** - Review completed by at least one maintainer and changes needed by contributor (explicit even when using the review feature of Github)
* ***CODE REVIEWED*** - The chart structure has been reviewed and found to be satisfactory given the [technical requirements](CONTRIBUTING.md#technical-requirements) (may happen in parallel to UX REVIEWED)
* ***UX REVIEWED*** - The chart installation UX has been reviewed and found to be satisfactory. (may happen in parallel to CODE REVIEWED)
* ***LGTM*** - Added ONLY once both UX/CODE reviewed are both present. Merge must be handled by someone OTHER than the maintainer that added the LGTM label. This label indicates that given a quick pass of the comments this change is ready to merge

### Stale Pull Requests
### Stale Pull Requests and Issues

After initial review feedback, if no updates have been made to the pull request for 1 week, the `stale` label will be added. If after another week there are still no updates it will be closed. Please re-open if/when you have made the proper adjustments.
Pull Requests and Issues that have no activity for 30 days automatically become stale. After 30 days of being stale, without activity, they become rotten. Pull Requests and Issues can rot for 30 days and then they are automatically closed. This is the standard stale process handling for all repositories on the Kubernetes GitHub organization.

## Supported Kubernetes Versions

This chart repository supports the latest and previous minor versions of Kubernetes. For example, if the latest minor release of Kubernetes is 1.8 then 1.7 and 1.8 are supported. Charts may still work on previous versions of Kubernertes even through they are outside the target supported window.
This chart repository supports the latest and previous minor versions of Kubernetes. For example, if the latest minor release of Kubernetes is 1.8 then 1.7 and 1.8 are supported. Charts may still work on previous versions of Kubernertes even though they are outside the target supported window.

To provide that support the API versions of objects should be those that work for both the latest minor release and the previous one.

Expand Down
98 changes: 95 additions & 3 deletions REVIEW_GUIDELINES.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,16 @@
# Chart Review Guidelines

Anyone is welcome to review pull requests. Besides our [technical requirements](https://github.com/kubernetes/charts/blob/master/CONTRIBUTING.md#technical-requirements) and [best practices](https://github.com/kubernetes/helm/tree/master/docs/chart_best_practices), here's an overview of review guidelines.
Anyone is welcome to review pull requests. Besides our [technical requirements](https://github.com/kubernetes/charts/blob/master/CONTRIBUTING.md#technical-requirements) and [best practices](https://github.com/kubernetes/helm/tree/master/docs/chart_best_practices), here's an overview of process and review guidelines.

## Process

The process to get a pull request merged is fairly simple. First, all required tests need to pass and the contributor needs to have a signed CLA. See [Charts Testing](https://github.com/kubernetes/charts/blob/master/test/README.md) for details on our CI system and how you can provide custom values for testing. If there is a problem with some part of the test, such as a timeout issue, please contact one of the charts repository maintainers by commenting `cc @kubernetes/charts-maintainers`.

The charts repository uses the OWNERS files to provide merge access. If a chart has an OWNERS file, an approver listed in that file can approve the pull request. If the chart does not have an OWNERS file, an approver in the OWNERS file at the root of the repository can approve the pull request.

To approve the pull request, an approver needs to leave a comment of `/lgtm` on the pull request. Once this is in place some tags (`lgtm` and `approved`) will be added to the pull request and a bot will come along and perform the merge.

Note, if a reviewer who is not an approver in an OWNERS file leaves a comment of `/lgtm` a `lgtm` label will be added but a merge will not happen.

## Immutability

Expand Down Expand Up @@ -29,7 +39,7 @@ Resources and labels should follow some conventions. The standard resource metad
name: {{ template "myapp.fullname" . }}
labels:
app: {{ template "myapp.name" . }}
chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
chart: {{ template "myapp.chart" . }}
release: {{ .Release.Name }}
heritage: {{ .Release.Service }}
```
Expand Down Expand Up @@ -66,10 +76,92 @@ image:
* The use of the `default` function should be avoided if possible in favor of defaults in `values.yaml`.
* It is usually best to not specify defaults for resources and to just provide sensible values that are commented out as a recommendation, especially when resources are rather high. This makes it easier to test charts on small clusters or Minikube. Setting resources should generally be a conscious choice of the user.

## Persistence

* Persistence should be enabled by default
* PVCs should support specifying an existing claim
* Storage class should be empty by default so that the default storage class is used
* All options should be shown in README.md
* Example persistence section in values.yaml:

```yaml
persistence:
enabled: true
## If defined, storageClassName: <storageClass>
## If set to "-", storageClassName: "", which disables dynamic provisioning
## If undefined (the default) or set to null, no storageClassName spec is
## set, choosing the default provisioner. (gp2 on AWS, standard on
## GKE, AWS & OpenStack)
##
storageClass: ""
accessMode: ReadWriteOnce
size: 10Gi
# existingClaim: ""
```

* Example pod spec within a deployment:

```yaml
volumes:
- name: data
{{- if .Values.persistence.enabled }}
persistentVolumeClaim:
claimName: {{ .Values.persistence.existingClaim | default (include "fullname" .) }}
{{- else }}
emptyDir: {}
{{- end -}}
```

* Example pvc.yaml

```yaml
{{- if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: {{ template "fullname" . }}
labels:
app: {{ template "name" . }}
chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
release: "{{ .Release.Name }}"
heritage: "{{ .Release.Service }}"
spec:
accessModes:
- {{ .Values.persistence.accessMode | quote }}
resources:
requests:
storage: {{ .Values.persistence.size | quote }}
{{- if .Values.persistence.storageClass }}
{{- if (eq "-" .Values.persistence.storageClass) }}
storageClassName: ""
{{- else }}
storageClassName: "{{ .Values.persistence.storageClass }}"
{{- end }}
{{- end }}
{{- end }}
```

## Documentation

`README.md` and `NOTES.txt` are mandatory. `README.md` should contain a table listing all configuration options. `NOTES.txt` should provide accurate and useful information how the chart can be used/accessed.

## Compatibility

We officially support compatibility with the current and the previous minor version of Kubernetes. Generated resources should use the latest possible API versions compatible with these versions. For extended backwards compatibility conditional logic based on capalilities may be used (see [built-in objects](https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/builtin_objects.md)).
We officially support compatibility with the current and the previous minor version of Kubernetes. Generated resources should use the latest possible API versions compatible with these versions. For extended backwards compatibility conditional logic based on capabilities may be used (see [built-in objects](https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/builtin_objects.md)).

## Kubernetes Native Workloads.

While reviewing Charts that contain workloads such as [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) the below points should be considered. These are to be seen as best practices rather than strict enforcement.

1. Any workload that are stateless and long running (servers) in nature are to be created as Deployments. Deployments in turn create ReplicaSets.
2. Unless there is a compelling reason, ReplicaSets or ReplicationControllers should be avoided as workload types.
3. Workloads that are stateful in nature such as databases, key-value stores, message queues, in-memory caches are to be created as StatefulSets
4. It is recommended that Deployments and StatefulSets configure their workloads with a [Pod Disruption Budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) for high availability.
5. For workloads such as databases, KV stores, etc., that replicate data, it is recommended to configure interpod anti-affinity.
6. It is recommended to have a default workload update strategy configured that is suitable for this chart.
7. Batch workloads are to be created using Jobs.
8. It is best to always create workloads with the latest supported [api version](https://v1-8.docs.kubernetes.io/docs/api-reference/v1.8/) as older version are either deprecated or soon to be deprecated.
9. It is generally not advisable to provide hard [resource limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#resource-requests-and-limits-of-pod-and-container) to workloads and leave it configurable unless the workload requires such quantity bare minimum to function.
10. As much as possible complex pre-app setups are configured using [init contianers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).

More [configuration](https://kubernetes.io/docs/concepts/configuration/overview/) best practices.
3 changes: 3 additions & 0 deletions code-of-conduct.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Kubernetes Community Code of Conduct

Please refer to our [Kubernetes Community Code of Conduct](https://git.k8s.io/community/code-of-conduct.md)
21 changes: 21 additions & 0 deletions incubator/burrow/.helmignore
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Patterns to ignore when building packages.
# This supports shell glob matching, relative path matching, and
# negation (prefixed with !). Only one pattern per line.
.DS_Store
# Common VCS dirs
.git/
.gitignore
.bzr/
.bzrignore
.hg/
.hgignore
.svn/
# Common backup files
*.swp
*.bak
*.tmp
*~
# Various IDEs
.project
.idea/
*.tmproj
18 changes: 18 additions & 0 deletions incubator/burrow/Chart.yaml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
name: burrow
version: 0.3.3
appVersion: 0.17.1
deprecated: true # moved to stable
description: Burrow is a permissionable smart contract machine
icon: https://pbs.twimg.com/profile_images/697035383679295488/_6vl74tM_400x400.png
keywords:
- blockchain
- smart_contracts
- smartContracts
- smart contracts
- ethereum
- hyperledger
- evm
sources:
- https://github.com/hyperledger/burrow
- https://quay.io/monax/db
engine: gotpl
Loading

0 comments on commit c859f47

Please sign in to comment.