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]

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 all data products and data contracts in the configured DMM namespace. Intended for local sandbox cleanup and CI teardown. Prompts for confirmation unless --yes is passed.

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

# Wipe entire sandbox (local dev only!)
fluid dmm wipe --yes

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.

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.