discussion topic for Tuesday's Simple Profile call

[Chris Lauwers <lauwers@ubicity.com>]

During our last Simple Profile call 2 weeks ago, we discussed an idea I proposed to allow having artifacts be associated with entire topologies (whereas before we limited artifacts only to individual nodes). The use case that motivated this idea is the scenario where a VM or Container image contains an entire “virtual appliance” that might consist of a number of software components bundled together with the Operating System on which these software components run. Associating this VM artifact with an entire topology accomplishes two things:

 

-          It correctly models the scenario where the entire topology gets deployed in one single action (just by deploying the VM)

-          In addition, it provides a model of the topology inside the VM

 

I had an action item to flesh out this approach by adding prose to the latest draft of the Simple Profile doc.

 

However, during our discussion 2 weeks ago Luc observed that this approach can’t really be supported by TOSCA today since the only way to deploy things is by running scripts on Compute nodes that “host” software components. Luc is correct, of course, and the use case I’m proposing doesn’t really fit this simple model.

 

Based on Luc’s comment, I suggest that we take a little detour and discuss whether it might be time to extend TOSCA’s deployment model a bit. The “run a script on a Compute node” approach works fine for cloud-based software applications, but not for much else. For example, in ETSI NFV, the assumption is that things will get deployed by making API calls to a Virtual Infrastructure Manager (VIM). VIMs could represent cloud management systems such as OpenStack, but also SDN controllers such as OpenDaylight. If we want TOSCA to be adopted as a “universal” modeling language for all types of entities that need to be deployed dynamically, then we need to support the scenarios where things get deployed by mechanisms other than running scripts on Compute nodes. In fact, the approach of making API calls will likely be a more common scenario than running scripts. The software that makes these API calls will run on (or with) the orchestrator, not on the entities that are being deployed.

 

I’d like to use the meeting on Tuesday to discuss these scenarios:

 

-          How do we specify in TOSCA that “operations” are to be executed by the orchestrator (rather than by Compute nodes)?

-          If the orchestrator runs software that implements these operations, how do we protect the orchestrator from faulty (or malicious) code?

-          Are there any other security concerns?

-          Can interfaces mix and match Compute-hosted scripts and Orchestrator-hosted scripts? If so, are there any synchronization issues between these two types?

 

I’m sure there are other aspects of this approach to discuss. If there are no objections, then I’d like to make this the topic of Tuesday’s discussion.

 

Thanks,

 

Chris