Circular topologies and relationship creation time

[pmjordan]

I have a need to describe a circular topology: Node A has a relation to Node B and Node B has a relation to Node A.

Understandably Ubicity considers this a deadlock since it doesn’t know in which order to deploy the elements. In fact, the relationships are only required to configure the deployed nodes after that have been instantiated, but in V2 there doesn’t seem to be a way to indicate when in the lifecycle the relationship is relevant.

[pmbruun]

This completely depends on the interpretation of the relationship. Not all relationships mean that there is a deployment dependency. Also, in version 2.0 we no longer have any standardized relationship types, so there is not presently any way of expressing that a relationship is intended to imply a deployment dependency.

[philippemerle]

TOSCA 1.3 specifies a set of normative relationship types such as tosca.relationships.HostedOn and tosca.relationships.ConnectsTo and specifies how an orchestrator 1.3 should interpret them. In a simplified view, if a node A is in relation with a node B then an orchestrator 1.3 shall create then configure then start node B before create node A. So if node A is in relation with node B which is in relation with node A (a circular relation) then an orchestrator 1.3 can not find a deployment plan. Here Ubicity correctly detects this circular dependency. So TOSCA 1.3 makes the following implicit assumption: Each relationship implies a deployment dependency. So there is no way in TOSCA 1.3 to describe circular relationships in an orchestrator agnostic portable way.

Let us image the following relationship types, their semantics is informally defined in the description:

relationship_types:
  HostedOn:
    description: the target node shall be created, configured and started before the source node is created
  Uses:
     description:  A relation implies no deployment dependency
  Contains:
    description: the source node shall be created, configured and started before the target node is created

Here most of orchestrators 1.3 will fail to correctly implement both Uses and Contains relationships, or if they will success this is because they hard-code the semantics of Uses and Contains.

TOSCA 2.0 may provide a linguistic support to clearly define what the deployment semantics is associated to each relationship type. A beautiful but big piece of work to do.

[pmbruun]

@philippemerle Yes, with TOSCA 1.3 orchestrators of course need to check that the dependencies are non-cyclic.

TOSCA 2.0 may provide a linguistic support to clearly define what the deployment semantics is associated to each relationship type. A beautiful but big piece of work to do.

@lauwers @tliron Are we planning this for 2.0? It was my impression that this would be delegated to profiles?

[philippemerle]

It was my impression that this would be delegated to profiles?

@pmbruun Yes profiles will define relationship types with their associated deployment semantics. But profile designers will need some TOSCA constructs to express the deployment semantics and these constructs shall be specified into the TOSCA 2.0 language. Here contributions will be welcome. For instance, my implementation includes a configure language where deployment semantics can be expressed. I could provide this as inputs to discussions in the TOSCA TC.

[tliron]

In my view the range of possible semantics is simply too big and should be beyond the scope of TOSCA's validation. For example, there can be complex rules for which kinds of relationships work together in which directions and for how many levels. And some of these rules may depend on deployment conditions (if/else logic).

Perhaps one day we can find a way to create a policy-based, declarative way to validate the topology as whole, or at least assist (maybe a TOSCA graph traversal DSL can help), but I'm skeptical. This kind of "business logic" is often programmatic by nature.

By the way, even something as simple as "dependency" semantics is open to interpretation. I don't see any technical problem with mutual dependencies and even cyclical dependencies. It's more about what kind of rules and results are wanted, as long as the rules are deterministic: e.g.: if the dependencies are cyclical than we can say that order is arbitrary. Of course there can also be various kinds of "dependencies" within the same graph, each with different semantics.

The fact that graph edges are typed is one of TOSCA's killer features. I would not want to limit its power and flexibility in any way.

[lauwers]

In my opinion, this isn't about relationship types, but rather about interface types, and about how operations of interfaces on nodes are "weaved" with operations of interfaces on relationships. This "weaving" is currently only specified for the Simple Profile interface types and only in the specification. It shouldn't be too hard to create syntax for this.

[pmbruun]

@lauwers Yes, but that is not the whole story, because there are operations on the source, the target and the relationship. And if the nodes have multiple relationships, you need to transitively weave those as well. Even if the relationship has no operations of its own, it could still imply weaving of operations on source and target.

@tliron the fact that there is a fairly large range of possible semantics does not necessarily give up and say it is "too big" - it could still be possible to classify and enumerate semantics that cover most common cases. Do we have evidence that the range is even very big?

If we identify a semantics X of some kind of dependency-relation source-X-target, then by anti-symmetry there would also exist a reverse semantics, X', so that source-X-target <=> target-X'-source - so that cuts the enumeration task in half.

My implementation has 5 major types of dependencies, and a number of variants - corresponding to different interleaving rules, as @lauwers writes. For example I have a lockstep variant of interleaving. Some of the variants differ on their teardown and re-creation interleaving rules, and I don't think we are close to needing those variants in TOSCA yet.

So @tliron - I suggest you give some more examples showing that the range is really "too big".

NB! I am not implying that all relationships must stay within a pre-defined range of semantics. I am saying that some types of semantics imply meaningful and commonly used interleaving strategies - aka. dependency types, and that those could be standardized.