How to fix relationship type name "AttachesTo" ambiguos error?

[abhishek-kumar0409]

Hi Tal, I am getting the below error: Can you please suggest what is wrong here?

PROBLEMS (2) file:/home/abhishek/projects/parser/etsi_nfv_sol001_vnfd_0_10_0_type.yaml relationship type name "AttachesTo" is ambiguous, can be in "file:/home/abhishek/projects/parser /etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple/1.1/relationships.yaml" relationship type name "tosca:AttachesTo" is ambiguous, can be in "file:/home/abhishek/projects/parser/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple/1.1/relationships.yaml"

My sample TOSCA VNFD imports a "etsi_nfv_sol001_vnfd_0_10_0_type.yaml" definition file. Is it conflicting with the profiles present in the puccini/assests directory or etc. The schema which was present in the ARIA and now in puccini is not up-to-date.

I am new to goLang and hence finding it little tough to understand the semantics and the code flow. Where do I need to place the latest tosca-for-nfv definitions in puccini?

Path-1: puccini/assets/tosca/profiles/simple-for-nfv/1.0 or Path-2:puccini/tosca/profiles/simple-for-nfv/v1_0

What am I suppose to do after I copy the definitions to right place?

[tliron]

Well, even without seeing your YAML I can tell you that the error is probably in your code. You are probably defining a relationship type in etsi_nfv_sol001_vnfd_0_10_0_type.yaml that is called AttachesTo. This is a reserved name in TOSCA, so you are not allowed to do that. Can you verify that this is the case or share that YAML file?

It may have worked in ARIA, but ARIA did not have complete support for namespaces, so it could not check for such errors. Puccini is more comprehensive.

As for looking into the code (thank you!), check out the README. Specifically there is a script called embed.sh that takes everything in the assets dir and turns it into Go code so that it can be compiled into the executable (so that it will be an all-in-one distribution).

[abhishek-kumar0409]

Dear Tal, Thanks much for the reply. I am not sure what is the issue here because I'm new to TOSCA and go Lang. Can I share you the sample vnfd and tosca definitions by email or some other means ?

[tliron]

You should be able to upload files here. Just drag them to the GitHub interface.

[abhishek-kumar0409]

samples.zip

[tliron]

Thanks. OK, I did find a bug, but ... it's really more of an issue of the TOSCA spec as usual being obtuse. The issue is that there is tosca.relationships.nfv.AttachesTo and tosca.relationships.AttachesTo, but by TOSCA semantics both of them should have the same shortcut name, AttachesTo. I will try to think of a different way to determine the shortcut.

[tliron]

Actually, wait a second. I think the TOSCA spec is correct here and that the ETSI NFV profile you are using is wrong.

Here's what it boils down to: the tosca. prefix for type names is reserved for TOSCA internal names. You should not be able to use it for your own special types. I understand that ETSI is considering this file as a proposal for TOSCA, but if they do so I would say that they are in error to use the same type name AttachesTo, because it would conflict with the Simple Profile relationship type. I think Puccini is doing the right thing here and that the error is clear.

The official Simple Profile for NFV doesn't have this problem because it doesn't try to override AttachesTo.

For now you can workaround the problem by search-and-replace: tosca.relationships.nfv.AttachesTo to something else, say, tosca.relationships.nfv.Attaches.

[abhishek-kumar0409]

Hi Tal, The shared definition file is an official one and it's published in ETSI's portal also. I also cross-verified the latest ETSI specification document. And, they have used tosca_definition_version as tosca_simple_yaml_1_2. I can reach out to ETSI for more clarifications.

However, I changed the tosca_definition_version from tosca_simple_yaml_1_2 in etsi_nfv_sol001_vnfd_0_10_0_type.yaml to tosca_simple_profile_for_nfv_1_0 (Simple Profile for NFV). But, this resulted in lot of errors because of the ambiguity issues of the schema definitions with the ones present in the assets/profiles/simple-for-nfv-1.0.

Is this expected from puccini or is it a bug? Posting the errors in the next comment

[abhishek-kumar0409]

PROBLEMS (15) file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml

artifact type name "tosca.artifacts.nfv.SwImage" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/artifacts.yaml"

capability type name "tosca.capabilities.nfv.Metric" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/capabilities.yaml"

capability type name "tosca.capabilities.nfv.VirtualBindable" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/capabilities.yaml"
capability type name "tosca.capabilities.nfv.VirtualCompute" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/capabilities.yaml"

data type name "tosca.datatypes.nfv.AddressData" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

data type name "tosca.datatypes.nfv.ConnectivityType" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

data type name "tosca.datatypes.nfv.L2AddressData" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"
data type name "tosca.datatypes.nfv.L3AddressData" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"
data type name "tosca.datatypes.nfv.RequestedAdditionalCapability" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"
data type name "tosca.datatypes.nfv.VirtualCpu" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"
data type name "tosca.datatypes.nfv.VirtualCpuPinning" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

data type name "tosca.datatypes.nfv.VirtualMemory" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

data type name "tosca.datatypes.nfv.VirtualNetworkInterfaceRequirements" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

data type name "tosca.datatypes.nfv.VnfcConfigurableProperties" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/data.yaml"

relationship type name "tosca.relationships.nfv.VirtualBindsTo" is ambiguous, can be in "file:/home/abhishek/projects/parser/samples/etsi_nfv_sol001_vnfd_0_10_0_type.yaml" or "internal:/tosca/simple-for-nfv/1.0/relationships.yaml"

[tliron]

That would definitely not work, because the internal official Simple Profile for NFV will conflict with this file. So indeed you are getting a lot of name errors.

The file you have is official to ETSI but not OASIS, and the future of the NFV profile is complicated right now. I have been present in a lot of these arguments and I think SOL001 is going down a wrong path. I also think that as long as ETSI decides to make their own proposal, they should not be using the tosca. prefix, as it is reserved for OASIS. Actually, a stricter TOSCA parser might even give you an error if you try to to use this prefix.

I will try to think of a workaround in code -- possibly avoid name shortcuts for any import, even if the reserved word is used. But I think such a workaround is wrong and that ETSI needs to rethink their proposal and avoid redefining Simple Profile type names.

[tliron]

For reference, here is the relevant code in Puccini.

[tliron]

As you can see, I committed a fix that will allow your TOSCA to compile with Puccini without changes. What it does is look specifically for types that are marked as "normative" (so it's not enough for them to have tosca. as a prefix).

But I remain unhappy with what ETSI is doing. If their proposal does become normative, it will still break with Puccini (and any other strict TOSCA parser).

@abhishek-kumar0409 I would greatly appreciate if you follow up and inform ETSI of their error here.

[abhishek-kumar0409]

Hi Tal,

From your reply, it looks like there is a serious issue in SOL-001. I guess you need to pitch in here and express your concerns to the SOL Working group. Not everyone in the community is a SME in TOSCA. This could be the main issue. Never mind, there is a lot of learning curve here. Once I am up-to speed, I will definitely love to work with you and contribute to this parser. Will you be able to join if we can arrange a meetings to address this concern to ETSI folks?

[tliron]

Yes, I will be able to join. I would appreciate if you would help facilitate a meeting. I have a lot of work on my hands already. :)

Also, I would appreciate if you could try to checkout the latest Puccini master and confirm that it solves the issue for you!

[abhishek-kumar0409]

Hi Tal, One last question, the tosca-definitions that you have in the repository is little outdated and also it's incomplete. There have been many new additions and modifications to the existing TOSCA-NFV objects in past...and I don't find them in puccini repository.

The shared ETSI schema definition doesn't contain any metadata section (having information such as normative, specification, etc.) which I could see in puccini repository. I would like to hightlight one such difference that I observe is tosca.nodes.nfv.VDU.Compute:(in puccini) and tosca.nodes.nfv.Vdu.Compute (in ETSI) and many more.

If I replace or update the profiles present in the puccini repo with the ETSI's then there won't be such issue right because I wont be importing any definition file in the VNFD ?

Any thoughts.. ? I tried this approach in aria and it worked for me in the past...!!

[abhishek-kumar0409]

ThanksTal, for the fixes..I will test the code tomorrow and will update you.

[tliron]

Can you please point me to the NFV spec you are referring to? The latest draft is csd04, which is what I followed. It was last updated in May 2017.

[abhishek-kumar0409]

Hi Tal,

Sorry for the delayed response. I was doing some research to find out the list of contributors of csd04. The active contributors of both the documents are same .

The draft csd04 is very very old. The TOSCA schema definition shared earlier by me is the latest spec and it's expected to change again in the next month, The SOL WG is responsible for updating the spec. and releasing it every month. These schemas are uploaded to the ETSI repository. I am sharing the doc in the attachment. The TOSCA Yaml schema definition file shared earlier is also compiled from this word document itself. I thought of contributing these files to ARIA but the community retired it.. :(

NFV-SOL001v0.10.0_clean.docx

[tliron]

OK, so I am aware of the work of SOL. But ETSI is not OASIS. There is a lot of debate on what to do with the profile and which one should be official, or even if it should be official. And there is yet further debate in the ONAP project. TOSCA belongs to OASIS, so I think it makes sense to consider that canonical for now. ETSI might end up proposing their final version to OASIS, and ONAP might, too. When that happens, we should follow. But for now csd04 is the latest official version.

But of course you're welcome to import any types you want. The specific problem we have here is that one ETSI type overlaps with a Simple Profile type.

I think there are many, many more problems. I have made it clear many times that the whole NFV profile approach is flawed, both in OASIS and in ETSI. There should not be separate NFV types. Moreover, the Simple Profile is also quite useless in the real world. Puccini supports these types because they are part of the spec, but anything interesting that Puccini does uses dedicated Kubernetes, OpenStack, etc., profiles.

[abhishek-kumar0409]

Hi Tal,

I have completed the testing of the code. The fixes provided by you worked and I didn't receive any ambiguous issue (due to the namespace collision for the "AttachesTo"). However, new errors started to came in due to ambiguity between the schema imported in my sample VNFD and the simple-tosca-for-nfv schemas present in (i.e. assets/profile) the puccini's repository.

As a workaround, I deleted the simple-profile-for-nfv schema and updated with the ETSI's schema and removed the import statement from the VNFD. With this approach, puccini is able to parse the VNFD correctly.

[tliron]

What are the errors you received? Using the files you attached here I am getting no errors.

[abhishek-kumar0409]

HI Tal,

Sorry for the delayed response. It took me while to reproduce the issue because I have modified the simple-profile-for-nfv. This is the error I received yesterday,,,

PROBLEMS (15)

file:/home/abhishek/projects/parser/samples/sample_tosca.yaml
node_types['MyCompany.SunshineDB.1_0.1_0'].derived_from: field refers to unknown node type: tosca.nodes.nfv.VNF
node_types['MyCompany.SunshineDB.1_0.1_0'].interfaces['Vnflcm'].type: field refers to unknown interface type: tosca.interfaces.nfv.Vnflcm
topology_template.node_templates['SunshineDB'].interfaces['Vnflcm']['heal']: undefined operation
topology_template.node_templates['SunshineDB'].interfaces['Vnflcm']['terminate']: undefined operation
topology_template.node_templates['dbBackend'].requirements[0]: cannot satisfy requirement "virtual_storage"
topology_template.node_templates['dbBackend'].type: field refers to unknown node type: tosca.nodes.nfv.Vdu.Compute
topology_template.node_templates['dbBackendInternalCp'].requirements[0]: cannot satisfy requirement "virtual_binding"
topology_template.node_templates['dbBackendInternalCp'].requirements[1]: cannot satisfy requirement "virtual_link"
topology_template.node_templates['dbBackendInternalCp'].type: field refers to unknown node type: tosca.nodes.nfv.VduCp
topology_template.node_templates['dbBackendIpv4'].requirements[0]: cannot satisfy requirement "virtual_binding"
topology_template.node_templates['dbBackendIpv4'].type: field refers to unknown node type: tosca.nodes.nfv.VduCp
topology_template.node_templates['internalVl'].type: field refers to unknown node type: tosca.nodes.nfv.VnfVirtualLink
topology_template.node_templates['mariaDbStorage'].artifacts['sw_image'].type: field refers to unknown artifact type: tosca.artifacts.nfv.SwImage
topology_template.node_templates['mariaDbStorage'].type: field refers to unknown node type: tosca.nodes.nfv.Vdu.VirtualBlockStorage
topology_template.substitution_mappings.requirements['virtual_link'][1]: requirement not found in node template "dbBackendIpv4": virtual_link

But, I guess there is something wrong here which I am not aware of....

[tliron]

It seems to me that you deleted the imports section on your sample_tosca.yaml. If you re-download the zip you attached above and try it, it should work fine.

[abhishek-kumar0409]

At the same time, I tried setting up puccini in the different server. And, to my surprise puccini was able to validate the VNFD successfully. This test of mine contradicts the above statement. So, I will request you not to invest time. May be some mistake from my end.

It tried with both tosca_definition_version: v1.1 and v1.2 and it worked well. However, validation failer for simple_profile_for_nfv_1_0. I am getting the same error as described in the above comment. This might have happend due to the collision between the imported profile (used in my sample VNFD ) and csd_04 profile present in puccini.

[tliron]

OK, I will close this issue for now because the core issue has been fixed. If something else comes up, please open a new issue.

[abhishek-kumar0409]

Thanks Tal

[tliron]

I do not have videos, but some of this talk is in the context of ONAP discussions.

I do believe in TOSCA as a common language, otherwise I would not be doing this project. But I do think the idea of lowest-common denominator normative types are misguided. A separate profile for NFV is an especially bad idea. Actually, I think most of the community understands that it's not good to split off, but they are also stuck with having to support all these ETSI descriptors. So essentially they shoved these ETSI descriptors into TOSCA. It's a mess.

As for OpenStack, you may have seen that I've started working on a profile. The idea is to duplicate the functionality of Heat in TOSCA (with Ansible as orchestrator). Again, to show that it's crazy to try to unite Kubernetes and OpenStack under the same types. We are talking about entirely different paradigms, architectures, resource types, topologies, etc.

I prefer action to talk, which is why Puccini exists. Actually talk is not very easy in the big communities (ONAP, ETSI, OASIS) due to the many interests on the table from many companies and industries. So I prefer to lead by example. From the FAQ:

Generally speaking, the notion that a single set of normative types could be used for all the various cloud and container platforms out there is a pipe dream. The devil is in the details, and the amount of detail needed for cloud deployment keeps growing and diversifying. Thus every Clout file is vehemently platform-specific. However, by bringing the tiniest implementation details all into one place we can at least have a common tool chain for all platforms. That's the gist of Puccini.

[tliron]

TOSCA = a rich object-oriented grammar for describing cloud topologies. The Simple Profiles are a set of normative types described in the TOSCA language. I'm saying that the former is a good idea but the latter is a dead end.

The assets folder is no less "out of hand" than the official profiles. Sure, they will will evolve, just like Kubernetes 1.11 adds features that Kubernetes 1.10 did not have and new versions of Heat do things that older ones did not. I don't see why this is a problem.

But anyway, these assets are just there as a convenience for distribution. You can create your own types (as well as the JavaScript to process them) and include that in your CSAR. That would be preferable in most cases.

[tliron]

I think your approach is doomed to fail. Especially when you add the word "cloud native" to the mix -- the platform-specific details are just too specific, and that ignores the complete paradigm shift that something like Kubernetes represents.

Of course you are welcome to use Puccini to try to achieve that -- I think it will be much, much easier to experiment using Puccini and its JavaScript as compared to other TOSCA platforms.

[tliron]

The question is what is included in the ring and what isn't. It's about the scope of the ring. :)

I think it's totally acceptable, fine, and manageable to have different types for different platforms. As long as you have one toolchain (TOSCA-based) for all of them, you don't have to keep reinventing the wheel. So instead of using HOT for OpenStack and Helm for Kubernetes you can use TOSCA for everything -- with the native types for each.

I believe telcos will eventually realize this, too. I'm in that conversation and I think there is some evolution in their thinking. But I basically expect that if they continue pursuing this lowest-common denominator for "cloud" they will end up with something unworkable (=failure).

I predict that the solutions will be more about integration of multi-cloud environments (as in edge computing). They will be not about common normative types, but about improvements to the grammar. Better substitution mapping in TOSCA, allowing for something like "generics" that we see in programming languages.

[tliron]

I am certain that we would have to divide into pieces. The question is how do we add them up together. :) (Service composition.) There are many chicken-and-egg problems that the industry has yet to solve: are your VNFs the "workload" for the cloud (meaning that a VNF is just another application) or are they part of the infrastructure that enabled the distributed cloud to exist in the first place?

Whatever the industry decides, TOSCA could be the language for all of it. You can use TOSCA to model your infrastructure (bare metal, OpenStack, SDN) and then use TOSCA to model the applications. Everything a "workload" to something else.

[tliron]

If not "distributed," how else would call the ability to divide applications among several geographies and technologies, some of which might be multi-tenant edge data centers?

Very glad to hear it was easy! The central goal in Puccini is to make these things as easy as possible. I'm all for "one ring" as long as we know its scope. ;)

[pmjordan]

I'll just note here for others who may read this that another cause of ambiguous errors is when a V1.3 template imports definitions which are at v1.2.

[tliron]

@pmjordan Can you explain this more? Is this a bug in Puccini or a user-related issue?

[pmjordan]

Not a bug. A legitimate response of pucinni to poorly constructed template. Mentioned here only because others may make the same error and find this thread when looking for a solution. Users should not attempt to import files which mix version of TOSCA. If they do Puccini will not be able to uniquely identify keywords and will produce an 'ambiguous...' error.

[tliron]

Thanks! I wonder, though, if this should be a spec-level issue. Should TOSCA support importing files from various versions? I will raise this issue in the OASIS group.

[tliron]

Upon further thought, I think this is a Puccini issue after all. Incompatible imports should not be allowed: even if they do not immediately cause a Puccini parsing/compilation error, there could be issues later on due to these incompatibilities. So with the latest commit Puccini will check for compatibility.

However, realizing that "out in the wild" there may be service templates that do import various versions, there is a "imports.permissive" quirk to disable this check. Of course it's expected that you know what you're doing when you use a quirk. :)