OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 2015-06-01 Interop. SC minutes


Minutes for 2015-06-01 GMT-08:00
Attendees: Matt, Paul, Karsten, Chris, Jurgen, Don, apologies from Sahdev

[08:09] Matt Rutkowski (IBM): vahidhashemian@us.ibm.com
[08:15] Matt Rutkowski (IBM): The OSCON demo has the following tiers: App Tier + DB Tier + Monitoring service Tier
[08:16] Matt Rutkowski (IBM): Montoring Service Tier has Elasticsearch + LogStash + Kibana (ELK)

[08:16] Matt Rutkowski (IBM): App tier is monitored via rsyslog + collectd
[08:34] Matt Rutkowski (IBM): Please contact Vahid Hashemian ( vahidhashemian@us.ibm.com ) for any questions on OpenStack Heat-Translator processing of the ELK CSAR for OSCON, this is his primary responsibility.
[08:39] Matt Rutkowski (IBM): Paul asked Matt if he could share the OpenStack abstract to the TME group for repurposing for OSCON
--------------------------------
[08:41] Matt Rutkowski (IBM): Here is the abstract we are using for an Austin openStack comference:
[08:41] Matt Rutkowski (IBM): Portable orchestration for containers in OpenStack Ton Ngo, Matt Rutkowski, Vahid Hashemian, Sahdev Zala With the rapid growth of container, there are many ongoing effort to manage containers such as Kubernetes, Swarm, etc. Associated with these managers are different methods for describing the orchestration for container in the form of yaml or json files. Although these efforts will greatly benefit the community, they can also create confusion since the users will have to choose among the different methods. TOSCA is a standard that has been developed in OASIS with broad support from major companies. As a domain specific language for orchestration, TOSCA provides a portable way to develop orchestration templates that will work across different container managers and technology. This will help to preserve the investment by companies in developing and deploying container solution. In addition, the containers described in TOSCA template will be integrated with other infrastructure components such as storage and networking. For OpenStack in particular, the result is a high level orchestration template describing both containers and infrastructure that can be deployed onto any OpenStack cloud. In this talk, we will show working example of TOSCA template for containers and demo a translator that generates the container descriptor together with the Heat template.
-----------------------------------
[08:45] Matt Rutkowski (IBM): original Abstract for Vancouver:
[08:46] Matt Rutkowski (IBM): The Heat-Translator project, which translates portable TOSCA workloads to Heat Orchestration Template (HOT), has recently become an official OpenStack project under Heat. TOSCA, supported by cloud service and tooling providers such as Alcatel-Lucent, CA Technologies, Cisco, Fujitsu, Gigaspaces, HP, Huawei, IBM and others, is finalizing a first version of its specification in YAML for release in the 1H 2015. In this session, we will cover the phenomenal progress that has been made in TOSCA specification and the Heat-Translator since the Paris summit. We will show how a variety of TOSCA templates can be easily mapped to Heat Orchestration Templates and leverage some new Heat features like SoftwareComponent which supports TOSCA's full software life-cycle operations. We then will look at the latest and greatest TOSCA models which includes Neutron-style networking and Containers including Docker using real-life use case. TOSCAs lan! dmark design allows application authors to decouple their templates from networking concerns enabling customer choice in the best network for their current deployments.
----------------------------------------
[08:48] Matt Rutkowski (IBM): Storyline for vbrownbag includes:
[08:48] Matt Rutkowski (IBM): TOSCA Parser Our first topic of conversation was the TOSCA parser development and the incredible strides we have made since we were recently elevated from the StackForge project to an OpenStack project under the Heat program. The team has put in a lot of work to capture the recent changes in the TOSCA Simple Profile in YAML specification. Some of the ongoing efforts to add in new TOSCA support and update related functionality are enumerated below. Networking: TOSCA specs has completed networking modeling and parser work is going on to provide support for networking node, related types used to describe logical network information, port definition and network endpoint capability with a single port or a complex endpoint with multiple ports. Support for new TOSCA capabilities: New capabilities have been introduced in the recent revision of the current specification. Besides new networking endpoint capability, other major capabilities that need a new implementation include specialized database endpoint capability and TOSCA compute capabilities for operating system and scalability. Cloud Service Archive (CSAR): The TOSCA CSAR is a container file. It typically includes a TOSCA service template containing reference to one or more file definitions of needed TOSCA base types as well as custom types and all artifacts that are required to deploy and manage lifecycle of the corresponding cloud application. The original CSAR specification, developed for the TOSCA XML specification, needs to be updated considering new features added in the ongoing TOSCA Simple Profile in YAML specification. The parser, which currently is tested with the YAML template, also needs to support CSAR as an input. Enhanced validation: The parser does a good job validating various sections and properties of service template but misses validation for nested sections specifically for interfaces and capabilities. Work is in progress to correct these issues so that there is better validation of TOSCA templates. Containers, Monitoring and Policies: The modeling of container semantics is in progress by the TOSCA Container Ad Hoc Working Group. A similar effort is going on for monitoring types as well by the Monitoring Ad Hoc Working Group. Policies are generally used to convey a set of capabilities, requirements and general characteristics of an entity and this work is in progress too. As these things are addressed in the TOSCA specification, the TOSCA translator team will be working diligently to consume these new requirements and update the code accordingly. Other major items: The support for node substitution, artifacts definition, new topology_template section, modified requirement definition, implementation of setting output variables to an attribute and updated definition with new or renamed properties and attributes etc.
---------------------------------------
Adjourned at 10:56 local time


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]