Skip to content
This repository has been archived by the owner on Oct 21, 2020. It is now read-only.

Make nfs-client ARM deployment consistent with regular deployment. #1090

Merged
merged 1 commit into from
Feb 12, 2019
Merged

Make nfs-client ARM deployment consistent with regular deployment. #1090

merged 1 commit into from
Feb 12, 2019

Conversation

geerlingguy
Copy link
Contributor

@geerlingguy geerlingguy commented Dec 30, 2018

I happen to be using the nfs-client provisioner for a project which runs Kubernetes on both ARM and AMD64 platforms, so I was trying to see what differences there were in the deployment (since there's one specific for ARM).

A diff showed a number of differences, but it seems that they are probably just the result of the two manifests getting out of sync (especially evidenced by the fact that the ARM manifest uses the deprecated serviceAccount instead of serviceAccountName).

I've made it so the ARM manifest matches the normal one; the only difference is the addition of the -arm to the end of the image name (which I've preserved).

Merging this PR will help people be able to see the exact, (currently) single difference between the templates to help them template the manifest or just to understand what's different.

I'm not sure what 'ifs' is, but I figure it's better to be consistent with the primary deployment manifest than have something that makes sense to me :)

@k8s-ci-robot
Copy link
Contributor

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.


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. I understand the commands that are listed here.

@k8s-ci-robot k8s-ci-robot added cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Dec 30, 2018
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Dec 30, 2018
@geerlingguy
Copy link
Contributor Author

I have signed the contributor's agreement.

@wongma7
Copy link
Contributor

wongma7 commented Feb 12, 2019

/lgtm
/approve
thank you. i think "ifs" is just an example directory, but agree let's be consistent to avoid confusion

@k8s-ci-robot k8s-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 12, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: 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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 12, 2019
@k8s-ci-robot k8s-ci-robot merged commit dca6c41 into kubernetes-retired:master Feb 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm Indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants