ztunnel

ztunnel copied to clipboard

We currently have ProxyMode::Dedicated | Shared and InpodEnabled: true|false and I can't think of any scenarios where those are not basically indicating the same thing.

We also sort of don't use ProxyMode at all, and I think we should - the tenancy model is more important to express than how we do the tenancy model (currently we have only one multitenant model anyway, so why make it optional?).

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

slapping a hold on until @keithmattix @jaellio @justinpettit have a chance to weigh in.

Hmm, how does direct.rs work still?

By setting proxy_mode: config::ProxyMode::Dedicated in the test config it uses.

This seems to break local development flows which I didn't realize would happen when initially discussing

Local development flows as in proxy_mode: config::ProxyMode::Dedicated flows?

Or local development flows as in proxy_mode: config::ProxyMode::Shared flows but without any inpod machinery?

Doesn't dedicated not allow multiple clients with unique source though? do we just not test that

Doesn't dedicated not allow multiple clients with unique source though? do we just not test that

I don't believe we test that. Probably because we have too many flags that influence how tenancy works.

That's kind of what I'm trying to say with this PR, we really only have two tenancy modes as far as I can see - multi tenant and single tenant.

Multitenant is only supported, tested, exercised and fully functional with inpod.

And if we don't test it and we don't use it, I don't know why we carry it/am waiting for an argument as to why we should carry (and thus test) it, or not.

And if we don't test it and we don't use it, I don't know why we carry it/am waiting for an argument as to why we should carry (and thus test) it, or not.

Well we do test it, this PR removed the tests :slightly_smiling_face:. This currently breaks how develop and ~exclusively run ztunnel. Mind if I take a bit to poke around and see if there are viable alternatives with this change to develop locally?

Well we do test it, this PR removed the tests 🙂. This currently breaks how develop and ~exclusively run ztunnel. Mind if I take a bit to poke around and see if there are viable alternatives with this change to develop locally?

Fair, we lightly test it, sorta, in one spot with 3 tests, and don't support the mode. Yep, please - I don't develop with standalone local ztunnel so I'm not the best testbed for that.

(Am also OK with just not doing this if it's a pain - just feels like we should drop or consolidate these flags)

ok I think my dev ex is solved easily: PROXY_MODE=dedicated

ok I think my dev ex is solved easily: PROXY_MODE=dedicated

Oh good - this one?

Doesn't dedicated not allow multiple clients with unique source though? do we just not test that

It does currently allow multiple sources which I think is broken. This PR would enable us to move towards a better architecture IMO, where a Proxy is never instantiated without a source_workload: <...>. This could be a WorkloadDescription like we have today, but could even be a full Workload (wait over xds) and/or full certificate as well.

We might not want that to block startup though, so maybe its something like a Lazy<(Workload, Certificate)> where we start it when we first launch, and then block first request on it until it loads.

For local dev, can just run ztunnel twice if need to test different sources

/test test

@howardjohn should be g2g