├── .gitignore ├── MAINTAINERS ├── .gitattributes ├── NOTICE ├── user-data.sample ├── DCO ├── CONTRIBUTING.md ├── config.rb.sample ├── README.md ├── Vagrantfile └── LICENSE /.gitignore: -------------------------------------------------------------------------------- 1 | .vagrant/ 2 | log/ 3 | user-data 4 | config.rb 5 | -------------------------------------------------------------------------------- /MAINTAINERS: -------------------------------------------------------------------------------- 1 | Jon Boulle (@jonboulle) 2 | Brian Waldon (@bcwaldon) 3 | -------------------------------------------------------------------------------- /.gitattributes: -------------------------------------------------------------------------------- 1 | # Detect text files automatically 2 | * text=auto 3 | 4 | # Force Unix-style line endings on these files 5 | user-data* text eol=lf 6 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | CoreOS Project 2 | Copyright 2014 CoreOS, Inc 3 | 4 | This product includes software developed at CoreOS, Inc. 5 | (http://www.coreos.com/). 6 | -------------------------------------------------------------------------------- /user-data.sample: -------------------------------------------------------------------------------- 1 | #cloud-config 2 | 3 | coreos: 4 | etcd2: 5 | #generate a new token for each unique cluster from https://discovery.etcd.io/new 6 | #discovery: https://discovery.etcd.io/ 7 | # multi-region and multi-cloud deployments need to use $public_ipv4 8 | advertise-client-urls: http://$public_ipv4:2379 9 | initial-advertise-peer-urls: http://$private_ipv4:2380 10 | # listen on both the official ports and the legacy ports 11 | # legacy ports can be omitted if your application doesn't depend on them 12 | listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:4001 13 | listen-peer-urls: http://$private_ipv4:2380,http://$private_ipv4:7001 14 | fleet: 15 | public-ip: $public_ipv4 16 | flannel: 17 | interface: $public_ipv4 18 | units: 19 | - name: etcd2.service 20 | command: start 21 | - name: fleet.service 22 | command: start 23 | - name: flanneld.service 24 | drop-ins: 25 | - name: 50-network-config.conf 26 | content: | 27 | [Service] 28 | ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }' 29 | command: start 30 | - name: docker-tcp.socket 31 | command: start 32 | enable: true 33 | content: | 34 | [Unit] 35 | Description=Docker Socket for the API 36 | 37 | [Socket] 38 | ListenStream=2375 39 | Service=docker.service 40 | BindIPv6Only=both 41 | 42 | [Install] 43 | WantedBy=sockets.target 44 | -------------------------------------------------------------------------------- /DCO: -------------------------------------------------------------------------------- 1 | Developer Certificate of Origin 2 | Version 1.1 3 | 4 | Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 5 | 660 York Street, Suite 102, 6 | San Francisco, CA 94110 USA 7 | 8 | Everyone is permitted to copy and distribute verbatim copies of this 9 | license document, but changing it is not allowed. 10 | 11 | 12 | Developer's Certificate of Origin 1.1 13 | 14 | By making a contribution to this project, I certify that: 15 | 16 | (a) The contribution was created in whole or in part by me and I 17 | have the right to submit it under the open source license 18 | indicated in the file; or 19 | 20 | (b) The contribution is based upon previous work that, to the best 21 | of my knowledge, is covered under an appropriate open source 22 | license and I have the right under that license to submit that 23 | work with modifications, whether created in whole or in part 24 | by me, under the same open source license (unless I am 25 | permitted to submit under a different license), as indicated 26 | in the file; or 27 | 28 | (c) The contribution was provided directly to me by some other 29 | person who certified (a), (b) or (c) and I have not modified 30 | it. 31 | 32 | (d) I understand and agree that this project and the contribution 33 | are public and that a record of the contribution (including all 34 | personal information I submit with it, including my sign-off) is 35 | maintained indefinitely and may be redistributed consistent with 36 | this project or the open source license(s) involved. 37 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | CoreOS projects are [Apache 2.0 licensed](LICENSE) and accept contributions via 4 | GitHub pull requests. This document outlines some of the conventions on 5 | development workflow, commit message formatting, contact points and other 6 | resources to make it easier to get your contribution accepted. 7 | 8 | # Certificate of Origin 9 | 10 | By contributing to this project you agree to the Developer Certificate of 11 | Origin (DCO). This document was created by the Linux Kernel community and is a 12 | simple statement that you, as a contributor, have the legal right to make the 13 | contribution. See the [DCO](DCO) file for details. 14 | 15 | # Email and Chat 16 | 17 | The project currently uses the general CoreOS email list and IRC channel: 18 | - Email: [coreos-dev](https://groups.google.com/forum/#!forum/coreos-dev) 19 | - IRC: #[coreos](irc://irc.freenode.org:6667/#coreos) IRC channel on freenode.org 20 | 21 | Please avoid emailing maintainers found in the MAINTAINERS file directly. They 22 | are very busy and read the mailing lists. 23 | 24 | ## Getting Started 25 | 26 | - Fork the repository on GitHub 27 | - Read the [README](README.md) for build and test instructions 28 | - Play with the project, submit bugs, submit patches! 29 | 30 | ## Contribution Flow 31 | 32 | This is a rough outline of what a contributor's workflow looks like: 33 | 34 | - Create a topic branch from where you want to base your work (usually master). 35 | - Make commits of logical units. 36 | - Make sure your commit messages are in the proper format (see below). 37 | - Push your changes to a topic branch in your fork of the repository. 38 | - Make sure the tests pass, and add any new tests as appropriate. 39 | - Submit a pull request to the original repository. 40 | 41 | Thanks for your contributions! 42 | 43 | ### Format of the Commit Message 44 | 45 | We follow a rough convention for commit messages that is designed to answer two 46 | questions: what changed and why. The subject line should feature the what and 47 | the body of the commit should describe the why. 48 | 49 | ``` 50 | scripts: add the test-cluster command 51 | 52 | this uses tmux to setup a test cluster that you can easily kill and 53 | start for debugging. 54 | 55 | Fixes #38 56 | ``` 57 | 58 | The format can be described more formally as follows: 59 | 60 | ``` 61 | : 62 | 63 | 64 | 65 |