Chat transcript from room: tosca
2013-03-11 GMT-08:00
[08:04] Matt Rutkowski (IBM): Matt called meeting to order at 10:05 US Central
[08:06] Matt Rutkowski (IBM): Move to approve mtg minutes from 2-25, Dale and Thomas 2nd, on objs.
[08:08] Matt Rutkowski (IBM): Is use of EVs documented?
[08:09] Matt Rutkowski (IBM): Thomas believes Frank submitted this, need to verify
[08:09] Matt Rutkowski (IBM): Derek believes this is documented
[08:11] Matt Rutkowski (IBM): With the method in the Implementers Recommendation, the definition of Interface seems useless, is this true?
[08:12] Matt Rutkowski (IBM): Thomas: true to some extend, the itfc defns. are not useless, operations supported are stillused
[08:12] Matt Rutkowski (IBM): Thomas: scripts are still associated with operations
[08:12] Matt Rutkowski (IBM): Thomas: in regard to properties, yes these are not used from operations
[08:13] Matt Rutkowski (IBM): Thomas: for use cases we have used so far, it seemed that it was convenient to use env. vars
[08:14] Matt Rutkowski (IBM): Aaron: defns. are allowed but not used, does not seem what TOSCA had intended
[08:14] Matt Rutkowski (IBM): Derek: the reason the use cases work without defining parms. is that all implicit context is auto. extracted and made available to scripts
[08:14] Georg Dittmar (scribe SAP) morphed into Georg Dittmar (SAP)
[08:15] Matt Rutkowski (IBM): Derek: if you want to pass explicit parm to a script that is complicated, since you have to describe par, itself and how the model passes it. Better addressed in prot. API.
[08:16] Matt Rutkowski (IBM): Derek: another use of operations is to invoke them from a client (abstract), in this case client would provide parms.
[08:16] Matt Rutkowski (IBM): Derek: what we are doing today is declarative approach, client is the TOSCA orchestrator
[08:16] Matt Rutkowski (IBM): Derek: it implicitly calls the scripts
[08:17] Matt Rutkowski (IBM): Derek: in imper. approach we would have to pass parms
[08:18] Matt Rutkowski (IBM): Derek: Need an imperative use case to show invoking script with explicit parm.
[08:20] Matt Rutkowski (IBM): Thomas: if you tink about this, we would need some declaration of where these parms come from.
[08:21] Matt Rutkowski (IBM): Dale: follow-up. It seems that we are hinting at a ref. mech. like xpath? i.e. way a parm is passed to an operation
[08:21] Matt Rutkowski (IBM): Thomas: perhaps in addition to xpath may need ID to node (to connect to model)
[08:22] Matt Rutkowski (IBM): Dale: in order to avoid complications of going to data types, it may be good to throttle down parms to pass them as args to command processor
[08:22] Matt Rutkowski (IBM): Dale: avoid types, use strings perhaps
[08:23] Matt Rutkowski (IBM): Dale: If people use perl, python etc this could complicate things
[08:23] Thomas Spatzier (IBM): When thinking about about additional things: some kind of simple "mapping language" would be good to declare where a parameter for an operation comes from in the TOSCA topology model to avoid the hard convention that scripts must access environment variables having the exact same spelling as node type properties
[08:23] Matt Rutkowski (IBM): Derek: for shell, agree. for other things not including type info (only 1 string per parm) would cause more issues than those you attempt to avoid
[08:24] Matt Rutkowski (IBM): Derek: especially for complex types like a Map or List
[08:26] Matt Rutkowski (IBM): some parameters are created dynamically and intermediately , how to make EVs for this kind of parameters? Which scripts will be responsible for this job?
[08:26] Matt Rutkowski (IBM): Aaron: some parms come from calculations, not available at the start
[08:27] Matt Rutkowski (IBM): Aaron: are there any scripts that will create these kind of EVs
[08:28] Matt Rutkowski (IBM): Aaron: for example. the result of some calculation of other parameters
[08:29] Matt Rutkowski (IBM): Derek: this is feasible, vars that are not defined at start of orch.
[08:29] Matt Rutkowski (IBM): Derek: vars that are function of dep. such as IP address of a resource
[08:30] Matt Rutkowski (IBM): Derek: vars need to be defined at point of execution, for decl. not an issue. for imper. it is an issue.
[08:31] Matt Rutkowski (IBM): Derek: are names known are values known
[08:31] Matt Rutkowski (IBM): Derek: state orch. comp. state into account
[08:33] Matt Rutkowski (IBM): Derek: these are alluded to ideas, if a script computes a value and wants to make it avail...
[08:33] Matt Rutkowski (IBM): Derek: talked about in TOSCA in terms of workflows
[08:36] Matt Rutkowski (IBM): Thomas: current way impl... the way we pass values from one script to anpother is by storing in topology (TOSCA orchest.) the return values of one node would map to another property of a node
[08:37] Matt Rutkowski (IBM): Thomas: the node/topology would have to have a defined property to be written back to
[08:40] Matt Rutkowski (IBM): Aaron: if the value is to be written back, this could be complicated (writing back from script to env vars)
[08:40] Matt Rutkowski (IBM): Aaron: after exec. of new bash, there will not be a place/job to write back these things to env. vars.
[08:40] Matt Rutkowski (IBM): Thomas: there must be a TOSCA aware engine aware of the topology (orchestrator)
[08:41] Matt Rutkowski (IBM): Thomas: this engine creates these EVs and creates new ones and stores them back to the topology
[08:43] Matt Rutkowski (IBM): Aaron: creating new bash implementors choice?
[08:44] Matt Rutkowski (IBM): Derek: have to do many things to manage import/export parms as long as done consistently its fine
[08:44] Matt Rutkowski (IBM): Derek: in our use cases the script are running in the VMs you are deploying
[08:46] Thomas Spatzier (IBM): I think this is really implementation detail and up to the implementer's choice. Opening a new bash for each invocation is just the most simple approach with less risk for polluting the environment with data from previous invocations.
[08:48] Matt Rutkowski (IBM): Derek: I would create a new bash for each script (what we did in our impl.)
[08:50] Aaron(Huawei): Detailed example is highly expected
[08:51] Matt Rutkowski (IBM): Thomas: could describe an example according to example just explained.
[08:54] Matt Rutkowski (IBM): How to ensure that all necessary Evs will be created by a new bash? Or in other words, according to what the TOSCA container will decide the content of the new bash?
[08:54] Matt Rutkowski (IBM): Derek: yes resp. of the engine
[08:54] Matt Rutkowski (IBM): How can the container know that which properties will be mapped to Evs for each target VM? If the same new bash is executed in all target VMs, then redundant Evs are unavoidable.
[08:55] Matt Rutkowski (IBM): Derek: again containers job of how engine is managing the orchestration
[08:55] Matt Rutkowski (IBM): Derek: perhaps having some examples it might help, sugarCRM it may be obvious
[08:56] Matt Rutkowski (IBM): How can the container know that which properties will be mapped to Evs for each target VM? If the same new bash is executed in all target VMs, then redundant Evs are unavoidable.
[08:56] Matt Rutkowski (IBM): Thomas: most naming conflicts can be avoided by creating a new environment
[08:56] Matt Rutkowski (IBM): Derek: we need to work on naming of vars and perhaps prefix them with "TOSCA" we had chance of collisions (like ip address)
[08:57] Matt Rutkowski (IBM): Derek: good to have clear naming conventions for TOSCA. but agree with Thomas, new bash should clear up and should be a best practice.
[08:58] Matt Rutkowski (IBM): Move to adjourn, Dale 2nds, no objs