[chore] Enhancement of MeshSync Discovery

[theBeginner86]

Current Behavior

Currently, every attributes of all resources is not being discovered by MeshSync.

For
Deployments:

For Namespace:

Desired Behavior

Ensure MeshSync tracks all attributes of discovered objects. Eg for namspaces.

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.

[welcome]

Thanks for opening this issue. A contributor will be by to give feedback soon. In the meantime, please review the Layer5 Community Welcome Guide and sure to join the community Slack.

[theBeginner86]

FYI @Aritra8438 @VaibhavMalik4187

[VaibhavMalik4187]

@theBeginner86 I need some help here, could you please share some documentation related to the codebase structure?

[KiptoonKipkurui]

@theBeginner86 I have been looking into this issue, and I would like some clarification on whats the desired behavior in terms of an apples to apples comparison i.e either current Deployment To Desired Deployment object or current Namespace to desired Namespace object attributes.
I looked at the unstructured object returned being converted in model_converter.go at runtime and all configuration under the spec field for both Deployments and Namespaces were captured as the attributes. The Namespace object had only the finalizer attribute under the spec field. In comparing a Deployment object to a Namespace object, it may look like the Deployment object has more attributes than the Namespace object while in reality the Namespace object has few/one configured attribute.
I would like your clarification on this to enable me help out on the issue.

[theBeginner86]

@theBeginner86 I have been looking into this issue, and I would like some clarification on whats the desired behavior in terms of an apples to apples comparison i.e either current Deployment To Desired Deployment object or current Namespace to desired Namespace object attributes.
I looked at the unstructured object returned being converted in model_converter.go at runtime and all configuration under the spec field for both Deployments and Namespaces were captured as the attributes. The Namespace object had only the finalizer attribute under the spec field. In comparing a Deployment object to a Namespace object, it may look like the Deployment object has more attributes than the Namespace object while in reality the Namespace object has few/one configured attribute.
I would like your clarification on this to enable me help out on the issue.

I see. Thanks for taking a look.
I was thinking that we had some one off condition that was just looking for labels for resources of Deployment type. But after looking at your comment and this part of the Namespace spec It looks like we might have to augment our discovery logic a bit.
I wonder if we could use this getLabels function from kubernetes/apimachinery

The original ask was to update our existing MeshSync discovery pipeline to ensure that more metadata (like labels and annotations) is available for every Kubernetes resource discovered by MeshSync.
So, in the screenshot above I was giving an example of how MeshSync is aware of labels that are assigned to a Deployment but we currently are not tracking that for most of other resources, like Namespace in the above example.

[KiptoonKipkurui]

@theBeginner86 Let me look into this and see how much more information about an object we can capture

[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.

[theBeginner86]

We can close this issue.
As I realized that I was querying wrong datable. The required information is already available in kubernetes_key_value table.

Reference:

So by default we should be looking at kubernetes_key_value as for every discovered object the labels and annotation are are stored in that specific table.