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
Thanks a lot for this controller to help in discovery duck types which can be used on various occasions.
From the kn client POV a podspecable.duck.knative.dev is useful especially to reason about K8s built-in types which are per se not allowed to be queried/accessed by a pure Knative client. As querying CRDs is part of the Knatice API contract, the listing of CRDs matching certain labels is directly possible for a client (so this selection would be not so important)
On the other hand, the explicitly defined refs would allow the client to have indirect access to those k8s core objects. In order to be useful for kn` for e.g. to finding out which core-podspecable can be used in a SinkBinding, we would need also the actual list of instances of the duck-type (e.g. like the union of all Deployement/StatefulSets/Jobs/... along with their coordinates).
I wonder whether we could add this as part of the status, too ? like a status.duckInstances ? Not sure if this is really feasible as it would require quite elevated permissions for the discovery controller in order to be able to query all resources (which are also not known in advance as they are part of the DuckType specification, so probably a global list of all resources would be needed).
The text was updated successfully, but these errors were encountered:
Thanks a lot for this controller to help in discovery duck types which can be used on various occasions.
From the kn client POV a
podspecable.duck.knative.dev
is useful especially to reason about K8s built-in types which are per se not allowed to be queried/accessed by a pure Knative client. As querying CRDs is part of the Knatice API contract, the listing of CRDs matching certain labels is directly possible for a client (so this selection would be not so important)On the other hand, the explicitly defined
refs
would allow the client to have indirect access to those k8s core objects. In order to be useful for kn` for e.g. to finding out which core-podspecable can be used in a SinkBinding, we would need also the actual list of instances of the duck-type (e.g. like the union of all Deployement/StatefulSets/Jobs/... along with their coordinates).I wonder whether we could add this as part of the status, too ? like a
status.duckInstances
? Not sure if this is really feasible as it would require quite elevated permissions for the discovery controller in order to be able to query all resources (which are also not known in advance as they are part of the DuckType specification, so probably a global list of all resources would be needed).The text was updated successfully, but these errors were encountered: