CNI Installer migration #2333
Labels
azure-ipam
cni
Related to CNI.
dropgz
dropgz
enhancement
exempt-stale
Keep this fresh
needs-backport
Change needs to be backported to previous release trains
release/latest
Change affects latest release train
release/1.4
Change affects v1.4 release train
work-in-progress
This is a tracking issue for the work to migrate from the single
dropgz
image to per-component-installer
images.Up until now, we have released the CNI installer image (
cni-dropgz
) as a versioned component separately from the CNI releases themselves. This has created a bit of versioning hell, as we struggle to maintain multiple release trains of the CNI (and thus CNI installer) and azure-ipam when the CNI/azure-ipam and installer version are not correlated.The proposed change is to flip the architecture of the CNI installer: treat
dropgz
as a library, and leverage it to build separate installer images for each versioned component which we need to install via container.We will migrate from the current state of:
to
Migration steps:
Build CNI installer imagesfeat: build cni installer image with cni builds #2324Build azure-ipam installer imagesfeat: build standalone azure-ipam installer image #2339Set up MCR publishing on new imagesMCR deps: bump sigs.k8s.io/controller-tools from 0.13.0 to 0.16.0 in /build/tools #2917Add MCR sovcloud syndicationMCR Add join VNET call for every AZR NC unpublish call with fixed UTs #3016Migrate pipelines to new imageschore: migrate to azure-cni and azure-ipam from dropgz-test #2372Add v1 scenario installation daemonset to AKSAKS #9774675CAPZchore: update AzCNI to new installer image kubernetes-sigs/cluster-api-provider-azure#4315dropgz-test imageschore: migrate to azure-cni and azure-ipam from dropgz-test #2372The text was updated successfully, but these errors were encountered: