docs(kv-cache): state that a ledger-less pool needs an explicit multiTenancy false - #696
Conversation
…Tenancy false #695 made leader.multiTenancy default to true, but the pool page still described the ledger-less master as the plain case. Say where a ledger-less master now comes from: a managed backend that declares leader.multiTenancy: false, which a store image older than Mooncake 0.3.12 has to, or an external master started without multi-tenancy. The omitted domain name is now the tenant the engines are handed on a multi-tenant master, so name each domain once a second Binding shares it. The kubectl example reads from a managed backend's default. Signed-off-by: thxCode <thxcode0824@gmail.com>
|
🔍 OpenCodeReview found 2 issue(s) in this PR.
📄
|
What type of PR is this?
/kind documentation
/area worker
What this PR does / why we need it:
#695 made
KVCacheBackend'sleader.multiTenancydefault totrue.docs/kv-cache/pool.mdstill described the ledger-less master as the plain case. This says where one now comes from:leader.multiTenancy: false, which a store image older than Mooncake 0.3.12 has to (links to the build-variants section feat(api): default KVCacheBackend leader.multiTenancy to true #695 added inbackend.md);It also updates the omitted
domain.namebullet: on a multi-tenant master,defaultis the tenant the engines are handed, so each domain should be named once a second Binding shares the master. Thekubectl get kvcpbexample is now read from a managed backend's default rather than from an opt-in.Which issue(s) this PR links to:
Relates #695
Special notes for your reviewer:
Docs only.
make lint docspasses.Does this PR introduce a user-facing change?