-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shadow api can not access pv which dynamicly created by pvc #784
Comments
@x-7 Would you please share the steps? So we could reproduce what happened. Thanks. |
@x-7 What Also |
I think one of the original reasons for designing shadowapi was to seamlessly replace the k8s native api in the business logic, so it only makes sense that at least what the k8s native api can access, the k8s shandowApi should also be able to access。 If not, I can only get the appropriate cluster id from the subscription, get the appropriate k8s configuration based on the cluster id, and then use the native api to get the resource information. This bypass looks very unclusternet |
@x-7 Clusternet is used for multi-cluster scenario. It helps deploy these template resources (the so-called shadow api resources) to child clusters. For these shadow resources that are not deployed to child clusters, it is not desired to populate any kinds of other resources in parent cluster. Taking pvc as an example. We want this PVC to be deployed in child clusters, right? Then what's the use of having a PV for this PVC in parent cluster? That does not make sense. When this PVC is deployed to a child cluster, the pv provider/provisioner in the child cluster will prepare and bind a proper PV for such a PVC. Moreover, in different child clusters, even a same named PVC can be bound with different named PVs. We can not make sure all these PVs are identical. That is totally impossible. These PVs may be from any kinds of storage providers as well. I think Resources Creation in Clusternet can show you some backgrounds and the design purposes. |
|
@x-7 I understand your user scenarios. It's painful to switch k8s contexts back and forth. We had such scenario as well. But there are multiple aspects that we need to consider before we move next.
|
Currently we've made some attempts to aggregate resource status from child clusters. Only jobs/statefulsets/deployments workloads are supported right now. |
"How could we specify or inline cluster context? Such as kubectl clusternet --cluster-id=xxx ? What the request url will be like? And how to align with native k8s style?" |
It feels so difficult |
What happened:
when use clusternet create a pvc without specfic volume,the pv dynamically created by the pvc can not be access with shandow api.
What you expected to happen:
expect the resouce created by it's parent resource(which is create with clusternet ) can be access with shandow api
How to reproduce it (as minimally and precisely as possible):
pvcbug.yaml
expect: the pv will appear in the output
actual : the output is empty
Anything else we need to know?:
Environment:
The text was updated successfully, but these errors were encountered: