-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
Comments
rbtr
added
enhancement
cni
Related to CNI.
azure-ipam
release/1.4
Change affects v1.4 release train
release/latest
Change affects latest release train
needs-backport
Change needs to be backported to previous release trains
dropgz
dropgz
work-in-progress
labels
Oct 27, 2023
10 tasks
10 tasks
4 tasks
4 tasks
This was referenced Nov 22, 2023
rbtr
added
exempt-stale
Keep this fresh
and removed
stale
Stale due to inactivity.
labels
Jan 4, 2024
4 tasks
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 #2917Add MCR sovcloud syndicationMCR #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: