Hello,
Per TOSCA YAML v1.2, the Import definition (section 3.6.8.1) indicates that file keyname is required. However, the grammar for single-line grammar shows “file” is not required. This seems to be inconsistence with table in section 3.6.8.1.
Is it correctly assumed that for Single-line grammar, the “file” keyname is not required, per section 3.6.8.2..1
Snipped from TOSCA YAML v1,2
1.1.1
Import definition
An import definition is used within a TOSCA Service Template to locate and uniquely name another TOSCA Service Template file which has type and template definitions to be imported (included) and referenced within another Service Template.
1.1.1.1
Keynames
The following is the list of recognized keynames for a TOSCA import definition:
|
Keyname
|
Required
|
Type
|
Constraints
|
Description
|
|
file
|
yes
|
string
|
None
|
The required symbolic name for the imported file.
|
|
repository
|
no
|
string
|
None
|
The optional symbolic name of the repository definition where the imported file can be found as a string.
|
|
namespace_prefix
|
no
|
string
|
None
|
The optional namespace prefix (alias) that will be used to indicate the
namespace_uri
when forming a qualified name (i.e., qname) when referencing type definitions from the imported file.
|
|
namespace_uri
|
no
|
string
|
Deprecated
|
The optional, deprecated namespace URI to that will be applied to type definitions found within the imported file as a string.
|
1.1.1.2
Grammar
Import definitions have one the following grammars:
1.1.1.2.1
Single-line grammar:
|
imports:
- <URI_1>
- <URI_2>
|
1.1.1.2.2
Multi-line grammar
|
imports:
-
file: <file_URI>
repository: <repository_name>
namespace_uri: <definition_namespace_uri> # deprecated
namespace_prefix: <definition_namespace_prefix>
|
In the above grammar, the pseudo values that appear in angle brackets have the following meaning:
- file_uri: contains the required name (i.e., URI) of the file to be imported as a
string.
- repository_name: represents the optional symbolic name of the repository definition where the imported file
can be found as a string.
- namespace_uri: represents the optional namespace URI to that will be applied to type definitions found within
the imported file as a string.
- namespace_prefix: represents the optional namespace prefix (alias) that will be used to indicate the default
namespace as declared in the imported Service Template when forming a qualified name (i.e., qname) when referencing type definitions from the imported file as a
string.
1.1.1.2.3
Requirements
-
The imports key “namespace_uri” is now deprecated. It was intended to be able to define a default namespace for any types that were defined within the Service Template being imported; however, with version 1.2, Service Templates MAY now declare their own default
Namespace which SHALL be used in place of this key’s value.
-
Please note that TOSCA Orchestrators and Processors MAY still use the”namespace_uri” value if provided, if the imported Service Template has no declared default Namespace value. Regardless it is up to the TOSCA Orchestrator or Processor to resolve Namespace
collisions caused by imports as they see fit, for example, they may treat it as an error or dynamically generate a unique namepspace themselves on import.
1.1.1.2.4
Import URI processing requirements
TOSCA Orchestrators, Processors and tooling SHOULD treat the
<file_URI> of an import as follows:
-
URI: If the <file_URI> is a known namespace URI (identifier), such as a well-known URI defined by a TOSCA specification, then it SHOULD cause the corresponding Type defintions to be imported.
-
This implies that there may or may not be an actual Service Template, perhaps it is a known set Types identified by the well-known URI.
-
This also implies that internet access is NOT needed to import.
-
Alias – If the <file_URI> is a reserved TOSCA Namespace alias, then it SHOULD cause the corresponding Type defintions to be imported, using the associated full, Namespace URI to uniquely identify the imported types.
-
URL - If the <file_URI> is a valid URL (i.e., network accessible as a remote resource) and the location contains a valid TOSCA Service Template, then it SHOULD cause the remote Service Template to be imported.
-
Relative path - If the <file_URI> is a relative path URL, perhaps pointing to a Service Template located in the same CSAR file, then it SHOULD cause the locally accessible Service Template to be imported.
-
If the “repository” key is supplied, this could also mean relative to the repository’s URL in a remote file system;
-
If the importing file located in a CSAR file, it should be treated as relative to the current document’s location within a CSAR file’s directory structure.
-
Otherwise, the import SHOULD be considered a failure.
1.1.1.3
Example
The following represents how import definitions would be used for the imports keyname within a TOSCA Service Template:
|
imports:
- some_definition_file: path1/path2/some_defs.yaml
- another_definition_file:
file: path1/path2/file2.yaml
repository: my_service_catalog
namespace_uri: http://mycompany.com/tosca/1.0/platform
namespace_prefix: mycompany
|
Thinh Nguyenphu
Nokia Networks
thinh.nguyenphu@nokia.com
+1 817-313-5189