1. Questions for Implementers Recommendation
Aaron Zhang，Huawei

2. Brief Understanding of TOSCA Implementer Recommendation
Defines Script Artifact, and proposes to pass parameters through environment variables:
Container is responsible for mapping properties of ServiceTemplate to environment variables (EV) with the same name (in the format of ${name} )
Scripts will read the value of Evs needed during execution
The return value of the execution of a script may be written back to corresponding EVs

3. Questions about the implementation way
With the method in the Implementer’s Recommendation, the definition of Interface seems useless, is this true?
And, some parameters are created dynamically and intermediately , how to make EVs for this kind of parameters? Which scripts will be responsible for this job?
Interface的意义被削弱

4. Questions about the new bash
Why a new bash is needed?
- The capability to map properties to Evs can be provided as an internal feature of the TOSCA container. What’s the value for the new bash?
When the new bash will be created?
The first time when the package is deployed?
What will happen if the ServiceTemplate is changed? Another new bash?
Will the bash become an inherent part of the package? Or in other words, will the new bash be part of the package if the package is exported from the TOSCA container?
Where to deploy the new bash?
- All target virtual machines? EVs redundant?
New bash:应该是container的功能，没有必要生成一个显示的bash脚本

5. Questions about EVs
How to ensure that all necessary Evs will be created by the New bash? Or in other words, according to what the TOSCA container will decide the content of the new bash?
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.
Also, how to avoid name confliction among Evs ?
环境变量怎么放置？