1. JAR
Desc
CSAR
Notes
A package file format typically used to aggregate many Java class files and associated metadata and resources (text, images, etc.) into one file for distribution.
JAR files are archive files that include a Java-specific manifest file. They are built on the ZIP format and typically have a .jar file extension.
TOSCA Simple Profile definitions along with all accompanying artifacts (e.g. scripts, binaries, configuration files) can be packaged together in a CSAR file
META-INF
There can be only one manifest file in an archive and it must be at that location.
TOSCA-Metadata (directory )
Contains the TOSCA.meta metadata file that provides entry information for a TOSCA orchestrator processing the CSAR file.
Manifest.mf
A manifest file is a metadata file contained within a JAR.
TOSCA.meta
Provides entry information for a TOSCA orchestrator processing the CSAR file
Manifest-Version
(e.g., 1.0)
Conforms to version 1.0 of the manifest specification.
TOSCA-Meta-File-Version
Version string
Currently, the TOSCA metafile version is tied to the TOSCA spec. version
Future work would separate out the CSAR specification into its own independenly versioned entity.
Main-Class:
(e.g., com.example.MyClassName)
The JVM (for an exec. JAR) needs to know the application's entry point.
An entry point is any class with a public static void main(String[] args) method
Entry-Definitions
[0,1]
Any TOSCA definitions files besides the one denoted by the Entry-Definitions keyword can be found by a TOSCA orchestrator by processing respective imports statements in the entry definitions file (or in recursively imported files).
E.g., Car (type)
E.g., in NFV this is the VNF “Node Type”
Class-Path:
(e.g., . pkg1.jar path/to/pkg2.jar)
Used to specify all the classes that must be loaded for an application to be able to run.
<other-definitions> (name TBD; substitutable-definitions?)
[0,N]
Not applicable to TOSCA at this time.
Future discussion (YAML list)
E.g., Ford Truck, Toyota Camry, etc.
E.g., in NFV these could be the impls. CSAR/STs
Simple Profile WG Notes:
Notes:
Claude: multiple root problem; is this resolved (from list)?
Chris: not completely in sync, needs more discussion
Claude:
from list (Ch. 6); potential update to 6.1
Chris: in 1.2 there is no way to defining mult. service templates in an archive
Steve B., purpose of these exchanges was to clarify usage of mult. entry defn.
Chris/Matt may have diff. views
1) mult. STs in a CSAR 
2) or another purpose
Chris: believes pt. of disagreement may be a single one
Steve: diff. view of how to implement topology subst.
Chris: IMO when u pkg a component it should be packaged as a type THEN mult. entry defn supports can be used to bundle mult. depl. flavors
Alex: disagree.  Need to diff. NFV use cases from enterprise use cases where app. dev. is trying to define a virt, network for an app.
3-tier app., across 3 network clusters, with LB
Matt: can we use car example instead please?
Alex/Chris: discuss
Shitao: depl. flavor same disc. since December
Chris: why not allow top-level / entry template that has a node type
Thinh: top-level should describe topology (form that build rest) == opinion 1
2nd option mult. top. and select from criteria
Chris: back to drawing board in NFV? 
Thinh/Chris: no (laughing)
Alex: do we need mult. views for node?  deploy vs. instance?
Chris: we already have that
Claude: speaking about ??? (missed hearing)
Matt: sees the issue as a “factory” type defn vs. impls. that can be used by the factory
Alex: production and test topologies, depl. VMs/networks may be very different, with diff operational policies
Alex: like the car/tire example
Chris: caps/reqs are how we differentiate in TOSCA (defined in the type)
Shitao: just need clarification for v1.2, but fix in 1.3
Matt: ST is diff. from CSAR, CSAR was intended for processing/depl
Chris: but way of world, majority use cases is to “onboard” impls/types into catalog
Arturo: abstract node type with diff topology templates with diff. depl. flavor
top-level has node type defn. but topology template that had only abstract node
Matt: that approach would be my first instinct with what we have today in spec. (v1.2)
Steve; if i load a million types into a catalog, 
topology templates trigger subst. NEED a template to trigger some form of top. subst. (at depl. time)
Chris: sep. design time vs. depl. time
Steve: 
There is a type defn and lower-level templates
pkged. in ZIP file and delivered
problem: that pkg. is also used for instantiation purposes
Chris: in NFV, these things are clear, service descriptor uses VNF but do not need top-level depl. topology (it will get used in service desc)
Shitao: top-level is just VNF type defn.
higher level is abstract node
Matt: why not have another meta tag? entry defn. for historical use (deploy); new tag for “import” 
Thinh: may still need top. template (top level)
Steve: either a new service or vnf service needs some kind of top. template to start anything
Matt: sees that CSAR/metadata needs to be used for 1) deployment 2) class loading 
Chris: Steve’s main use case is deployment, of VNF as a service all by itself
Steve: VNFD is a type defn only with a bunch of lower level templates, not sufficient IMO
Chris/Steve are in agreement that in order to depl. (understand each other)
Shitao: ST that includes top. template (has vnf), still need Network Service to deploy VNF
Arturo: disagree: standalone is valid use case
Claude: top of hour, will keep going if ppl can stay
Chris: processing is broad term and nothing breaks
Matt: would like to prove out that nothing breaks for legacy
TOSCA Simple Profile WG (notes):
Matt shows slide JAR-CSAR compare, will post to Kavi
Matt propose:
do not break CSAR 1.0 by changing Entry-defn grammar
create new field (to be named later) that mirrors JAR Class-Defintions
i.e., “class” packages to be loaded
Could be subdir. in CSAR (as now) or CSAR that contains CSARs (recursive) as shown by JAR of JARs…
CSAR recursion would be new
Complete ability to define what “load” means (i.e., avail at design time, registry/catalog
if “classes” are never used (by import) during orch./deployment, you simply release memory
link: 
Thinh: Is this for 1.3
Matt: yes, 1.3
Priya: addresses my concerns
Claude: discuss on mailing lists…
Matt: also can separate CSAR spec. from Simple profile spec. …
Claude: would help having sep. document to describe processing…
Arturo: from disc. with Chris, RE: SW image artifact
Chris points out an art. defn. cannot include props.
Claude: just not doc. properly in 1.2 spec.?
Matt: Chris ind. that he wanted to propose Artifact template defn (topology); and then propose we add properties
Matt: we left Properties out of 1.2 unintentionally… we had some text / example left incomplete, but of course Artifact Processors were introduced in 1.2, which would need parameters hence we would need Properties (and Attributes) on Artifact Types and any new Artifact Template.