Hi everyone, I have a question regarding the multi...
# flyte-support
g
Hi everyone, I have a question regarding the multi-cluster setup, specifically around the separation of concerns between the data plane and control plane. From my current (and somewhat limited) understanding, I know that due to the limitations of fast registration, the control plane needs access to the data plane's bucket. Aside from that, the control plane has its own bucket for storing metadata, while the data plane uses a separate bucket for raw data. However, this setup doesn't seem to be working as expected anymore. Can someone from the team help clarify the expected architecture here? Is there a recommended design or workaround that allows us to avoid granting the control plane access to the data plane's bucket?
a
When doing fast registration, flytekit uses the credentials of flyteadmin to generate a signed URL so it can store the compiled tarball in the storage bucket but the component that ends up writing to the bucket is propeller. Flyte supports specifiying a separate metadata and raw data buckets, so your control plane should be fine with permissions only on the metadata bucket.
It will need access to the dataplane's K8s API Server though which, in Flyte OSS, is handled with bearer tokens.
Honestly this is much easier in Union's Self Managed offering
g
No, I don’t think it’s working as you described. Currently, I’m unable to see the input and output in the UI, and the logs show that Flyte Admin is trying to access the data plane’s S3 bucket, which seems unusual. Aside from the input/output and fast register issue, everything else appears to be functioning properly.
It seems like you’re storing complex inputs and outputs as S3 pointers, and if I’m not mistaken, that might be causing the issue
IMG_1510.jpg