occurances in node template requirement assignment not supported

[pmjordan]

In tosca/examples/requirements-and-capabilities.yaml the socket must be assigned twice as shown. But what can I do if I want both to be of type SuperSmartPlug? I tried to comment out the first socket instance and add a line after 225 containing occurrences: [ 2,2 ] I think this should be allowed by the syntax in Tosca 1.3 section 3.9.2.2.2 but I get an error @226,13 topology_template.node_templates["fan1"].requirements{0}.relationship.occurrences: unsupported field

[tliron]

You are absolutely right, this was on my TODO list, a feature added in 1.3. By the way, you mean section 3.8.2.2.2. I will work on it today.

[tliron]

So, there are a few things that confuse me here about what you are trying to do:

1) If you want both to be of type SuperSmartPlug, what's stopping you from adding type: SuperSmartPlug to the first requirement, e.g. insert it before line 214? 2) Why do you think adding "occurrences" would help you?

Actually, the whole interpretation of what "occurrences" means is being heavily debated. In my opinion having "occurrences" in the assignment makes absolutely no sense in my usage, because Puccini interprets "occurrences" in the definition to say exactly how many assignments you should have. I basically have no idea how to interpret this keyword in assignments, which is why I postponed implementing it. Maybe you have some insight from what you are trying to do here?

[pmjordan]

Your solution would not be very elegant for large numbers of sockets.

My requirement is to deploy an app to a specified number, n, of compute. My approach is: myApp: requirements: occurrences [n,n]

myCompute directives: [select] node_filter: capabilities:

• host: attributes:
  • ...

I could attempt to use scaling policy but that has it's own ambiguities

[tliron]

I don't understand exactly what you are trying to do. Are you trying to say that "occurrences" would be used to specify how many relationships to create? What do you expect to happen if the range is, for example, [ 1, UNBOUNDED ]? It doesn't seem that this keyword is designed for what you intend.

In my opinion, if you want to be able to specify the number of sockets then it should be via a property in the relationship type. Generally I think there would be a lot more detail you need than just number. Remember, a node template is not a node instance. For example, if the number of connections needs to be distributed somehow between multiple node instances.

node_templates:
  my-app:
    requirements:
    - host:
        node: my-db
        relationship:
          type: Connections
          properties:
            count: 20
            distribution: Balanced

  my-db:
    properties:
      instances: 10

In this example, the idea would be to distribute those connections in a balanced way, so there would be 2 connections per db instance. If there were 100 db instances, then a random 20 of them of would get one connection each. There could be other distribution styles, too, such as putting half of them on one instance with 1 each on others in order to create a failover redundancy.

My point in this example is to show that runtime relationships are not design relationships. The former is between node instances, which is very implementation specific, while the latter is between node templates, which is left abstract in TOSCA. By adding properties to relationships, capabilities, node templates, etc. -- and also using policies -- you have various ways of telling your orchestrator what to do. I don't see how the "occurrences" keyword, as a range, is very useful. What are your thoughts?

[pmjordan]

Thank you for your deep thinking on this subject. I now see your point about the difference between runtime and design relationships. FYI I moved on to using policies to express my requirement but in my case they required so much a priori knowledge in the orchestrator that I'm now moving the required logic completely outside of TOSCA . So to conclude I no longer have a use case for occurrences in node template requirement.