Well, at least until TOSCA 1.3 this was not in spec, so I think this could at best be a proposal for TOSCA 2.0. If we do so, I'm not entirely sure this would be a good idea. One of the things we discussed (but don't think we decided on) was that metadata values could be any arbitrary unvalided YAML, not just strings. If we decide that it's actually a value ... well, it's untyped. We discussed maybe supporting an "any" type in TOSCA, so that might be what happens here. But also, I'm concerned that this could lead to poor designs, a way to "sideload" properties into node templates and breaking the OOP contract. What's next, a get_metadata function? Once we allow metadata to parameterized it becomes ... data. This is not necessarily a terrible thing, but it's a big change and deserves more examination. On Wed, Apr 21, 2021 at 11:57 AM Chris Lauwers <
lauwers@ubicity.com > wrote: I received an interesting question about whether it is legal to use intrinsic functions inside metadata, as shown in the following example: 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. I personally don t see any issue with this, but I m curious if anybody feels differently? Thanks, Chris