Workflow, tooling, and day-to-day development procedures for tigera/operator. For code architecture and design principles, see principles.md.
There are a few important packages to be aware of:
- Operator API definitions exist in
api/v1 - Rendering code for generating Kubernetes resources is in
pkg/render - Control/reconcile loops for each component can be found in
pkg/controller/<component> - Status reporting is in
pkg/controller/status
Tests:
- Tests for file
X.gocan be found inX_test.go. - FV tests which run against a local cluster can be found in
test/*.go.
- APIs should adhere to the Kubernetes API conventions
- When changing an API, make changes to pkg/controller/migration/convert if new configuration can be handled when migrating from a manifest-based Calico OSS install to the operator.
- Always run
make gen-filesafter API or CRD changes. This regenerates CRD manifests, deepcopy methods, and client sets. - Don't edit generated files by hand. Files in
pkg/components/andpkg/imports/crds/are regenerated by make targets. Edit the source configs instead. - After running
gen-files, verify that existing resources weren't inadvertently changed to "Namespaced".
This graph shows the dependencies between controllers. Optional dependencies are in dashed lines.
When picking changes to a release branch, you must cherry-pick the change to all release branches semantically after the target release as well. This ensures that if a user upgrades their cluster, they do not "lose" features that existed in a prior release.
See common tasks for detailed information on common dev procedures like running the code, tests, and debugging.