-
Notifications
You must be signed in to change notification settings - Fork 85
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
Helm chart 1.0 #194
Helm chart 1.0 #194
Conversation
e94dd40
to
295421f
Compare
/test pull-aws-fsx-csi-driver-e2e |
/test pull-aws-fsx-csi-driver-e2e |
• Failure [604.565 seconds] /retest |
replicas: {{ .Values.controller.replicaCount }} | ||
selector: | ||
matchLabels: | ||
app: fsx-csi-controller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this will cause upgrade issues since matchLabels
is immutable. It looks like maybe it is being added to ensure that is continues to be included on the kustomize manifests. If that is the case, I would move if from here to an else
in the selectorLabels helper template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll test out the upgrade case, since I am bumping major version of helm chart I am not sure without testing how helm deals with it. I just cargo culted how ebs does it TBH: https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/charts/aws-ebs-csi-driver/templates/controller.yaml#L12
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change is safe because helm somehow knows to delete and recreate the deployment which also deletes and recreates the pods..
- I installed the current helm chart v0.1.0 using the README command
a. (I manually edited the deployment and daemonset to have hostNetwork and to point to image 0.4.0 instead of 0.3.0 because they were crashlooping as I have instance metadata disabled) - I ran
helm upgrade --install aws-fsx-csi-driver ./charts/aws-fsx-csi-driver
- helm recreated the deployment
k get deployment
NAME READY UP-TO-DATE AVAILABLE AGE
fsx-csi-controller 1/1 1 1 57s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't notice that the name of the deployment was changing. That explains the delete and create behavior.
spec: | ||
replicas: 2 | ||
selector: | ||
matchLabels: | ||
app: fsx-csi-controller | ||
app.kubernetes.io/name: aws-fsx-csi-driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this is a concern but this will need intervention on a new apply since matchLabels are immutable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may still be the case since the deployment name isn't changing. Did you test the upgrade with kustomize?
spec: | ||
selector: | ||
matchLabels: | ||
app: fsx-csi-node | ||
app.kubernetes.io/name: aws-fsx-csi-driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if this is a concern but this will need intervention on a new apply since matchLabels are immutable.
I resolved comments I think have been addressed by latest 5 commits, the one open question is how to deal with matchLabels which I will test out. appreciate the thorough review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know what you think about trying to validate that the service account exists. Did you test the kustomize based upgrade? It looks like the names of those resources are changing. I haven't used kustomize but based on past kubectl behavior it seems like the match labels could be an issue.
I would seem my comment about the validation is part of a resolved conversation so you might have to look for it :(
annotations: | ||
{{- toYaml . | nindent 4 }} | ||
{{- end }} | ||
{{- end }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I would just add the annotation to controller.serviceAccount.annotations
, which is what I did for the EBS chart. I do, however, see what you are saying about some users potentially wanting to use a pre-existing service account.
If this chart isn't creating a service account and therefore expects that one already exists it might be worth using the lookup function to validate that it does exist and fail if it doesn't.
https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function
spec: | ||
replicas: 2 | ||
selector: | ||
matchLabels: | ||
app: fsx-csi-controller | ||
app.kubernetes.io/name: aws-fsx-csi-driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may still be the case since the deployment name isn't changing. Did you test the upgrade with kustomize?
…r own serviceAccount
latest commit gives lookup function a try. it seems to work but the error message is quite ugly, I'm not sure if I called
|
the kustomize upgrade indeed failed to apply. however it worked with --force, I suppose I can add this to the readme installation instructions as upgrade note, same as for helm (working on that now) |
Looks like a correct use of fail. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: krmichel, nckturner, wongma7 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 |
Is this a bug fix or adding new feature? fixes #191
What is this PR about? / Why do we need it?
What testing is done?