Your installation’s architecture will be determined directly by how you lay out your namespaces, which should be a direct representation of how you wish to visualize and manage your platforms, environments, applications etc.

The sum-total of all your namespaces is referred to within Bcome as your Estate.

Namespaces are declared via YAML (see: Namespace attributes) in the following format:

  description: "A description of your namespace"
  type:  the namespace type

Namespaces are laid out in a parent - child format, for example:

  description: "The grandparent"
  type: collection

  description: "The parent"
  type: collection

  description: "The child"
  type: inventory


Namespaces can be of type: collection, inventory, inventory-subselect or inventory-merge

Namespace Types


Collections may contain any number of other collections and any number of inventories, and is denoted by type ‘collection’.

  type: collection
  description: My collection


Your installation must have at least one, and only one root collection. All other namespaces are located below the root. This collection references your Estate, as it contains within it all other namespaces.


An inventory contains servers, either populated from a particular cloud account or from a statically defined manifest. It is denoted by type ‘inventory’.

  type: inventory
  description: My inventory

Sub-selected Inventory

A Sub-selected Inventory contains servers that have been populated as a result of applying filters to an Inventory. It is denoted by type ‘inventory-subselect’.

It requires an origin Inventory referenced by the subselect_from) attribute upon which the subselect is actioned, in addition to a filter block.

  type: collection
  description: My root collection

  type: inventory
  description: My Inventory

  type: inventory_subselect
  description: My Sub-selected Inventory
  subselect_from: my_inventory
  filters: ...

Note that the ‘subselect_from’ key denotes a breadcrumb to the subselected from inventory (minus the root collection). For example, consider the following:

  type: collection
  description: Root collection

  type: collection
  description: Platform collection

  type: collection
  description: Production environment

  type: inventory
  description: All my servers

You could create a sub-selection from the ‘servers’ Inventory as follows:

  type: inventory-subselect
  description: My application servers for platform production
  subselect_from: platform:production:servers
  sub_filter: {}

The root collection key in the sub-select_from attribute - in this instance ‘estate’ - is implicit.


See: Namespace attributes for sub_filter options.

Merged Inventory

A merged inventory is the result of a union of two or more Inventories and/or Sub-selected inventories. It is denoted by type ‘inventory-merge’.

It requires contributing Inventories and/or contributing Sub-Selected-inventories to be specified using the ‘contributors’ attribute. For example:

  type: inventory-merge
  description: Production and Development frontend servers
  - production:frontend
  - development:frontend


Use Merged Inventories to create ‘Multi-cloud’ and/or ‘Hybrid-cloud’ views.

A Merged Inventory may have contributors from the same or different networks within the same Cloud, different Clouds, or from statically declared manifests.


A Server directly represents a server from a Cloud provider, or one from a the statically defined manifest.

With the exception of static-manifests, servers are not declared, rather they are populated into Inventories from by your Network configuration (see: network-configuration-attributes).