[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (TOSCA-17) Packaging Format for TOSCA
[ http://tools.oasis-open.org/issues/browse/TOSCA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30660#action_30660 ]
Frank Leymann commented on TOSCA-17:
-------------------------------------
First of all, we seem to agree on the ZIP format - done.
Second, we seem to agree on the content of the archive: archive metadata (A), TOSCA metadata (T), and payload (P).
- The CSAR proposal uses the /Meta-Inf subdirectory for (A).
- The CSAR proposal uses the /Service-Template subdirectory to store TOSCA metadata (T). Note, that this (T) is typically a *set* of .ste files for modularity reasons (i.e. one of the .ste files may contain the node types and relationship types, another .ste file contains the topology template, yet another file may contain the plans). Because of this set characteristics of TOSCA metadata, the CSAR proposal splits this metadata into two subdirectories, and does not mix this metadata together.
Third, the CSAR proposal does not prescribe how to organize the payload (P). I am not sure why we should add restrictions like "flatness" to the (P) part, but of course if there are technical reasons we need to understand them and reflect them in the spec.
Note, that we said that the CSAR spec is "inspired" by the JAR spec to avoid re-inventing the wheel. This does not mean at all that we adopt restrictions like 72 char limits (such a limit is not in the CSAR spec at all).
The CSAR spec assumes that metadata you mention (permissions, ownership,...) is listed in the manifest block associated to the corresponding file. And, yes, this is what JAR does. This metadata is *not* defined as part of the CSAR spec, because this is artifact specific. I.e. domain specialists are free to define whatever is required to ensure portable behavior of their artifacts.
> Packaging Format for TOSCA
> --------------------------
>
> Key: TOSCA-17
> URL: http://tools.oasis-open.org/issues/browse/TOSCA-17
> Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
> Issue Type: New Feature
> Components: Spec
> Affects Versions: CSD03
> Reporter: Frank Leymann
>
> Specifying a cloud application requires a number of different artifacts. In order to allow self-contained definitions of cloud applications a packaging format is needed that contains all the artifacts making up a manageable cloud application.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]