[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: Query regarding get_artifact function used in implementation definitions with Tosca Yaml
|
FYI. I took the liberty of forwarding David Webster’s question about artifacts.
Thanks, Chris From: Dave Webster (davwebst) <davwebst@cisco.com> ----- start message ----- Dear Tosca community Can you help us to clarify the usage of the
get_artifact function in a Tosca Yaml specified as a value for an
implementation definition, found in this document: Specifically this section:
3.6.16.2.1 Short notation for use with single artifact
The following single-line grammar may be used when only a primary implementation artifact name is needed:
This notation can be used when the primary artifact name uniquely identifies the artifact, either because it refers to a named artifact specified in the artifacts section
of a type or template, or because it represents the name of a script in the CSAR file that contains the definition. When specifying the implementation value (defined as “primary_artifact_name” above), is it valid to use the
get_artifact function, such as: == 1 == interfaces: Vnflcm: instantiate: implementation: {get_artifact: [SELF, CREATE_ROUTER_SCRIPT]} . . . artifacts: CREATE_ROUTER_SCRIPT: type: tosca.artifacts.Implementation.Python description: Generate chassis identifier file: ../Files/Scripts/create_router.py The text description does not seem to explicitly forbid the
get_artifact usage in this case, but I wanted confirmation as this is a point of slight confusion at the moment. OR, must a referenced artifact have only be referenced directly by name, such as: == 2 == interfaces: Vnflcm: instantiate: implementation: CREATE_ROUTER_SCRIPT . . . artifacts: CREATE_ROUTER_SCRIPT: type: tosca.artifacts.Implementation.Python description: Generate chassis identifier file: ../Files/Scripts/create_router.py OR, are both valid? I do realise that the actual script name “../Files/Scripts/create_router.py” can be specified for the implementation value such as: == 3 == interfaces: Vnflcm: instantiate: implementation: ../Files/Scripts/create_router.py But unfortunately, this isn’t an option at the moment. Much thanks for any input. Cheers and have a good day! Dave Webster Software Engineer Cisco Systems From: Dave Webster (davwebst) Hi Chris, Thanks so much for responding – as someone who is unexpectedly and frequently thrust to the forefront of Cisco client support, I do realise ad-hoc queries are an unwanted distraction at busy times, so much appreciated!
Yes, if you or any colleagues are aware of any conscious or intentional restrictions (documented or planned) on intrinsic or property functions (specifically
get_input) usage within TOSCA Yaml constructs, then that would be great to know.
The two get_input usage situations in question are the one described in my original email, and also the one described below where it
is used in sub or child properties. For example, the following is from the ETSI SOL001 2.7.1 spec (based on the TOSCA 1.2 spec): dbBackend: type: MyCompany.nodes.nfv.Vdu.Aux
properties: ... configurable_properties: additional_vnfc_configurable_properties: name_prefix_in_vim: { get_input: name_prefix_in_vim } dns_server: { get_input: dns_server } An industry colleague is questioning the legality of
dns_server and
name_prefix_in_vim having their values set with
get_input, when they are not direct children of the main properties element, as he believes the TOSCA spec demands. Said same industry colleague has now also placed a similar question on the tosca-comment mailing list. I will use this list going forward. Thanks again and have a great day! Dave Webster From: Chris Lauwers <lauwers@ubicity.com>
Hi Dave, Thanks for reaching out and I’m happy to receive these kinds of questions. If you want to reach the broader community of TOSCA experts, you can always use the
tosca-comment@lists.oasis-open.org email distribution list. With respect to your question, you are correct that this is insufficiently documented in the Version 1.3 spec. I personally don’t see any issue with the use of get_input functions inside metadata, but I’ll check to see if there are dissenting
opinions. I’ll keep you informed. Thanks, Chris From: Dave Webster (davwebst)
davwebst@cisco.com Good Day, Chris, Apologies for emailing you without prior consent or context.
My name is David Webster, a senior software engineer working for Cisco UK on their ETSI OSS VNFM and NFVO product offerings. Chris, I had a query regarding the TOSCA Simple Profile YAML Version 1.3, specifically about the usage of the
get_input property function, and I noticed your name against minor revision comments within the document, hence me reaching out to you. If you are not the correct person, please accept my apologies with hopes you may point me in the direction of another colleague or collaborator. We are currently discussing with another vendor about in what situations within a TOSCA 1.3 compliant Yaml file (using SOL001 2.7.1 constructs) get_input may be used. We have a node which looks as follows: c1_nic1: type: cisco.nodes.nfv.VduCp properties: layer_protocols: [ ipv4 ] order: 1 virtual_network_interface_requirements: - support_mandatory: true metadata: security_groups: { get_input: VIM_NETWORK_MGMT_SEC_GRP_0 } requirements: - virtual_binding: c1 But are being queried about the security_groups value, with the concern being that “tosca
functions are not allowed inside metadata.” Myself and colleagues have thoroughly read through the 1.3 specification, and we can see no explicit restrictions on the usage of
get_input. I was wondering if you had any comments which may clarify the situation. Much thanks for your time, really appreciate it. Have a great day. Dave Webster Senior Technical Lead Cisco Systems UK |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]