Telephony Network Service

[philippemerle]

I would like to report you the following issues I encountered on the telephony network service example:

1. there are several entry_schema: the_entry_type occurrences in many files.
   This one-line form is not allowed by TOSCA 1.3 grammar, but this was allowed by TOSCA 1.2.
   All occurrences should be replaced by entry_schema: { type: the_entry_type }.
2. In profiles/kubernetes/1.0/capabilities.yaml,
   - valid_values: [ ExternalName, ClusterIP, NodePort, and LoadBalancer ]
   should be replaced by
   - valid_values: [ ExternalName, ClusterIP, NodePort, LoadBalancer ],
   i.e. and should be removed.
3. In profiles/kubernetes/1.0/capabilities.yaml,
   metadata is not an allowed keyname of attribute definitions in TOSCA 1.3.
   This keyname was added in TOSCA 2.0.
4. In both asterisk-cnf.yaml and asterisk-vnf.yaml topology_template:substitution_mappings,
   connection is not a capability to map but a requirement to map.
5. there is namespace: cloud.puccini.xxx in each profile.yaml file
   but cloud.puccini.xxx seems to not be a URI as expected by the TOSCA 1.3 grammar.
6. In asterisk-cnf.yaml:node_types:Asterisk:requirements:data-plane
   both ns:Connection and ns:Routing relationship types can match the requirement.
   Perhaps should add relationship: ns:Connection to avoid this ambiguity.
7. In asterisk-cnf.yaml:topology_template:substitution_mappings
   and asterisk-vnf.yaml:topology_template:substitution_mappings,
   the capability deployment is unmapped but its occurrences is [1, 'UNBOUNDED'],
   the capability trunks is unmapped but its occurrences is [1, 'UNBOUNDED']
   and the requirement trunk is unmapped but its occurrences is [1, 1].
8. In profiles/network-service/profile.yaml
Connection is an empty relationship type definition.
   Is valid_target_types: [ Connectable ] missed?
   or should we interpret no valid_target_types as any capability type is allowed?
9. Is node_types:Asterisk:capabilities:connection useful in both asterisk-cnf.yaml and asterisk-vnf.yaml?

I hope these could help to improve this example.

[tliron]

Thanks for taking a careful look at this! There are a lot of different issues here, some typos, some interpretations of the spec, and some problems with the substitution. Give me some time to process them separately and I'll respond back to you.

I wonder if this would be better as a GitHub "discussion" rather an "issue"? Are you OK with that? If so, you can click the "Convert to discussion" link in the bottom right.

[philippemerle]

Thanks for taking a careful look at this! There are a lot of different issues here, some typos, some interpretations of the spec, and some problems with the substitution. Give me some time to process them separately and I'll respond back to you.

Ok, take your time, I'm not in a hurry .

I wonder if this would be better as a GitHub "discussion" rather an "issue"? Are you OK with that? If so, you can click the "Convert to discussion" link in the bottom right.

I agree but I don't see any "Convert to discussion" link. Do you?

[tliron]

Perhaps only admins can do it? In any case, done.

[philippemerle]

@tliron: Any progress on these issues?

[tliron]

Thanks for following up. Not quite yet, the main work now is on fixing the basic K8s and KubeVirt profiles. There is now a profile generator that automatically converts from K8s' OpenAPI specifications to TOSCA. In the process a few things about the profiles are changing. It's still a work in a progress.

[philippemerle]

Thank you for your prompt reply. I am very interesting by this work on a profile generator, could evaluate it and perhaps contribute to it. Is this generator available somewhere?

[philippemerle]

I see the profile generator in https://github.com/tliron/turandot/tree/main/turandot-profile-generator.
Is there a short tutorial explaining how to run this generator?

[tliron]

No tutorial yet, because it's in a lot of flux ... I actually had to rewrite it completely when I realized an old pathway in the K8s code is not well supported. To run it use this script.

It "works" now in the sense that the TOSCA is valid and all the examples have been modified to also validate against it, but ... these are utterly enormous profiles and there's more thought that needs to go into specific types.

The basic concept is that there is an automatic heuristic, but also a somewhat rich annotation language for handling exceptions to the rules. This allows adding object-orientation and controlling the different kinds of entity types (nodes, capabilities, data) that TOSCA adds to the mix.

[philippemerle]

Thank you. I will try this generator asap, but I have already a lot of other works on the table;-)