Project: Project Calico (Runtime / Cloud Native Network)
File: README.md

This directory is used for generating CustomResourceDefinition resources to install into a Kubernetes cluster. Calico APIs that are backed using CRDs should be added here so that auto-generation picks up the API. See other structs in this directory as an example. Once added, run `make gen-crds` in the root of this repository to update the custom resource definition yamls. Then, once merged, use those yamls to update the CRDs served from https://github.com/projectcalico/calico y a large factor. Since Typha can filter out updates that are not relevant to Felix, it also reduces Felix's CPU usage. In a high-scale (100+ node) Kubernetes cluster, this is essential because the number of updates generated by the API server scales with the number of nodes. We recommend always using Typha when you are using the Kubernetes API datastore. However, Typha is strictly necessary when you are using the Kubernetes API datastore with a cluster greater than 50 nodes. Typha is generally not required for Calico deployments using an etcdv3 datastore directly. Follow the "more than 50 nodes" section in the . The best place to ask a question or get help from the community is the . We also have . is the company behind Project Calico and is responsible for the ongoing management of the project. However, it is open to any members of the community individuals or organizations to get involved and contribute code. Thanks for thinking about contributing to Project Calico! The success of an open source project is entirely down to the efforts of its contributors, so we do genuinely want to thank you for even thinking of contributing. Before you do so, you should check out our contributing guidelines in the `CONTRIBUTING.md` file, to make sure it's as easy as possible for us to accept your contribution. Typha mostly uses Docker for builds. We develop on Ubuntu 16.04 but other Linux distributions should work (there are known Makefile that prevent building on OS X). To build Typha, you will need: A suitable linux box. To check out the code into your GOPATH. Docker >=1.12 GNU make. Then, as a one-off, run ```bash make update-tools ``` which will install a couple more go tools that we haven't yet containerized. Then, to build the calico-typha binary: ```bash make build ``` or, the `calico/typha` docker image: ```bash make image ``` To run all the UTs: ```bash make ut ``` To start a `ginkgo watch`, which will re-run the relevant UTs as you update files: ```bash make ut-watch ``` To get coverage stats: ```bash make cover-report ``` or ```bash make cover-browser ``` If you want to be able to run unit tests for specific packages for more iterative development, you'll need to install GNU make go >=1.7 then run `make update-tools` to install ginkgo, which is the test tool used to run Typha's unit tests. There are several ways to run ginkgo. One option is to change directory to the package you want to test, then run `ginkgo`. Another is to use ginkgo's watch feature to monitor files for changes: ```bash cd go ginkgo watch -r ``` Ginkgo will re-run tests as files are modified and saved. After building the docker image (see above), you can run Typha and log to screen with, for example: ```bash docker run --privileged --net=host -e TYPHA_LOGSEVERITYSCREEN=INFO calico/typha ``` Calico binaries are licensed under the , with the exception of some . Calico imports packages with a number of apache-compatible licenses. For more information, see . In addition, the base container image contains pre-packaged software with a variety of licenses.