Domain model¶

This page describes the Site custom resource, the applications registry, and what the platform derives from the model. The lifecycle the model drives is in 09; the exporter output detail is in 13.

The Site resource¶

Version v1 has been removed from the Custom Resource Definition (CRD). Version v2 is the only served and stored version. kubectl get sites prints owner, space, name, retention date, and the enabled flag as additional columns.

The CRD declares no required fields: it validates the shape (types, patterns, lengths, defaults) of what is present. Completeness is enforced by the Hub form and by the Python model, which supplies defaults for absent fields (see "Build paths").

spec fields¶

spec.configuration fields¶

The retention zero date¶

The model stores a date object, not the raw string. An empty retention_date (and any absent audit date) becomes the sentinel 2000-01-01 (DEFAULT_DATE_ZERO). The retention job compares against this date like any other, so a Site whose retention_date is empty through direct API use is treated as long expired: it is notified, archived, and finally deleted. The Hub form avoids this: a new site gets today + 365 days as the default, the field carries a "greater than today" validator, and a malformed submission falls back to the stored value.

Identity, naming, and labels¶

• Site path: /<space|owner>/<name>/; account id: <owner>-<name> (core/.../model/utils.py).
• Labels on every derived object (Labels.create_labels): sites.ecmwf.int/app=site, sites.ecmwf.int/id, sites.ecmwf.int/name, sites.ecmwf.int/owner, sites.ecmwf.int/space, and app.kubernetes.io/name=site-<id>. The id label is the raw id. The name, owner, and space values pass through dns_label_hash: a valid DNS-1123 label keeps its value, anything else is replaced by Base32hex(SHA-256), 52 lowercase characters. An empty value omits the label. A hashed owner (for example an email) is therefore not searchable with kubectl get sites -lsites.ecmwf.int/owner=... by plain text; the Hub encodes label queries so its searches work.
• Annotation sites.ecmwf.int/operator_bound=true on every derived object; pods inherit it, and the operator's pod handlers act only on annotated pods (09).
• The StatefulSet and Service select pods by sites.ecmwf.int/id alone (get_match_labels: only stable values go into selectors).

Applications registry¶

Defined in core/src/ecmwf/sites/core/model/site_apps_registry.py with per application app_config.py modules under site/src/ecmwf/sites/website/applications/; each module registers a class in the singleton SiteApplicationRegistry. The runtime contracts and request flow are in site application architecture.

Every class carries flags that drive selection:

Selection rule (ConfiguredSiteApplications): a normal application is configured only when the site's applications list contains an entry with its name and a non-empty image. An entry without an image does not enable anything. The effective container image is the entry's image, or the registry formula when the entry omits it.

In v2, webdav, s3, and the admin UI have no boolean flags: they are enabled by the presence of their entry in spec.configuration.applications. The platform setting migration.enabled adds site-mirror to every site; it is not a per-site application entry.

Each application entry may set:

For a custom application, platform settings restrict registries (site.custom_application_allowed_registries) and public-site custom images (site.allow_public_custom_application, default false). The complete container, validation, and upgrade contract is in custom applications.

Site application images resolve to {kubernetes.private_registry}/{kubernetes.private_registry_project}/{name}:{site.version} (default eccr.ecmwf.int/sites-oss, tag from the chart release; see 01-overview). A non-empty image field in spec.configuration.applications overrides that formula. On upgrade, only the custom application's image is kept; every built-in application's image is rewritten to the platform version.

Resource tiers¶

settings.resource_limits is a tier name, not a quantity. The base table (each application module may override the numbers) is:

The proxy, API, and admin modules define their own larger values per tier, and so does every other application module: no current container uses the base numbers. See the per-application tables in built-in Site applications, custom applications, and content mirror.

Derived objects¶

SiteExporter (core/src/ecmwf/sites/core/model/site_exporter.py) renders, per site, all objects named after spec.id:

Build paths¶

SiteBuilder produces the same model from the Hub form, from the API request, or from the resource itself (from_form / from_json / from_crd), so UI, API, and operator agree on one schema:

• from_crd flattens metadata, spec, and status into one dictionary, keeps the resourceVersion for conflict-safe writes, and optionally rebuilds application images (upgrade=True, see the registry section).
• from_json applies model defaults for absent fields: space falls back to owner, enabled defaults to false, quota to 1, dates to the zero sentinel. A CR without spec.configuration.enabled: true is therefore disabled as far as the model is concerned, even though the CRD default for the stored object is true.
• from_form builds a new site enabled, with the owner as space unless a custom space is set, the default application list, and the retention default of today + 365 days.

status¶

The operator writes status from Pod conditions: for each pod it resolves the first failed or last successful condition (lastTransitionTime) and patches it onto the Site resource (operator/src/ecmwf/sites/operator/site_handler.py, core/src/ecmwf/sites/core/kubernetes/utils.py:resolve_pod_status). The stored shape is SiteStatus: condition (status, last transition time), all_steps_started, phase (Running, Pending, Disabled), start_time, message, reason, and containers — a list of not-ready containers with name, kind (waiting, terminated, or running for a container that fails its readiness check), reason, and message. are_all_pods_running() is true only when all_steps_started and the phase is Running. The CRD types status as an open object (x-kubernetes-preserve-unknown-fields), so the model, not the schema, defines the shape. status is display state only; reconciliation never reads it.

Behaviour requirements¶