Open Stack

Meeting 1 was conducted on Monday and consisted mostly of freeform discussions, clarification, and QA: http://irclogs.solum.io/2013/solum.2013-12-02-17.05.html.  The next meeting is Monday, December 9, 2013 1700 UTC.

Wiki: https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts

Action and open topics:

* Updated proposal wiki with personas
* Discussed whether a single command or multiple commands are needed to transform an image (one for build+test, or two)
** Believe 1 is sufficient to encapsulate the entire transformation, use cases are needed to justify extras.
* The parent blueprint and wiki page represents the general design and philosophy, and specific child blueprints will target exact scenarios for milestones
* [NEXT] Helpful discussion on the injection of artifacts such that the transformation script can operator on them.  No clear design, but lots of suggestions
* Strong consensus that the the transformation script should depend on Solum or OpenStack concepts - a developer should be able to debug a transformation by using the image themselves, or run it outside of Solum.
* Should anticipate that the transformation environment and execution environment might have different resource needs - i.e. Java maven may require more memory than Java execution
* [NEXT] Should the transformation happen inside the environment the app is destined for (i.e. able to reach existing deployed resources) or in a special build env?
** No consensus, arguments for and against
** Transformation environments may need external network access, production environments may not allow it
* Transformation should remove or disable debugging or compile tools prior to execution for security - this is a recommendation to image authors
* The final execution environment may dynamically define exposed ports that Solum must be aware of
** For M1 the recommendation was to focus on upfront definition via metadata
* [AGREED] No external metadata service would be part of Solum, any metadata that needs to be provided to the image during transformation would be done via injection and be an argument to prepare
** That might be via userdata or docker environment variables and bind mounted files