Skip to content

Conversation

@stephenfin
Copy link
Member

Make some tweaks based on initial attempts to use this tool.

  • docs: Distinguish between import, create dependencies
  • scaffold-controller: Make difference between questions more obvious

Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
@github-actions github-actions bot added the semver:patch No API change label Sep 25, 2025
!!! note

ORC dependencies can *only* be expressed between ORC objects. Therefore if one OpenStack resource depends on another, that relationship can only be expressed in ORC if both resources have corresponding ORC objects. Resoruces which a user may depend on but cannot create, like a flavor or a provider network, can be expressed by importing an existing resource.
ORC achieves this through dependency management. OpenStack doesn't have the concept of resource dependencies natively, so ORC expresses dependencies through ORC objects, not their underlying OpenStack resources. Resources that a user can create and may be depended on, like a server group or image, are expressed as *create dependencies*, while resources that the user cannot create but may be depended on, like a flavor or provider network, are expressed *import dependencies*.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I don't think the proposed change brings clarity. I agree the doc needed a rewrite, but the modification makes it more confusing to me.

This paragraph aim to say that resources must be known to ORC if you want to express dependency. The way you have your openstack resource known to ORC is either via:

  • a managed resource, where ORC has ownership over its lifecycle. The object will have managementPolicy: managed and a resource spec.
  • an unmanaged resource, that ORC has read only access to. The object will have managementPolicy: unmanaged and an import filter. This is to import existing resources into ORC.

They both have can have create dependencies (i.e. upon object creation), and they behave exactly the same, meaning that the resource won't be created or imported until the dependency is satisfied: when the referenced ORC object exists and is considered available. The only difference is that one will have the dependency expressed in the resource spec, while the other one will have the dependency expressed in the import filter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

semver:patch No API change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants