RE: [tosca] Proposal for requirement "occurrences"

[Chris Lauwers <lauwers@ubicity.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:

o One or more templates from the catalog

o Input values

o 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.

Iâm talking about concepts, not implementations. Assuming you still agree with the Operational Model, then the ânormalized topology templatesâ need to be stored somewhere, even if only temporarily. Could be in the processorâs memory, in the file system (even a /tmp directory) or in a database. How itâs implemented doesnât matter. Whatâs important is that these templates exist and can be found and retrieved. Iâm using the word âcatalogâ to represent the fact that normalized templates are kept somewhere from which they can be found and retrieved.

The same goes for âinventoryâ. And yes, you can use the âplatformâ as your inventory, but that defeats the purpose of model-driven management (which is the strength of TOSCA). In model driven management, you operate on âmodelsââthe digital twins, if you will. These models are stored somewhere (could be in the orchestrator memory) but the place where theyâre stored is what I call the âinventoryâ.

 

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.

Day 0 validation is about checking correctness of the template (or profile), just like a compiler checks whether a program is valid. Nothing more, nothing less. Day 0 validation cannot check if the âprogramâ will never incur any runtime errors.

 

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:

o Service Provisioning: the creation of a complete service representation graph in inventory

o 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.

In order to make progress, we discussed the idea of proposing updates and then voting. We cannot keep postponing decisions indefinitely.

 

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.

Nothing I have suggested precludes a âminimal TOSCA processorâ.

 

Chris