You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Observation
As an alternative option specifying the namespace LODs in the workspaceInfo.yaml file for runwhen local (which works relatively well for smaller scale deployments). It would be nice to have some specific annotations that we can read from the resource to specify LOD, such that deployment pipelines could automatically add the desired annotation. In this way, new resources could be automatically included or excluded without updating the workspaceInfo.yaml file.
Possible Suggestions
For Kubernetes, discover some annotation set on the namespace:
Any other details or context
I think this should be aligned with #374, though an annotation like the following would be set on the matched resource and not the namespace:
Observation
As an alternative option specifying the namespace LODs in the workspaceInfo.yaml file for runwhen local (which works relatively well for smaller scale deployments). It would be nice to have some specific annotations that we can read from the resource to specify LOD, such that deployment pipelines could automatically add the desired annotation. In this way, new resources could be automatically included or excluded without updating the
workspaceInfo.yaml
file.Possible Suggestions
For Kubernetes, discover some annotation set on the namespace:
Any other details or context
I think this should be aligned with #374, though an annotation like the following would be set on the matched resource and not the namespace:
We would also want to consider how to handle this with other cloudquery discovered resources such GCP/Azure/AWS tags.
The text was updated successfully, but these errors were encountered: