Meshery: [mesheryctl] [child] Create `mesheryctl exp preflight` to verify environment readiness for a Meshery deloyment

[navendu-pottekkat]

Refer epic #1754 for more info.

Refer the mesheryctl Command Tracker for current status of mesheryctl.

Desired Behavior

mesheryctl exp preflight command should be added which verifies the presence of dependencies and overall environment readiness for a Meshery deployment.

➜  ~ mesheryctl exp preflight

Docker
--------------
√ Docker is running
√ docker-compose is available

Kubernetes API
--------------
√ can initialize the client
√ can query the Kubernetes API
√ has required level of privileges

Kubernetes Version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

Acceptance Tests

• [ ] Users may or may not be installing to Docker, so failure of Docker being available should only be shown as a warning.
• [ ] Meshery requires "ClusterAdmin" role in order to be able to provide and manage service meshes. This check should verify that the Meshery ServiceAccount has the "ClusterAdmin" role assigned.

Future

mesheryctl exp preflight will be moved to mesheryctl system preflight and mesheryctl system check --preflight.

---

Contributor Guide

• mesheryctl Contributing Guide
• Beginner's guide to contributing to Meshery and mesheryctl
• mesheryctl Command Tracker
• Meshery CLI Commands and Documentation

[navendu-pottekkat]

@piyushsingariya FYI

[piyushsingariya]

Hey @navendu-pottekkat can you drop some references to be sure about how to make this from scratch?
Also, I researched and couldn't found any solid way to check about the docker part, so if you have any clue about that too it would be helpful.

[navendu-pottekkat]

We kind of do the docker checks in the preReqCheck function in the helpers.go file... I guess this would only include that... We do not need to check anything else right @leecalcote ?

[leecalcote]

Gents, the milestone (version) for this issue is set for v0.9.0. If we can complete this before that release, that would be great. We would need to have completed the other functions schedule in the milestones in v0.6, v0.7, v0.8 first, though (see the roadmap.md in the root folder of this repo).

I noted this in Slack and will record here for posterity: This issue (and its parent issue) large in nature and will require a written design spec before it is scheduled for implementation. For now, I’m unassigning the issue, so that we can focus on v0.6.0 issues.