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

Migrate from plain manifests to helm charts in mesheryctl #4318

Merged
merged 4 commits into from Oct 6, 2021

Conversation

panyuenlau
Copy link
Member

@panyuenlau panyuenlau commented Oct 3, 2021

Description

This PR fixes the helm chart part of #4103
(The mesheryctl changes will be included in another PR to separate from the helm chart changes)

Notes for Reviewers
The current PR only fixes the existing issues related to serviceAccount, clusterRole, and clsuterRoleBInding within the helm charts, I've tested the basic installations for each adapter but need some help on testing the other functionalities

Note: all the adapters should just use the service account meshery-server to have the permission to perform certain operations, but some of the adapters had their own service accounts created in the helm charts

Signed commits

  • Yes, I signed my commits.

>TODO: will be adding changes to the mesheryctl implementation to use the helm chart after making sure the charts are functioning properly

Signed-off-by: Pan Yuen Lau <panyuenlau@gmail.com>
Signed-off-by: Pan Yuen Lau <panyuenlau@gmail.com>
@panyuenlau panyuenlau changed the title Mesheryctl helm Migrate from plain manifests to helm charts in mesheryctl Oct 3, 2021
@codecov-commenter
Copy link

codecov-commenter commented Oct 3, 2021

Codecov Report

Merging #4318 (e4c6cd7) into master (8c224b9) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #4318   +/-   ##
=======================================
  Coverage   21.36%   21.36%           
=======================================
  Files          59       59           
  Lines        5046     5046           
=======================================
  Hits         1078     1078           
  Misses       3653     3653           
  Partials      315      315           
Flag Coverage Δ
e2etests ∅ <ø> (?)
unittests 21.36% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8c224b9...e4c6cd7. Read the comment docs.

@pottekkat pottekkat requested review from a team October 3, 2021 17:19
Copy link
Member

@Aisuko Aisuko left a comment

Choose a reason for hiding this comment

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

Thanks, @panyuenlau, so cleanly work. Please add the code comment to the ClusterRole in order to clearly describe the permission we need to apply.

- meshery.layer5.io
resources:
- brokers/status
verbs:
Copy link
Member

Choose a reason for hiding this comment

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

Please give any code comment for apiGroups' verbs if could what I mean we should sure which permissions we need to get.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, should the templates/NOTES.txt be modified to capture the recent changes?

Copy link
Member Author

Choose a reason for hiding this comment

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

@Aisuko @hexxdump TBH, I am not familiar enough with the system to give a good explanation on why we need those permissions for the cluster role, I made the changes just based on the plain yaml manifests that we're currently using... reference: https://github.com/meshery/meshery-operator/blob/master/config/manifests/default.yaml#L273-L288

Copy link
Member

Choose a reason for hiding this comment

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

Good discussion. Given that the scope of these verbs is restricted to meshery.layer5.io resource groups, we shouldn't see any pushback from users given that the Meshery Operator should have full control over the lifecycle of its custom controllers.

@Aisuko
Copy link
Member

Aisuko commented Oct 4, 2021

Hi, @navendu-pottekkat, I remember the CI check was only triggered by the specific folder, right? Is that strategy keep working well? I saw there trigger so many CI includes UI, DOC, golangci-lint. please help us check the strategy if possible.

@@ -11,10 +11,10 @@ image:
env: {}

probe:
#TODO: Need to confirm the health check path of meshery.
#TODO: Need to confirm the health check path of meshery.
Copy link
Contributor

Choose a reason for hiding this comment

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

@navendu-pottekkat what's Meshery's health check path?

Copy link
Contributor

Choose a reason for hiding this comment

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

There is no specific health-check path but we can try hitting the version endpoint to get the surety that meshery is running properly.

Copy link
Member

Choose a reason for hiding this comment

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

A good item to create a new issue for follow up here.

@hexxdump
Copy link
Contributor

hexxdump commented Oct 4, 2021

Description

This PR fixes #4103

Notes for Reviewers The current PR only fixes the existing issues related to serviceAccount, clusterRole, and clsuterRoleBInding within the helm charts, I've tested the basic installations for each adapter but need some help on testing the other functionalities

Note: all the adapters should just use the service account meshery-server to have the permission to perform certain operations, but some of the adapters had their own service accounts created in the helm charts

Signed commits

  • Yes, I signed my commits.

TODO: will be adding changes to the mesheryctl implementation to use the helm chart after making sure the charts are functioning properly

I feel, the mesheryctl changes(to move away from manifests) should be handled through a separate PR

meshery-nginx-sm:
enabled: true
fullnameOverride: meshery-nginx-sm

Copy link
Contributor

Choose a reason for hiding this comment

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

@leecalcote, we do not have helm charts for meshery-nsm, meshery-tanzu-sm and meshery-app-mesh yet. Is there some limitation for these service meshes?

Copy link
Member Author

@panyuenlau panyuenlau Oct 6, 2021

Choose a reason for hiding this comment

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

@hexxdump I believe we do have the meshery-nsm helm chart: https://github.com/meshery/meshery/tree/master/install/kubernetes/helm/meshery/charts/meshery-nsm

But not the other two that you mentioned

Copy link
Member

Choose a reason for hiding this comment

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

Good question and answer. The other two adapters are alpha stage adapters, and so, charts haven't been created yet. We can go ahead and create those charts now, so long as we don't include their deployment by default.

@panyuenlau
Copy link
Member Author

Description
This PR fixes #4103
Notes for Reviewers The current PR only fixes the existing issues related to serviceAccount, clusterRole, and clsuterRoleBInding within the helm charts, I've tested the basic installations for each adapter but need some help on testing the other functionalities

Note: all the adapters should just use the service account meshery-server to have the permission to perform certain operations, but some of the adapters had their own service accounts created in the helm charts

Signed commits

  • Yes, I signed my commits.

TODO: will be adding changes to the mesheryctl implementation to use the helm chart after making sure the charts are functioning properly

I feel, the mesheryctl changes(to move away from manifests) should be handled through a separate PR

I agree, since separating the two into different PRs would help us identify potential issues more easily

@leecalcote leecalcote added area/devops area/lifecycle Lifecycle management (install, uninstall, configure) related labels Oct 5, 2021
…level chart

Signed-off-by: Pan Yuen Lau <panyuenlau@gmail.com>
@panyuenlau panyuenlau requested a review from Aisuko October 6, 2021 02:06
@panyuenlau panyuenlau marked this pull request as ready for review October 6, 2021 12:58
Copy link
Member

@leecalcote leecalcote left a comment

Choose a reason for hiding this comment

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

@panyuenlau confirming: with this update, two service accounts will be created: meshery-server and meshery-operator?

@@ -49,7 +52,7 @@ securityContext: {}
service:
type: ClusterIP
port: 10010
targetPOrt: 10010
Copy link
Member

Choose a reason for hiding this comment

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

Yikes!

- meshery.layer5.io
resources:
- brokers/status
verbs:
Copy link
Member

Choose a reason for hiding this comment

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

Good discussion. Given that the scope of these verbs is restricted to meshery.layer5.io resource groups, we shouldn't see any pushback from users given that the Meshery Operator should have full control over the lifecycle of its custom controllers.

Copy link
Member

@leecalcote leecalcote left a comment

Choose a reason for hiding this comment

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

Unless I've missed something, this is a great step forward.

@leecalcote leecalcote merged commit 64038fe into meshery:master Oct 6, 2021
@panyuenlau
Copy link
Member Author

panyuenlau commented Oct 6, 2021

@panyuenlau confirming: with this update, two service accounts will be created: meshery-server and meshery-operator?

@leecalcote correct, the meshery and all the adapters should share the meshery-server service account in order to use the UI to manage the corresponding service mesh; and meshery-operator service account is for the meshery-operator pod

@panyuenlau panyuenlau deleted the mesheryctl-helm branch October 8, 2021 02:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devops area/lifecycle Lifecycle management (install, uninstall, configure) related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants