Multi-Context Support

[tangledbytes]

Description

This PR adds support for multiple contexts in meshery. This is a critical PR, has a huge surface area for bugs to pop up and also changes the way sections of meshery server interact with kubernetes cluster.

Details:

1. This PR changes the "unit" of cluster communication from a kubeconfig file to per-user per-cluster kubernetes contexts. Following are a few results of such changes:
   • Any number of kubconfigs can be uploaded to meshery server.
   • Each user gets to have any number of contexts for a meshery instance
   • "Current context" for each user can differ.
   • Long running processes will not be impacted with future context changes of the user.
   • Potential issues (that the author can/could think of):
     • What happens when there is no context?
       • In-cluster deployments - A context is created from the mounted secrets
       • No kubeconfig - no context is created and no handler is created. This does not stops the http flow though, each handler can choose to accept or reject the request. This behaviour was chosen so as to keep meshery working even if no kubernetes cluster is reachable.
     • What if a current-context already exists and a new kubeconfig is uploaded with another "current-context"?
       • Depends on the provider. At the moment, both None as well as Meshery Cloud will ignore the "current-context" claim of the new context. If the user wants to switch the context, they can do so via the API/UI.
     • What if a "current-context" is deleted? Will there be a new current-context chosen?
       • No
     • Who can see my contexts?
       • Anyone who has access to the meshery instance.
     • Who can modify my contexts?
       • No one. Contexts are immutable.They can be deleted but only by the "owner" of the context.
     • What happens if two users invoke the same API with different contexts?
       • Both of their execution will be isolated. There are no global handlers in meshery server.
     • What happens if two users invoke different Meshery APIs under the same context?
       • Meshery operations remain isolated.
     • What happens if I delete all of my contexts?
       • You are back to the initial stage. Meshery will try to read kubeconfig and find your current-context.
       • Other users will not see those contexts anymore.
       • Inflight operations (yours or those of other users) proceed unaffected and conclude as requested.
     • What happens if the owner of the context has their user account deleted?
       • Context remains. Created_By value goes to nil.
2. Tests done:
   • On local system:
     • With one cluster in kubeconfig:
       • Startup meshery
       • Ping cluster
       • Check details of context in settings
       • Deploy meshery operator
       • Delete current context
       • Deploy service mesh (interact with adapter)
       • Run performance test
     • With two clusters in kubeconfig:
       • Startup meshery
       • Ping each cluster
       • Change context from the UI
       • Check details of context in the settings
       • Delete current context
       • Delete all contexts
       • Deploy meshery operator
       • Deploy service mesh (interact with adapter)
       • Run performance test

Notes for Reviewers
Although this PR is functional (to the best of my knowledge) but still it should not be merged. Some cleanup items are left to do like:

1. Use meshkit errors

Signed commits

• Yes, I signed my commits.

[codecov-commenter]

Codecov Report

Merging #4218 (9ab1e2d) into master (22906f4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4218   +/-   ##
=======================================
  Coverage   32.12%   32.12%           
=======================================
  Files          62       62           
  Lines        5252     5252           
=======================================
  Hits         1687     1687           
  Misses       3140     3140           
  Partials      425      425           

Flag	Coverage Δ
gointegrationtests	10.75% <ø> (ø)
unittests	24.06% <ø> (ø)

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 bfb387d...9ab1e2d. Read the comment docs.

[tangledbytes]

Reviewers,
@sudo-NithishKarthik, this PR effects UI. Some changes has been done while some still needs to be done. Kindly take a look at it.
@navendu-pottekkat, @piyushsingariya this PR changes the behaviour of some APIs and removes some. This may have implications on mesheryctl. Please look out for them and lemme know.
@bariqhibat this PR changes the way kubehandlers are provided to graphql. Please look out and lemme know if it causes some issues.

[pottekkat]

Thanks for the note @Utkarsh-pro Will test out mesheryctl and see if there are any issues.

[leecalcote]

Syncing with master.

@Utkarsh-pro this PR does not include the Kubernetes context selector, does it?

Without a selector, users will be unable to identify which context a given operation is to be sent to.

[leecalcote]

@Utkarsh-pro when multiple contexts are connected, only a single cluster chip shows on the Dashboard. We're expecting to show all connected contexts here, yeah?

Screen.Recording.2022-01-04.at.2.17.44.AM.mov

[leecalcote]

@Utkarsh-pro I'm getting:

INFO[0042] attempting to save kubernetes context to remote provider 
DEBU[0042] saving context to remote provider - constructed URL: https://meshery.layer5.io/user/contexts 
WARN[0042] failed to save the context: Status Code: 201.failed to save kubernetes context 

I'll send you the full logs...

[tangledbytes]

Syncing with master.

@Utkarsh-pro this PR does not include the Kubernetes context selector, does it?

Without a selector, users will be unable to identify which context a given operation is to be sent to.

@leecalcote, yes this PR doesn't have the mentioned context selector. Right now the only way to switch contexts is to do it from the settings (by selecting the context from the dropdown).

UI certainly needs to be improved, it could be a part of this PR or could be brought in another PR considering that the UX doesn't changes even if we bring in this PR.

[tangledbytes]

@Utkarsh-pro when multiple contexts are connected, only a single cluster chip shows on the Dashboard. We're expecting to show all connected contexts here, yeah?

Screen.Recording.2022-01-04.at.2.17.44.AM.mov

Yes, that's right. We should be showing the same here as well.

[tangledbytes]

@Utkarsh-pro I'm getting:

INFO[0042] attempting to save kubernetes context to remote provider 
DEBU[0042] saving context to remote provider - constructed URL: https://meshery.layer5.io/user/contexts 
WARN[0042] failed to save the context: Status Code: 201.failed to save kubernetes context 

I'll send you the full logs...

Ah, I think this is just a minor bug. I think the status code that the remote provider sending is 201 (resource created) while the server is expecting 200. So the API is working just fine, just need to change the expected status code.

Will fix this 👍

[piyushsingariya]

Things that failed during testing in my system

• Failed to delete current-context
• Failed to delete all context
• Failed to deploy operator in a non-current-context cluster
• If I upload the same kubeconfig twice, multiple entries for contexts get saved

2022-01-15.15-13-28.mp4

[leecalcote]

@Utkarsh-pro thoughts on @piyushsingariya's feedback?

Heads-up on merge conflicts.

[tangledbytes]

These are concerning findings @piyushsingariya. I have been away from this PR for a while now but will look into these behaviours and will confirm if these are indeed reproducible bugs and were not left out for certain reasons.

I should be able to get back on this within a few hours.

// @leecalcote

[tangledbytes]

Also, thank you much @piyushsingariya for testing this out understanding you may had to go out of your way to test this PR out 🙁 .

[leecalcote]

@Utkarsh-pro here's the design for the Kubernetes context switcher - https://www.figma.com/file/SMP3zxOjZztdOLtgN4dS2W/Meshery-UI?node-id=3984%3A21705

[leecalcote]

@Utkarsh-pro any comment here? Something that you can implement?

[leecalcote]

A few merge conflicts have popped up. FYI, @Utkarsh-pro.

[tangledbytes]

@leecalcote, yes I can work on the the given UI. Have been lagging quite a lot but will make sure that this PR goes through ✅ .

[leecalcote]

@Utkarsh-pro sounds great. Can you demo progress at this week's Meshery development meeting?

[leecalcote]

@Utkarsh-pro, how about this week? Can you demo progress at this week's Meshery development meeting?

[tangledbytes]

Hey @leecalcote, I have conflicting meeting on Wednesday. I'll try to show the progress on Friday's call though.

[leecalcote]

@Utkarsh-pro, excellent! // @debo19

[leecalcote]

Tomorrow is the big day! :)

[tangledbytes]

@leecalcote all the changes that I had locally are here now. I have also resolved the merge conflicts.

Screenshots

@piyushsingariya I could not replicate duplicate upload issue, I am not sure what might have caused that 🤔 . To answer other questions:

• Users can delete their "active context" but doing so will have not net effect as the reload will re-create the context, that's why it seems you cannot delete the context.
• Operator deployment in multiple cluster is not yet part of this PR. The reason is mostly because there is no design for that yet. Right now operator is deployed as soon as meshery comes up, that cannot be done if the contexts themselves are closely tied to users. We basically need design here, just the deployment part - the rest of the things are in place to support multiple operators and data sources.

// @sudo-NithishKarthik @Revolyssup