[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=30571#action_30571 ] Tobias Kunze commented on TOSCA-17: ------------------------------------ Issue: Archive format Main candidates are historically cpio, tar and zip, with zip being the de facto platform independent standard. However, zip being largely ignorant about what it zips up creates a number of issues that need to be dealt with. Specifically: 1. Filesystem meta-information needs to be captured and re-created: specifically (*nix) permissions & ownership 2. File meta-information needs to be captured and either prescribed or transformed: specifically, character set and encoding, but also platform-specific conventions such as line endings or byte ordering. E.g. a shell script copied to a Windows system and zip'ed up there will wreak havoc when run after extraction on a Linux system Proposal: * Standardize on ZIP * Require a) that archivers capture filesystem and file meta-information in a suitable location (e.g. the manifest) and b) that extractors restore this meta-information, potentially transforming files in the process (TBD). Issue: Java-isms There is concern regarding basing CSAR on the JAR specification, which I share. Such Java-isms result in a hard sell to non-Java folks and are also often blind to non-Java issues (such as issues resulting from a tighter integration with the operating system). Proposal: * Change the outward appearance of the spec to use generic, functional names rather than names borrowed from the JAR spec. E.g., instead of naming the meta-information directory META-INF, it could be called "tosca". Likewise, instead of calling the manifest "MANIFEST.MF", it could be simply "manifest", etc. There are many good solutions other than JAR and a good goal to have would be to look at (at a minimum) the Debian and RPM package structures and then decide on a new, platform-independent structure that embodies the platform-independent nature of TOSCA. * From a user uptake perspective, I would also propose to use "human friendly" formats wherever possible. For instance, instead of the "geek style" of keywords such as "Manifest-Version" (capitalized with dashes between words) in the JAR manifest, I'd posit that everyone would be much happier with simply "Version". Or, instead of "CSAR-Version", "CSAR Version" (although this is debatable; Debian packages, for instance place the archive structure version deliberately in a single, top-level "version" file). We should strive to keep files as human-friendly as possible, with as many declarations as possible having reasonable defaults (i.e. being optional). > 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]