Re: [tosca] discussion topic for Tuesday's Simple Profile call

["Matt Rutkowski" <mrutkows@us.ibm.com>]

Thanks for the reminder Luca.  We
will discuss the issue on today's call as it is relevant to work we are
doing around artifacts and abstract node.
  
Kind regards,
Matt




From:      
 Luca Gioppo <luca.gioppo@csi.it>
To:      
 "BOUTIER, LUC"
<luc.boutier@fastconnect.fr>, Chris Lauwers <lauwers@ubicity.com>
Cc:      
 "tosca@lists.oasis-open.org"
<tosca@lists.oasis-open.org>
Date:      
 11/08/2016 08:33 AM
Subject:    
   Re: [tosca]
discussion topic for Tuesday's Simple Profile call
Sent by:    
   <tosca@lists.oasis-open.org>

---

Hi all
today I will not manage to join, but I'm very interested
in this issue since I opened a similar question some time ago and as usual
it never got tracktion
https://issues.oasis-open.org/browse/TOSCA-262
 
In my view the TOSCA standard does not specify WHERE or
HOW the orchestrator have to work.
Is something that we give for granted, but there is no
real spec for expressing the fact that the operation have to be executed
 
In chapter 1.2 there is mentioned the usage of chef scripts,
but much as a hint since no other example are given
In  2.1 there is written that "application developer
does not need to provide any deployment or implementation artifact that
contain code or logic to orchestrate ...
In 2.4 example there is no mention on where the DB create
artifact is executed
In 3.5.6 there is no mention on WHERE and HOW the artifact
is used.
 
We can have many use cases where we need to state this
behavioud running away from a "de facto" standard that is not
mentioned to help the implementation of a more complete set of use cases:
 
1) Script to create a DB (could be executed both on the
orchestrator and on the node it depends where we consider useful to have
the DB client installed to do the operation
2) precooking of stuff (my Orchestrator could be implemented
with Puppet: I could write in the puppet master all the nodes needed coming
out of the TOSCA file and than fire up a default VM that will present itself
to the puppetmaster and make the actual installation
3) I could write a Docker file with the info in the TOSCA
and create an image and than generate the container out of it.
 
All these use cases are real and by the way my orchestrator
work like this: I use puppet to generate an image for a container and the
topology get translated into a set of containers that is afterwards placed
in a VM (all this starting from a TOSCA file).
 
So I vote a +1 on the request :D
 
Luca
 >  _________________________________________________________________________
 >  
 >

Il 8 novembre 2016 alle 9.07 "BOUTIER, LUC" <luc.boutier@fastconnect.fr> ha scritto:
 >  
 >  
Hi Chris,
 
I absolutely think that we need indeed a way to specify at the operation level if it should be executed on the node’s host (should be default) or on the management machine (default when the node has no compute host?). And I fully agree that there are many scenarios where it is required.
From security perspective I guess it could be the orchestrator responsibility to sandbox through containers or whatever way the executed code.
From a workflow generation point of view I absolutely think that there will be mix match between orchestrator operated nodes and compute operated nodes but this is not a more complicated challenge to handle than synchronization between 2 different compute nodes that the orchestrator would have to manage so I don’t think it is an issue.
 
Regarding single operation nodes, my main concern actually is that in the current TOSCA model nodes that are not implemented are considered as abstract and must be replaced by the orchestrator with a concrete implementation. In such topologies (implemented by an artifact) this consideration goes away and it should be specified somehow. Also we have to make sure that we have a way to specify the state of every nodes as some images may contains nodes that are installed but not started.
Finally, it is important to note that the usual TOSCA workflow weaving does not apply to these special topology included nodes and connecting relationships that defines pre_configure / post_configure operations is considered as an error (unless the node is left on state created ?).
 
I just want to make sure that all the workflow constraints of using such nodes and interactions with other nodes through relationships is well specified (limitations in supported operations, states of nodes etc.).
I think also that we need a way for people to specify or override the internal nodes that could not have operations specified with some that defines management operations (like start for a node that is created by the VM but not started).
 
I hope I will be able to join the call today but I have a sore throat that makes it hard to speak and I’m not sure I will make it.
 
Luc
 
From: <tosca@lists.oasis-open.org> on behalf of Chris Lauwers <lauwers@ubicity.com>
 >   Date: Tuesday, 8 November 2016 at 05:13
 >   To: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
 >   Subject: [tosca] discussion topic for Tuesday's Simple Profile call
 
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
 
 >