[DevOps] Enhance MeshSync Discovery All Resources

[theBeginner86]

Current Behavior

Currently MeshSync doesn't discover following K8s API Resources

1. IngressClass
2. NetworkPolicy
3. ServiceAccount
4. Roles
5. ClusterRoleBindings
6. RoleBindings
7. ResourceQuotas
8. PriorityClasses
9. RuntimeClasses

Desired Behavior

Add support in MeshSync discovery pipeline to discovery all the available resources in Kubernetes cluster.

Contributor Resources

The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

• See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
• See Meshery site designs in Figma (open invite).
• Fill-in a Community Member Form and join the Community Slack for access.

[theBeginner86]

@KiptoonKipkurui would you like to take this up?

[KiptoonKipkurui]

@theBeginner86 Sure, I will take this up

[leecalcote]

Gents, MeshSync should be able to be informed about ALL resources. Resources should not have to be named. Generally, resources should only be named as a blacklist of what not to be informed of (granted, MeshSync will support the flexibility of a whitelist, too, but that whitelist should be all resources by default). // @MUzairS15 @Aisuko

[KiptoonKipkurui]

@theBeginner86 Following this discussion, this I believe this issue should change to enhance meshery to auto discover all resources in a cluster

Gents, MeshSync should be able to be informed about ALL resources. Resources should not have to be named. Generally, resources should only be named as a blacklist of what not to be informed of (granted, MeshSync will support the flexibility of a whitelist, too, but that whitelist should be all resources by default). // @MUzairS15 @Aisuko

[theBeginner86]

@theBeginner86 Following this discussion, this I believe this issue should change to enhance meshery to auto discover all resources in a cluster

Gents, MeshSync should be able to be informed about ALL resources. Resources should not have to be named. Generally, resources should only be named as a blacklist of what not to be informed of (granted, MeshSync will support the flexibility of a whitelist, too, but that whitelist should be all resources by default). // @MUzairS15 @Aisuko

Sounds good. Updated 👍

[Priyank-Vaidya]

@theBeginner86 I want to work on this issue

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[leecalcote]

@KiptoonKipkurui do we still have a hardcoded whitelist? Is it dynamically configurable, yet? If so, can you point me to the docs on it?

[KiptoonKipkurui]

@KiptoonKipkurui do we still have a hardcoded whitelist? Is it dynamically configurable, yet? If so, can you point me to the docs on it?

The whitelist is currently hard coded in helm charts and meshsync, and only the items on this list would be discovered and watched. Currently each time you want to track events for a specific resource it has to be added to this both sections. Now the enhancement with this PR was to first use KubeAPI discovery API to get all resources in the cluster without being bound to the said list thus making all resources supported by default and second and enhancement to support using both fields blacklist and whitelist in our ConfigMap (current implementation has us using either one or the other).

Is Dynamically configurable: partial yes, for resources already here meshsync one can blacklist or whitelist and also control the observed events (added, modified, removed), but not for resources outside this list

Docs?: Docs exist to document the current behavior

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue is being automatically closed due to inactivity. However, you may choose to reopen this issue.