Skip to content
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

Add methods to fetch upgrader image from bundle #7283

Merged
merged 1 commit into from
Jan 18, 2024

Conversation

taneyland
Copy link
Member

@taneyland taneyland commented Jan 10, 2024

Issue #, if available:

Description of changes:
The eks-a controller will be responsible for creating the custom CP/MD upgrade resources for in-place upgrades. We need a way to fetch the upgrader image from the bundle so this adds methods that will be used in the controller to pull the bundle and fetch the images. The images will be stored in a config map. This upgrader config map will then be fetched by the node upgrader when the image is needed.

ConfigMap:

apiVersion: v1
data:
  v1.25.16-eks-1-25-29: public.ecr.aws/l0g8r8j6/aws/upgrader:v1-25-29-eks-a-v0.0.0-dev-build.8103
  v1.26.11-eks-1-26-25: public.ecr.aws/l0g8r8j6/aws/upgrader:v1-26-25-eks-a-v0.0.0-dev-build.8103
  v1.27.8-eks-1-27-19: public.ecr.aws/l0g8r8j6/aws/upgrader:v1-27-19-eks-a-v0.0.0-dev-build.8103
  v1.28.4-eks-1-28-12: public.ecr.aws/l0g8r8j6/aws/upgrader:v1-28-12-eks-a-v0.0.0-dev-build.8103
  v1.29.0-eks-1-29-1: public.ecr.aws/l0g8r8j6/aws/upgrader:v1-29-1-eks-a-v0.0.0-dev-build.8103
kind: ConfigMap

Testing (if applicable):
performed in-place upgrade with image from bundle

Documentation added/planned (if applicable):

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@eks-distro-bot eks-distro-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 10, 2024
Copy link

codecov bot commented Jan 10, 2024

Codecov Report

Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (413ea04) 71.65% compared to head (0d2b99b) 71.73%.
Report is 10 commits behind head on main.

Files Patch % Lines
controllers/nodeupgrade_controller.go 35.71% 6 Missing and 3 partials ⚠️
pkg/clustermanager/cluster_manager.go 89.18% 3 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7283      +/-   ##
==========================================
+ Coverage   71.65%   71.73%   +0.07%     
==========================================
  Files         556      559       +3     
  Lines       43185    43416     +231     
==========================================
+ Hits        30944    31144     +200     
- Misses      10532    10553      +21     
- Partials     1709     1719      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@taneyland taneyland force-pushed the fetch_from_bundle branch 7 times, most recently from 007680d to aa260aa Compare January 16, 2024 23:28
@@ -168,14 +166,20 @@ func (r *NodeUpgradeReconciler) reconcile(ctx context.Context, log logr.Logger,
return ctrl.Result{}, nil
}

configMap := &corev1.ConfigMap{}
if err := remoteClient.Get(ctx, types.NamespacedName{Name: constants.UpgraderConfigMapName, Namespace: constants.EksaSystemNamespace}, configMap); err != nil {
Copy link
Member

@vivek-koppuru vivek-koppuru Jan 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other option is so pass in the config map from here to node upgrade object, just so that if node upgrader is run on it's own for any reason, we can pass in any config map. If we decide to mount the config map to the upgrader pod directly, then that gives us a different amount of flexibility where we can deploy the pod directly with a different config map mounted. Just some thoughts that I have to consider.

@taneyland taneyland force-pushed the fetch_from_bundle branch 3 times, most recently from c1599f2 to 72f570c Compare January 17, 2024 17:29
controllers/nodeupgrade_controller.go Outdated Show resolved Hide resolved
pkg/constants/constants.go Outdated Show resolved Hide resolved
pkg/clustermanager/cluster_manager.go Show resolved Hide resolved
if configMap.Data == nil {
return ctrl.Result{}, errors.New("upgrader config map is empty")
}
upgraderImage := configMap.Data[nodeUpgrade.Spec.KubernetesVersion]
Copy link
Member

@abhinavmpandey08 abhinavmpandey08 Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this check if configMap.Data == nil { just verifies that the configmap data is still nil but not if the configmap contains an entry for the EKS Distro/K8s version we are looking for
We can keep that but can we also add something like this?

Suggested change
upgraderImage := configMap.Data[nodeUpgrade.Spec.KubernetesVersion]
upgraderImage, ok := configMap.Data[nodeUpgrade.Spec.KubernetesVersion]
if !ok {
return ctrl.Result{}, fmt.Errorf("upgrader image corresponding to EKS Distro version %s not found in the configmp", nodeUpgrade.Spec.KubernetesVersion)
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yes. I totally agree. Thanks!

Comment on lines 1430 to 1432
if _, ok := upgraderConfigMap.Data[version]; !ok {
upgraderConfigMap.Data[version] = image
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think for this case, when a version is already in the configmap, we should override it instead of preserving the older version

Suggested change
if _, ok := upgraderConfigMap.Data[version]; !ok {
upgraderConfigMap.Data[version] = image
}
upgraderConfigMap.Data[version] = image

@abhinavmpandey08
Copy link
Member

/approve
/woof

@eks-distro-bot
Copy link
Collaborator

@abhinavmpandey08: dog image

In response to this:

/approve
/woof

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@eks-distro-bot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: abhinavmpandey08

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@taneyland taneyland merged commit 50c4621 into aws:main Jan 18, 2024
11 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved lgtm size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants