[lifecycle] Manage Un/Deployment of Meshery Adapters

[theBeginner86]

Notes for Reviewers

• Kubernetes
  • Able to deploy/undeploy
  • Remove OSM Adapter sub chart. (missed out in [chore] Removed OSM #8375)
• Docker
  • Able to deploy/undeploy
  • Detect running Meshery container and install adapters' containers in same network

This PR fixes #

Signed commits

• Yes, I signed my commits.

[github-actions]

[codecov]

Codecov Report

Patch coverage has no change and project coverage change: -0.04% ⚠️

Comparison is base (d02bf15) 5.20% compared to head (afe737c) 5.17%.
Report is 2 commits behind head on master.

❗ Current head afe737c differs from pull request most recent head 4a450a3. Consider uploading reports for the commit 4a450a3 to get more accurate results

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #8393      +/-   ##
=========================================
- Coverage    5.20%   5.17%   -0.04%     
=========================================
  Files         124     124              
  Lines       17664   17774     +110     
=========================================
  Hits          919     919              
- Misses      16573   16683     +110     
  Partials      172     172              

Flag	Coverage Δ
gointegrationtests	5.17% <0.00%> (-0.04%)	⬇️

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

Files Changed	Coverage Δ
server/handlers/mesh_ops_handlers.go	0.74% <ø> (ø)
server/helpers/adapters_tracker.go	0.00% <0.00%> (ø)
server/helpers/error.go	0.00% <0.00%> (ø)

... and 4 files with indirect coverage changes

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

[suhail34]

Doubt :
As you have removed adapters from docker-compose how will this thing work with mesheryctl as it uses the same docker-compose file and downloads it

[theBeginner86]

Doubt :
As you have removed adapters from docker-compose how will this thing work with mesheryctl as it uses the same docker-compose file and downloads it

You can make use of Adapter Tracker Interface. It does have the info for adapters as it's seeded on Meshery boot as env vars.
FYI: https://github.com/meshery/meshery/blob/master/server/cmd/main.go#L125

[theBeginner86]

This PR is ready.

System Flows:

1. For Docker env, performing un/deploying would create new containers (or stop and delete running containers) of each adapter. Would ensure that the new adapters are on the same Docker network as the one for Meshery container
2. For K8s env, performing un/deploying would internally use Helm with overrides for each adapter (enabled: true/false). Then on each un/deployment Helm upgrade is performed.
3. For local env, its not supported and wouldn't perform any action.

[theBeginner86]

The initial code written for this functionality is not clean would require some refactoring considering most of this functionality can be extracted into MeshKit. Like provisioning of containers or supporting multi-k8s deployment through our deployment modals.

[theBeginner86]

Looks like someone had changed this tag for meshery image. 🤔

As there is no image tag of latest for layer5/meshery image. https://hub.docker.com/r/layer5/meshery/tags?page=1&name=latest

[theBeginner86]

I have one more question.

Should we start publishing all Meshery Adapter's charts separately too?

So that users can directly do following for managing deployments of their individual adapters irrespective of Meshery deployment:
helm install meshery-istio meshery/meshery-istio

Instead of deploying them as follows:

helm pull meshery/meshery --untar
cd meshery/charts
helm install meshery-istio ./meshery-istio

The above would have no change in the current sub chart structure that we have its just that instead of referring a local charts dir we would be referring the remotely published charts.

The above would also be helpful when we would be deploying Meshery in K8s and trying to manage lifecycle of Adapters. As currently, since both Meshery and Adapters are part of the same release so during deployment/un-deployment of any adapter, the Meshery release is upgraded that leads to restart of Meshery pods. So, if Adapters charts are published separately then we can easily put them under separate release and that would not hinder Meshery pods.

[leecalcote]

I'm not opposed to it, @theBeginner86.

@AugustasV @nebula-aac @Revolyssup thoughts?

[leecalcote]

Good error messages.

[leecalcote]

Error handling of local builds that try to perform deployments works.