Serge Huber created UNOMI-958:
---------------------------------
Summary: Operators cannot read per-tenant usage through the Unomi
REST API
Key: UNOMI-958
URL: https://issues.apache.org/jira/browse/UNOMI-958
Project: Apache Unomi
Issue Type: Sub-task
Components: unomi(-core)
Affects Versions: unomi-3.1.0
Reporter: Serge Huber
Fix For: unomi-3.1.0
h2. Summary
Multi-tenant operators and upstream control planes cannot read per-tenant usage
(profiles, storage, API volume) from Unomi over REST. Limits should be enforced
above Unomi, but there is no supported REST API to measure usage per tenant.
h2. What is going wrong today
* Usage is collected in background services but not exposed on REST endpoints.
* Documentation refers to monitoring endpoints (e.g. API call counts) that are
not implemented.
* Quota-related code (limits on \{{Tenant}}, \{{TenantQuotaService}}) suggests
Unomi enforces limits, but nothing blocks operations — misleading dead code.
* Upstream gateways or billing systems cannot poll Unomi for per-tenant usage
to enforce plans (profile caps, request limits, etc.).
h2. Impact
* Platform teams must query the search backend directly or build custom tooling.
* Product quotas cannot be enforced consistently at the layer above Unomi
without a supported usage API.
* Contributors may assume \{{ResourceQuota}} on \{{Tenant}} is enforced inside
Unomi when it is not.
h2. Who is affected
* Operators running shared multi-tenant Unomi clusters
* Teams building a control plane or API gateway in front of Unomi
h2. What good would look like
* Unomi exposes *read-only* per-tenant usage via REST: \{{GET
/cxs/tenants/\{tenantId\}/usage}} (optional \{{period}} query param, e.g.
\{{24h}}).
* Response includes profiles, events, segments, rules, storage, and requests
for the requested period, plus \{{collectedAt}} so callers know metrics are
cached/refreshed.
* Endpoint is protected with existing tenant access rules (tenant admin for own
tenant; platform admin for any tenant).
* In-Unomi *quota enforcement* is removed or clearly deprecated; limits remain
the responsibility of the layer above.
* \{{ResourceQuota}} on \{{Tenant}} is deprecated or removed so operators are
not misled.
* \{{TenantQuotaService}} is removed; monitoring consolidated into a single
usage service (evolve \{{TenantMonitoringService}}).
* Multi-tenancy manual updated: usage REST API documented; enforcement
described as upstream responsibility.
* Integration test covers the REST usage endpoint for at least one tenant with
known data.
h2. Out of scope
* GraphQL usage exposure (separate follow-up ticket).
* Enforcing profile, request, or storage limits inside Unomi.
* Storing plan limits on \{{Tenant}} unless kept strictly as non-enforced
metadata (prefer removal).
* Exact N+1 profile rejection on implicit profile creation via
\{{/context.json}}.
h2. Context
* Follows PR 4 ([#809|https://github.com/apache/unomi/pull/809]): UNOMI-941,
UNOMI-938, UNOMI-942 (TenantService robustness + per-tenant count accuracy).
* PR 5 remains UNOMI-943 (migration scripts). This ticket is a follow-up PR
after PR 4 merge.
* Architectural decision: Unomi *measures* via REST; control plane / gateway
*enforces*.
{panel:title=Technical notes (for implementers)|borderStyle=solid}
* Remove \{{TenantQuotaService}} and blueprint wiring.
* Evolve \{{TenantMonitoringService}} → \{{TenantUsageService}} in \{{api}}
with \{{TenantUsage}} DTO.
* Add route on \{{TenantEndpoint}}: \{{GET /tenants/\{tenantId\}/usage}} with
\{{@RequiresTenant}}.
* Request counting: lightweight per-tenant counter on REST path (in-memory
buckets for period), not persisted \{{apiCall}} items unless needed later.
* \{{calculateStorageSize}}: expose document count clearly; add \{{sizeBytes}}
only when implemented correctly.
* Deprecate/remove \{{ResourceQuota}}; update \{{TenantIT}} and shell CRUD
accordingly.
{panel}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
