fluid datamesh-manager

Publish FLUID data products and contracts to Entropy Data / Data Mesh Manager, and manage the products and teams stored there.

Syntax

fluid datamesh-manager publish CONTRACT [options]
fluid datamesh-manager list [--format FMT]
fluid datamesh-manager get PRODUCT_ID
fluid datamesh-manager delete PRODUCT_ID [--yes]
fluid datamesh-manager teams [--format FMT]
fluid datamesh-manager list-contracts [--format FMT]
fluid datamesh-manager get-contract CONTRACT_ID
fluid datamesh-manager delete-contract CONTRACT_ID [--yes]
fluid datamesh-manager wipe [--yes] [--max-passes N]

A short alias fluid dmm is registered for the same command group.

Key options

publish

list, teams

get, delete

list-contracts, get-contract, delete-contract

Manage companion data contracts published alongside data products.

wipe

Delete every data product in the configured DMM tenant. Data contracts are not deleted: remove those with delete-contract. Intended for local sandbox cleanup and CI teardown. Prompts for confirmation unless --yes is passed.

DMM refuses to delete a product that other products consume, so wipe works in passes: each pass deletes the products DMM accepts, and the products that were refused as in use go to the next pass. Consumers drain before their producers. It stops when nothing is left, when a pass makes no progress, or after --max-passes. When a pass makes no progress it names the consumers that block each remaining product. The command exits 0 when the tenant ends empty, and 1 when any product remains.

Examples

# Publish
fluid datamesh-manager publish contract.fluid.yaml --dry-run
fluid datamesh-manager publish contract.fluid.yaml --with-contract --validation-mode strict
fluid dmm publish contract.fluid.yaml --auto-approve-access

# Read / list
fluid dmm list --format json
fluid dmm list-contracts --format json
fluid dmm get-contract my-org.customer360-contract

# Delete
fluid dmm delete gold.customer360_v1 --yes
fluid dmm delete-contract my-org.customer360-contract --yes

# Delete every data product in a sandbox (local dev only!)
fluid dmm wipe --yes
fluid dmm delete-contract my-org.customer360-contract --yes   # contracts are separate

Configuration

The generic catalog adapter accepts the same behavior through ~/.fluid/config.yaml:

catalogs:
  datamesh-manager:
    endpoint: https://api.entropy-data.com
    auth:
      api_key: ${DMM_API_KEY}
    data_product_specification: odps
    provider_hint: odps
    odps_lineage_mode: contract
    auto_approve_access: false

ODPS lineage and Access agreements

For ODPS publishes, product-to-product consumes[] entries are not kept as ODPS inputPorts by default. They become Entropy Access agreements from the upstream data product/output port to the consuming data product.

That default avoids duplicated lineage nodes: upstream data products stay data products, and are not mirrored as SourceSystem objects just to satisfy older ODPS importer behavior.

Use --odps-lineage-mode source-system only for legacy DMM deployments that explicitly require SourceSystem custom properties on retained ODPS input ports. Explicit source-system consumes authored in the FLUID contract are still preserved as source-system input ports in the default contract mode.

Access agreements are create-only by default. Use --auto-approve-access, DMM_AUTO_APPROVE_ACCESS=true, or catalog config auto_approve_access: true only when your environment intentionally auto-approves those agreements. --no-auto-approve-access forces pending agreements for one publish even when the environment variable is set.

Team creation is defensive: if the server rejects the initial team payload because member emails do not exist as DMM users yet, the provider retries team creation without members while preserving the contact email.

Notes

• The short alias fluid dmm is equivalent to fluid datamesh-manager.
• Before any publish, the loaded FLUID contract is validated against the schema matching its declared fluidVersion. --validation-mode strict aborts on errors; --validation-mode warn (the default) logs and proceeds.
• --validate-generated-contracts validates generated ODCS companion contracts before PUT. Use it with --validation-mode strict when generated catalog contracts should block publish.
• The dcs contract format is marked deprecated; prefer the default odcs.
• For local-only export to ODCS (no publish), see fluid odcs. For ODPS exports, see fluid odps and fluid odps-bitol.