Skip to content

Dependencies

Dependencies allows you to specify DAG and how different service components are dependent on each other. The dependency structure is inturn used to determine the order across service components during several operations like provisioning, patching, scaling etc. As an example, if service component Parent (say Kafka) depends on a service component Child (say ZooKeeper), then Omnistrate will make sure to provision Zookeeper first before Kafka is deployed to make sure Zookeeper is available when Kafka tries to come up.

Note

  • Dependencies are different from resource linking. To learn more about linking service components, please see this page. For comparison between the two, see this
  • Note that some of the resources (service components) can be internal in your DAG. To learn more about internal vs external resources, please see this page
  • Note that some of the resources can be passive resources in your DAG. To learn more about passive vs active resources, please see this page

Configuring dependencies

You can define dependencies using depends_on tag in your compose specification. Here is a more concrete example:

PGAdmin:
  image: omnistrate/pgadmin4:7.5
  x-omnistrate-mode-internal: true

Writer:
  image: 'bitnami/postgresql:latest'
  x-omnistrate-mode-internal: true

Reader:
  image: 'bitnami/postgresql:latest'
  x-omnistrate-mode-internal: true

Cluster:
  image: omnistrate/noop
  depends_on:
    - Writer
    - Reader
    - PGAdmin

Alternatively, you can configure it using our API/CTL/UI. In the above example, Cluster resource depends on 3 resources: Writer, Reader and PGAdmin. The relationship between them will look like the following:

Resource dependencies

Note

Note that Writer, Reader and PGAdmin are all internal resources and so Omnistrate will NOT generate API/CLI/UI for your customers to directly provision or perform other management operations. Instead the lifecycle of these resources will be managed through Cluster parent resource, which is external.

Note

Also, note that Cluster is a passive resource and so creating an instance of just Cluster resource will NOT provision any infrastructure. However, Cluster resource depends on the other 3 resources and, so when create is invoked on the Cluster resource, it will create an instance of other 3 resources which are active resources with their associated infrastructure.

Configuring dependency parameters

As part of defining dependencies, you may also want to map dependency parameters. It allows you to map API parameters to configure dependent components to the parent component through dependency mapping. As an example:

Cluster:
  image: omnistrate/noop
  x-omnistrate-api-params:
    - key: instanceType
      description: Instance Type
      name: Instance Type
      type: String
      modifiable: true
      required: true
      export: true
      defaultValue: t4g.small
      parameterDependencyMap:
        Writer: writerInstanceType
        Reader: readerInstanceType
        PGAdmin: instanceType

In the above example, the instanceType param of Cluster resource is mapped to writerInstanceType of Writer resource, readerInstanceType of Reader resource, and instanceType of PGAdmin resource.

Note

In case, you have two service components, A and B, which rely on a third service component, C. If they both define the parameterDependencyMap to service component C, then depending on whether the user is creating an instance of A or of B, C will use the corresponding value.

References

For a hello world example, please see this
For video walkthrough, see this