NSD / VNFD ID uniqueness and versioning about son-catalogue

[sonata-jenkins]

Hi Daniel,

we've started a similar discussion in son-schema. I think, that the service descriptors should be identified uniquely by a group-Id, a name, and a version, similar to Java Maven packages https://maven.apache.org/guides/mini/guide-naming-conventions.html. That is, the "id" can be created by humans and is human-readable and understandable.

An "id" as you mentioned it has to be created by a machine, like the service platform, but has nothing to do with the service description, IMHO.

We might still want to have an "id" that identifies the descriptor in a database, but this should be internal to the SP and should not be part of the service descriptor.

Cheers,
Michael

[jbonnet]

What a popular subject! ;-)
Also here son-catalogue#2

[jbonnet]

@dang03: I didn't get your second example; you update the NSD (increase it's version) and get a new ID for it? That might be as it was in T-NOVA, but I don't think that's right... is it?

[dang03]

@jbonnet Exactly, the second example shows an updated NSD with an increased version and it receives a new ID. I think this was the approach used in T-NOVA, following the concept of ID "uniqueness".
The other approach could be to have a NSD updated, with the version increased but keeping the same ID. Then, the catalogue could keep many NSD with the same ID but different versions.
Which approach would you suggest to follow?

[mbredel]

Referencing the discussion in son-catalogue#2, the ID should be service platform internal only. That is, the ID identifies the a descriptor uniquely. Thus, it should be a different identifier for a different version - as Daniel said already :-)

[dang03]

This issue belongs to Service Platform (SP) Catalogues. Moving to son-catalogue-repos (WP4)