The following dependencies must be installed on your system before you can build the installer.
sudo dnf install gcc-c++ zip
If you need support for libvirt destroy, you should also install libvirt-devel
.
You can follow the official Go Installation Doc to install a compatible go version.
We follow a hard flattening approach; i.e. direct and inherited dependencies are installed in the base vendor/
.
Dependencies are managed with Go Modules but committed directly to the repository.
- Add or update a dependency with
go get <dependency>@<version>
. - If you want to use a fork of a project or ensure that a dependency is not updated even when another dependency requires a newer version of it, manually add a replace directive in the go.mod file.
- Run
go mod tidy
to tidygo.mod
and updatego.sum
, then commit the changes. - Run
go mod vendor
to re-vendor and then commit updated vendored code separately.
If your vendor bump touched github.com/openshift/api
, also run go generate ./pkg/types/installconfig.go
to update data/data/install.openshift.io_installconfigs.yaml
.
This guide is a great source to learn more about using go mod
.
For the sake of your fellow reviewers, commit vendored code separately from any other changes.
The installer uses Cluster API controllers to provision the cluster insfrastructure (more details here). Each provider are vendored to cluster-api/providers/<provider-name>
(e.g. cluster-api/providers/aws
for AWS platform).
Whenever there are changes in the CAPI provider projects that need to be available to the installer, we need to bump the provider version in the installer project. The following describes the process to do so. We will use AWS provider (CAPA) as an example, but other providers should follow the same steps.
We need to set the version of CAPI provider to the revisions with the changes in the provider go.mod
.
# At the project root (i.e. <path>/installer)
cd cluster-api/providers/aws/
# For example:
# - With commit ref: go get sigs.k8s.io/cluster-api-provider-aws/v2@17a09f591
# - With a released version, go get sigs.k8s.io/cluster-api-provider-aws/[email protected]
go get sigs.k8s.io/cluster-api-provider-aws/v2@<revision>
go mod tidy && go mod vendor
Important: If CAPI provider project has a replace
block, we need to make sure provider go.mod
matches that. For example, the CAPA go.mod
and provider go.mod
must match if any.
We need to also set the same version of CAPI provider in the installer top-level go.mod
.
# At the project root (i.e. <path>/installer)
# For example:
# - With commit ref: go get sigs.k8s.io/cluster-api-provider-aws/v2@17a09f591
# - With a released version, go get sigs.k8s.io/cluster-api-provider-aws/[email protected]
go get sigs.k8s.io/cluster-api-provider-aws/v2@<revision>
go mod tidy && go mod vendor
When bumping version of the CAPI provider, some infrastructure CRDs might be updated and we need to ensure the installer is aware of that as it keeps a copy of the CRD in directory data/data/cluster-api/
.
First, clone the upstream CAPI provider project.
# We need to have a copy of the CAPI provider project if not yet
git clone [email protected]:kubernetes-sigs/cluster-api-provider-aws.git
cd cluster-api-provider-aws
# Checkout the revision with changes
git fetch origin && git checkout <revision>
Next, generate the CRD manifest. The manifest will be available in out/infrastructure-components.yaml
. We then copy it over to the installer project's corresponding infrastructure manifest.
make release-manifests
cp out/infrastructure-components.yaml <path-to>/installer/data/data/cluster-api/aws-infrastructure-components.yaml
Important: If using a released version of CAPI provider, the CRD is available for downloading from the release page.