[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=30675#action_30675 ] 

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

> Second, we seem to agree [...]

I propose we simplify the CSAR format to 2.3 above, i.e. have one reserved directory named "tosca" at the root level containing all of A and T, and everything P flat (i.e. not in a reserved directory) at the top level as well. Why require two directories, "Meta-Inf" and "ServiceTemplate", when one will do just as well? Also, "tosca" avoids the "META-INF" Java-ism.

> Third, [...]

"flat" refers to the payload being flat ("exploded") in the tree (e.g. [[T A] P]) vs in its own reserved directory (e.g. [[T A] [P]]). There are no restrictions on how P is organized internally.

> Note, that we said that the CSAR spec is "inspired" by the JAR spec [...]

AFAICS we don't need to adopt anything from JAR. We need to make the three decisions mentioned above. The first is already made (ZIP) and the second I suggested to simplify from your

    [Meta-Inf[A]ServiceTemplate[T]P]

to

    [tosca[AT]P]

The third decision concerns the specific content of A as well as its format. This is all standard stuff: signatures, hashes, perhaps a version declaration, none of which needs to come from JAR. In fact, it is so simple, it would be probably more complicated to explain what we don't want from JAR than simply to define it ourselves.


> 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.

I am not a JAR expert, but I have never seen a jAR Manifest express that a certain directory need to be created drwxrwtr-- or a set of files writeable for the www-data group. And even if JAR specified keys for this (again, I don't see this anywhere in the spec), I believe we'd nevertheless want a small DSL that allows users to express such things succinctly. E.g. some codification of "Install everything as the Apache user, but make directory x writeable for the ftp user".


In short, I think we should drop the JAR "inspiration" altogether, decide on the simpler tree layout, and then focus on the content and format of the files that make up A.



> 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