RE: [tosca] Proposal for requirement "occurrences"

[Chris Lauwers <lauwers@ubicity.com>]

 

2) Though I think 2.9.2 is the right way to do it, I'm willing to compromise with the idea of allowing requirement fulfilments to be postponed to runtime, simply because it seems like you'll never agree that 2.9.2 should be the only way to achieve it. However, I cannot agree that this feature would be automatically defined by a heuristic. I would insist that there would be a keyword that a user would have to explicitly set for requirement assignments (and I would discourage people from using it). I dislike the word "dangling" for various reasons, so I would suggest something like "runtime: true". (Calin's suggestion of a "scope" keyword doesn't make much sense to me, because the important aspect is the WHEN and not the WHERE.) In essence the keyword just tells the processor: skip this requirement. It's not your responsibility. It will be fulfilled instead by the orchestrator on Day 1 at the moment the topology is deployed, assuming the orchestrator supports this feature. I imagine many orchestrators can't do this easily if at all, because they would consume the TOSCA topology as an input and cannot go back and change it. (You'll see this in action in my upcoming TOSCA for Ansible demo.) Unless you add an initial pre-orchestration phase ... but I wouldn't consider it worth the effort when 2.9.2 does everything needed without this awkwardness.

 

OK, perhaps weâre getting to the core of the confusion/disagreement. Requirement fulfillment is not at all a question of âWHENâ. The issue of âWHENâ is extremely straightforward. It is either done on Day 0 (Design Time) or on Day 1 (Deployment Time):

 

1. If a designer knows at design time which target node will be used to fulfill a given requirement, then the designer will add an explicit relationship to that target node in the topology template
2. If a designer doesnât know (or doesnât want to dictate) which target node will be used, then the topology template leaves the requirement âdanglingâ and the requirement must be fulfilled at deployment time based on the target capability type, target node type, and node filter specified in the requirement.

 

There really arenât any other options that work in general.  Letâs look at the following code snippet that has an unfulfilled requirement:

 

node_types:

  A:

    derived_from: tosca.nodes.Root

    requirements:

      - dependency:

          node: B

          occurrences: [ 1, 1 ]

 

  B:

    derived_from: tosca.nodes.Root

    properties:

      size:

        type: string

        constraints:

          - valid_values: [ small, large ]

 

topology_template:

 

  inputs:

    size_input:

      type: string

      constraints:

        - valid_values: [ small, large ]

     

  a:

    type: A

    requirements:

      - dependency:

          node_filter:

            properties:

              - size: { equal: large }

 

  b:

    type: B

    properties:

      size: { get_input: size_input }

 

Clearly it is not possible to fulfill the âdependencyâ requirement until input values are available, which is at Deployment time. There is no scenario under which a processor can fulfill the requirement any earlier.

 

So, I agree with Calin. There is no question of WHEN a requirement can be fulfilled. The real question is WHERE a processor/orchestrator will look for target nodes.

 

Chris