Relationship between Adopted Resources with other aws-prometheusservice-controller components.

[RipulHandoo]

Notes for Reviewers

This PR fixes #
1.Relationship between Adopted Resources with other aws-prometheusservice-controller components.

Signed commits

• Yes, I signed my commits.

[leecalcote]

"description": "A hierarchical inventory relationship in which the configuration of (parent) component is patched with the configuration of other (child) component. Eg: The configuration of the EnvoyFilter (parent) component is patched with the configuration as received from WASMFilter (child) component."

[leecalcote]

I believe that this relationship is valuable. My understanding is that it might only be valuable to the extent that the user is in a brownfield situation, which is to say that they have already deployed their Pods (in this case). The behavior of the AdoptedResource (which is a resource pervasively available throughout each of the controller projects) is valuable to capture into a Meshery Relationship in-context of melding Visualizer (Operator) and Designer modes. The following is my understanding of the purpose and use of AdoptedResources.

An AdoptedResource in the AWS Controllers for Kubernetes (ACK) project only applies to resources that have been deployed to a running cluster. It does not apply to resources defined solely in a manifest (not yet deployed).

Here's why:

1. Interaction with existing resources: The primary function of AdoptedResource is to manage existing AWS resources, not resources defined for future deployment. It achieves this by referencing the already provisioned resource and ensuring its state aligns with your configuration. Manifests, on the other hand, hold definitions for resources to be created, not existing ones.
2. Kubernetes API interaction: AdoptedResource interacts with the Kubernetes API to retrieve information about the existing resource and potentially manage its desired state. However, until a resource is deployed to the cluster and registered with the API, there's no information for AdoptedResource to interact with.

Therefore, while AdoptedResource offers a way to integrate existing resources with your Kubernetes cluster, it only takes effect once those resources are deployed and registered within the cluster.

I make note of this to help ensure that we understand when and where this relationship is useful to users, and how this moment in time (day 2 only), serves as a prerequisite that Meshery might need to enforce with the presences of the id.pattern.meshery.io annotation on the given existing Pod (in this case) resource.

@aabidsofi19 @MUzairS15 @theBeginner86

[github-actions]