Skip to content

Commit

Permalink
Merge branch 'v1.3.1-nodeps' into openshift-newer-coredns
Browse files Browse the repository at this point in the history
  • Loading branch information
bbrowning committed Feb 6, 2019
2 parents 4fbb9ba + c463189 commit 30221b1
Show file tree
Hide file tree
Showing 3,435 changed files with 12,440 additions and 1,105,487 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
19 changes: 19 additions & 0 deletions .benchmark.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
#!/usr/bin/env bash

set -e +o pipefail

# bit too spammy
return

if [ "$TRAVIS_PULL_REQUEST" != "false" ] ; then
echo -e "NOTE: The CPU benchmarks are performed on Travis VMs and vary widly between runs," > .benchmark.body
echo -e " you can't trust them. The memory benchmarks are OK\n\n" >> .benchmark.body
awk '/^benchmark.*old/ { printf "%s\n%s\n", "```", $0 };
/^$/ { print "```" };
/^Bench/ { print $0 };
END{ print "```" }' .benchmark.log >> .benchmark.body
jq -n --arg body "$(cat .benchmark.body)" '{body: $body}' > .benchmark.json
curl -H "Authorization: token ${GITHUB_TOKEN}" -X POST \
--data-binary "@.benchmark.json" \
"https://api.github.com/repos/${TRAVIS_REPO_SLUG}/issues/${TRAVIS_PULL_REQUEST}/comments"
fi
8 changes: 8 additions & 0 deletions .github/ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
<!--
When reporting bugs and requesting assistance, please include:
* the version of CoreDNS you are using
* your Corefile
* logs, if applicable
Thanks for using CoreDNS!
-->
2 changes: 0 additions & 2 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,6 @@ Corefile
coredns
coredns.exe
coredns.exe~
debug
debug.test
kubectl
go-test-tmpfile*
coverage.txt
Expand Down
1 change: 1 addition & 0 deletions .presubmit/filename-hyphen
Original file line number Diff line number Diff line change
Expand Up @@ -5,5 +5,6 @@ echo "** presubmit/$(basename $0)"
for dir in "$@"; do
if find $dir | grep '-'; then
echo "** presubmit/$(basename $0): please use an underscore in filenames instead of a hyphen"
exit 1
fi
done
7 changes: 7 additions & 0 deletions .presubmit/trailing-whitespace
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
#!/bin/bash

echo "** presubmit/$(basename $0)"

if grep -r '[[:blank:]]$' "$@"; then
echo "** presubmit/$(basename $0): please remove any trailing white space"
fi
10 changes: 10 additions & 0 deletions .stickler.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
---
linters:
golint:
min_confidence: 0.85
fixer: true

files:
ignore:
- 'vendor/*'
- 'pb/*'
18 changes: 11 additions & 7 deletions .travis.yml
Original file line number Diff line number Diff line change
@@ -1,24 +1,27 @@
sudo: required
# Trusty distribution is much faster when sudo is required
dist: trusty

services:
- docker

language: go
go:
- "1.10.x"
- "1.11.x"

go_import_path: github.com/coredns/coredns

git:
depth: 3

branches:
only:
- master

env:
- TEST_TYPE=coverage ETCD_VERSION=2.3.1
- TEST_TYPE=integration ETCD_VERSION=2.3.1
- TEST_TYPE=core ETCD_VERSION=2.3.1
- TEST_TYPE=plugin ETCD_VERSION=2.3.1
- TEST_TYPE=coverage ETCD_VERSION=3.3.8
- TEST_TYPE=integration ETCD_VERSION=3.3.8
- TEST_TYPE=core ETCD_VERSION=3.3.8
- TEST_TYPE=plugin ETCD_VERSION=3.3.8

# In the Travis VM-based build environment, IPv6 networking is not
# enabled by default. The sysctl operations below enable IPv6.
Expand All @@ -35,10 +38,11 @@ before_install:

before_script:
- docker run -d --net=host --name=etcd quay.io/coreos/etcd:v$ETCD_VERSION
- make godeps

script:
- make TEST_TYPE=$TEST_TYPE travis


after_success:
- bash <(curl -s https://codecov.io/bash)
- bash .benchmark.sh
20 changes: 20 additions & 0 deletions ADOPTERS.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,3 +7,23 @@
* [Tradeshift](https://tradeshift.com/) uses CoreDNS to look up company identifiers across multiple shards/regions/zones
* [SoundCloud](https://soundcloud.com/) uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second.
* [Z Lab](https://zlab.co.jp) uses CoreDNS in production combination with Consul and Kuberenetes Clusters.
* [Serpro/estaleiro](estaleiro.serpro.gov.br) uses CoreDNS as Kubernetes' DNS Server, in production with tuned Kubernetes plugin options
* [Lumo](https://thinklumo.com) uses CoreDNS as Kubernetes' DNS Server, in production and lab with default configuration
* [Booming Games](https://booming-games.com) uses CoreDNS in multiple Kubernetes clusters, with Federation plugin. expect going to production soon.
* [Sodimac](http://www.sodimac.cl) uses CoreDNS with Kubernetes in production with default configuration.
* [Bose](https://www.bose.com/) uses CoreDNS with Kubernetes in production on very large cluster (over 250 nodes)
* [farmotive](https://farmotive.io) uses CoreDNS in Kubernetes using default configuration, in its Lab. Expect to be in production soon.
* [Zalando SE](https://www.zalando.de) uses CoreDNS as Kubernetes' DNS Server, in production.
* [Trainline](https://trainline.com) uses CoreDNS along with Kubernetes in production, with a tuned configuration.
* [AnchorFree](https://www.anchorfree.com) uses CoreDNS within Kubernetes in production, with standard configuration.
* [Datacom](https://datacom.co.nz) uses CoreDNS with a tuned configuration for Kubernetes, as production.
* [Takealot.com](https://www.takealot.com) uses CoreDNS as Kubernetes' DNS Server, in production.
* [scalable minds](https://scalableminds.com) uses CoreDNS with default configuration for Kubernetes in its production environment.
* [ObjectRocket](https://www.objectrocket.com) uses CoreDNS on its numerous Kubernetes' clusters, using refined configurations. Address both Lab and Production environment
* [Devino Telecom](https://devinotele.com) uses CoreDNS with default configuration for Kubernetes for its Lab and its Production.
* [Yandex Money](https://money.yandex.ru) uses CoreDNS in Lab and Production, using default configuration for Kubernetes.
* [AdGuard](https://adguard.com/) uses CoreDNS in [AdGuard Home](https://github.com/AdguardTeam/AdGuardHome) and, therefore, in production public AdGuard DNS servers.
* [Skyscanner](https://www.skyscanner.net) uses CoreDNS within Kubernetes in production with the configuration tuned to use the Autopath plugin.
* [Zinza Technology](http://zinza.com.vn) uses CoreDNS within Kubernetes in production, with standard configuration.
* [Hualala](http://www.hualala.com/home) uses CoreDNS in Kubernetes using default configuration, in its Lab. Expected to be in production soon.
* [Hellofresh](https://www.hellofresh.com/) uses CoreDNS in multiple Kubernetes clusters, with Forward plugin.
2 changes: 1 addition & 1 deletion CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ $ go get -u github.com/golang/dep/cmd/dep

Use the following to update the locked versions of all dependencies
```sh
$ dep ensure -update
$ make dep-ensure
```

To add a dependency to the project, you might run
Expand Down
147 changes: 147 additions & 0 deletions GOVERNANCE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,147 @@
# CoreDNS Governance

## Principles

The CoreDNS community adheres to the following principles:

- Open: CoreDNS is open source, advertised on [our website](https://coredns.io/community).
- Welcoming and respectful: See [Code of Conduct](CODE-OF-CONDUCT.md).
- Transparent and accessible: Changes to the CoreDNS organization, CoreDNS code repositories, and CNCF related activities (e.g. level, involvement, etc) are done in public.
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with
project objectives, scope, and design principles.

## Project Lead

The CoreDNS project has a project lead.

A project lead in CoreDNS is
a single person that has a final say in any decision concerning the CoreDNS project.

The term of the project lead is one year, with no term limit restriction.

The project lead is elected by CoreDNS maintainers
according to an individual's technical merit to CoreDNS project.

The current project lead is identified in the top level [OWNERS](OWNERS) file with the string
`project lead` and the term behind the name.


## Expectations from Maintainers

Every one carries water...

Making a community work requires input/effort from everyone. Maintainers should actively
participate in Pull Request reviews. Maintainers are expected to respond to assigned Pull Requests
in a *reasonable* time frame, either providing insights, or assign the Pull Requests to other
maintainers.

Every Maintainer is listed in the top-level [OWNERS](https://github.com/coredns/coredns/blob/master/OWNERS)
file, with their Github handle and a possibly obfuscated email address. Everyone in the
`approvers` list is a Maintainer.

A Maintainer is also listed in a plugin specific OWNERS file.

A Maintainer should be a member of `maintainers@coredns.io`, although this is not a hard requirement.

## Becoming a Maintainer

On successful merge of a significant pull request any current maintainer can reach
to the author behind the pull request and ask them if they are willing to become a CoreDNS
maintainer. The email of the new maintainer invitation should be cc'ed to `maintainers@coredns.io`
as part of the process.

## Changes in Maintainership

If a Maintainer feels she/he can not fulfill the "Expectations from Maintainers", they are free to
step down.

The CoreDNS organization will never forcefully remove a current Maintainer, unless a maintainer
fails to meet the principles of CoreDNS community,
or adhere to the [Code of Conduct](CODE-OF-CONDUCT.md).

## Changes in Project Lead

Changes in project lead or term is initiated by opening a github PR.

Anyone from CoreDNS community can vote on the PR with either +1 or -1.

Only the following votes are binding:
1) Any maintainer that has been listed in the top-level [OWNERS](OWNERS) file before the PR is opened.
2) Any maintainer from an organization may cast the vote for that organization. However, no organization
should have more binding votes than 1/5 of the total number of maintainers defined in 1).

The PR should only be opened no earlier than 6 weeks before the end of the project lead's term.
The PR should be kept open for no less than 4 weeks. The PR can only be merged after the end of the
last project lead's term, with more +1 than -1 in the binding votes.

When there are conflicting PRs about changes in project lead, the PR with the most binding +1 votes is merged.

The project lead can volunteer to step down.

## Changes in Project Governance

Changes in project governance (GOVERNANCE.md) could be initiated by opening a github PR.
The PR should only be opened no earlier than 6 weeks before the end of the project lead's term.
The PR should be kept open for no less than 4 weeks. The PR can only be merged follow the same
voting process as in `Changes in Project Lead`.

## Decision making process

Decisions are build on consensus between maintainers.
Proposals and ideas can either be submitted for agreement via a github issue or PR,
or by sending an email to `maintainers@coredns.io`.

In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved.
If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background
on the issue, but not involved in the conflict) to intercede.
If a dispute still cannot be decided, the project lead has the final say to decide an issue.

Decision making process should be transparent to adhere to
the principles of CoreDNS project.

All proposals, ideas, and decisions by maintainers or the project lead
should either be part of a github issue or PR, or be sent to `maintainers@coredns.io`.

## Github Project Administration

The __coredns__ GitHub project maintainers team reflects the list of Maintainers.

## Other Projects

The CoreDNS organization is open to receive new sub-projects under its umbrella. To accept a project
into the __CoreDNS__ organization, it has to meet the following criteria:

- Must be licensed under the terms of the Apache License v2.0
- Must be related to one or more scopes of the CoreDNS ecosystem:
- CoreDNS project artifacts (website, deployments, CI, etc)
- External plugins
- Other DNS related processing
- Must be supported by a Maintainer not associated or affiliated with the author(s) of the sub-projects

The submission process starts as a Pull Request or Issue on the
[coredns/coredns](https://github.com/coredns/coredns) repository with the required information
mentioned above. Once a project is accepted, it's considered a __CNCF sub-project under the umbrella
of CoreDNS__.

## New Plugins

The CoreDNS is open to receive new plugins as part of the CoreDNS repo. The submission process
is the same as a Pull Request submission. Unlike small Pull Requests though, a new plugin submission
should only be approved by a maintainer not associated or affiliated with the author(s) of the
plugin.

## CoreDNS and CNCF

CoreDNS is a CNCF project. As such, CoreDNS might be involved in CNCF (or other CNCF projects) related
marketing, events, or activities. Any maintainer could help driving the CoreDNS involvement, as long as
she/he sends email to `maintainers@coredns.io` (or create a GitHub Pull Request) to call for participation
from other maintainers. The `Call for Participation` should be kept open for no less than a week if time
permits, or a _reasonable_ time frame to allow maintainers to have a chance to volunteer.

## Code of Conduct

The [CoreDNS Code of Conduct](CODE-OF-CONDUCT.md) is aligned with the CNCF Code of Conduct.

## Credits

Sections of this documents have been borrowed from [Fluentd](https://github.com/fluent/fluentd/blob/master/GOVERNANCE.md) and [Envoy](https://github.com/envoyproxy/envoy/blob/master/GOVERNANCE.md) projects.

0 comments on commit 30221b1

Please sign in to comment.