[OASIS Issue Tracker] Commented: (TOSCA-17) Packaging Format for TOSCA

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/TOSCA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30641#action_30641 ] 

Tobias Kunze  commented on TOSCA-17:
------------------------------------

Java-isms start with the name (JAR -> WAR -> EAR -> CSAR) and continue throughout, most obviously by basing CSAR on JAR, but also stylistically by using e.g. mixed-case symbols with dashes as word separators. (The C-style  choice would be lowercase with underscores, 90's-style would be camel case, W3C-style would be lowercase with dashes, etc.; The Apple Way™ would probably eschew all of these in favor of human-readable regular case with spaces as word separators. Cultural clues matter for adoption!)
 
Instead, for instance, we could simply prescribe a ZIP format and then define our own tree structure inside it and only include meta files to the extend that TOSCA deems necessary. E.g.
 
./
├── directory1
├── directory2
├── directory3
├── directory4
├── file1
├── file2
├── file3
├── file4
├── file5
├── file6
└── tosca/
    ├── files.yml
    ├── manifest
    ├── service-template.yml
    ├── signature.asc
    └── version
 
would be probably very close to sufficient. The "files" file could contain ownership/permissions instructions, manifest could be a simple Unix-style (":"-separated, one line per file) database, version would give the CSAR version the archive follows, etc. Most importantly, it would be minimal, culturally agnostic, and it would not carry silly stuff from 15 years ago over to the modern age such as the 72 char limit in the JAR spec. I realize it would be simpler to base CSAR simply on JAR, but the big opportunity here is that we can make it much simpler than that.
 
Does that make sense?
 
To summarize, I think we need to make 3 decisions:
 
1. *Archive Format*. I believe everyone is OK with ZIP from a platform-independence perspective

2. *Layout*. We have 3 different types of files: Archive meta data (version, signature, ...), TOSCA meta data (manifest, service template, ...), and the Payload tree. All three could be flat ("X" in the notation below) or in their own directory ("[X]"). With that said, I can think of 3 basic structures:

    1. *All flat*: [A T P] or [A [T] [P]] or any mixture thereof
    2. "A outside, rest inside*: [A [T P]], etc.; this has been traditionally more popular with tar/cpio-based archives but matters less with formats where files are directly addressable such as ZIP 
    3. *A lumped together with T*: [[T A] P]; the example above uses this format

3. Format of TOSCA-defined files. These could be

    1. *All uniform* (XML or YAML) or
    2. *Heterogenous* based on intended use: e.g. Service Template XML or YAML, Manifest parseable for Unix tools, signature consumable for PKI tools, others for human consumption, etc.
 

My preference would be 1, 2.3 and 3.2.
 

> 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