[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca] discussion topic for Tuesday's Simple Profile call
Hi all, Stuck on voting line for ages (not losing my spot for ANYTHING!), but will be trying to listen quietly with headphones. Very important conversation. Please appoint a scribe (maybe use the TOSCA chat) so as to make every effort to record attendance and thoughts for Luca and others in the TC who can't make it.
Thanks, From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> on behalf of Luca Gioppo <luca.gioppo@csi.it>
Sent: Tuesday, November 8, 2016 9:32:36 AM To: BOUTIER, LUC; Chris Lauwers Cc: tosca@lists.oasis-open.org Subject: Re: [tosca] discussion topic for Tuesday's Simple Profile call 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: > |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]