Re: [tosca] Proposal for requirement "occurrences"

[Tal Liron <tliron@redhat.com>]

On Fri, Feb 4, 2022 at 8:11 PM Chris Lauwers <lauwers@ubicity.com> wrote:

• Creation of the representation graphs does not cause anything to run in the real cloud, nor does it require information from systems running on the cloud. All thatâs required is:

• One or more templates from the catalog
• Input values
• Access to node representations in some inventory.

You write this as if it's obvious and non-problematic. But nowhere did we talk about catalogs and inventories. An inventory is, in any meaningful way, in the real cloud or part of it. If you have a pool of virtual machines and one must be allocated for your service, well, it would be removed from that pool. So the only way your "dangling" scheme can be tested is to run it against an actual cloud.

Maybe you are expecting that Day 0 validation would happen against some fake cloud that has a limitless inventory. Well, in that case it's pointless to even mention the inventory -- all the "dangling" requirements would always be fulfilled from this infinite source. And that's why, if I concede to this feature, I understand it as postponing "actual" validation to Day 1.

Â

I thought all of this was perfectly clear when we agreed to the Operational Model in Section 4. To further clarify and to avoid this type of confusion in the future, I propose we do the following:

Â

• Cleary define which activities take place during Design (Day 0), Deployment (Day 1), and ongoing management (Day 2)
• Further split up Service Deployment into two phases:

• Service Provisioning: the creation of a complete service representation graph in inventory
• Service Activation: taking the actions required to ârealizeâ the representation graph on the external platforms.

Unless anyone objects, Iâll update the document accordingly.

I object to you updating the document on your own, because we obviously have very different ideas about what is possible in Day 0.

I think you need to define "catalog" and "inventory". Personally, I think both should be out of scope for TOSCA, surely not part of the minimal TOSCA processor we agreed upon. These terms don't always mean something in every platform or orchestration environment. In many cases the "inventory" is the platform itself. But we still want the minimal TOSCA processor to be feature-complete.