search

sonata-nfv / son-catalogue

SONATA's SDK Catalogue
http://www.sonata-nfv.eu
Apache License 2.0
1 stars 2 forks source link

Package IDs to be used #2

Closed jbonnet closed 8 years ago

jbonnet commented 8 years ago

Will we use 'small integers' IDs, or should we go for a UUIDs?

mbredel commented 8 years ago

As mentioned in the package-descriptor page, I am in favor of using a naming schema similar to Java Maven (https://maven.apache.org/guides/mini/guide-naming-conventions.html). "ID" should be world-wide unique, allow versioning, but also be createable by humans.

Integers, as well as UUIDs, as used in T-NOVA have to be created by a machine ...

jbonnet commented 8 years ago

Ok, good point. Had missed that. No problem on my side.

shuaibsiddiqui commented 8 years ago

Hi Michael,

Can you please point to the package descriptor page? Is it this one: http://wiki.sonata-nfv.eu/index.php/SONATA%27s_Package_Descriptor ?

sonata-jenkins commented 8 years ago

No, it’s directly on GitHub: https://github.com/sonata-nfv/son-schema/tree/master/package-descriptor

From: Muhammad Shuaib Siddiqui [mailto:notifications@github.com] Sent: Dienstag, 1. März 2016 10:30 To: sonata-nfv/son-catalogue Subject: Re: [son-catalogue] Package IDs to be used (#2)

Hi Michael,

Can you please point to the package descriptor page? Is it this one: http://wiki.sonata-nfv.eu/index.php/SONATA%27s_Package_Descriptor ?

— Reply to this email directly or view it on GitHubhttps://github.com/sonata-nfv/son-catalogue/issues/2#issuecomment-190632392.

jbonnet commented 8 years ago

Thinking deeper on this... I think we should have:

  1. IDs
  2. names
  3. is for machine manipulation (reading/writing), while 2. is for humans. 'For humans' means 'subject to error'. Therefore, I'd support using both, (UU)IDs* for machines to talk and Names as suggested by Michael.

What do you think?

mbredel commented 8 years ago

I think you are partially right, we should have 1) IDs and 2) Names. But I think only the names should got in the descriptor files, like the package descriptor. (Only talking about the files that might be generated in the SDK on a developers laptop for instance.)

IF we have ID's AND names in the descriptor file, than we would have two primary keys that identify the package, which usually is a bad idea. For instance, these key must be kept in sync which is error prone.

Once a package/descriptor is uploaded to a service platform and stored in a database, the service platform (i.e. the database) generates additional metadata, such as who uploaded the package and time of upload, anyway. Thus, it can also create a (UU)ID that is unique within the SONATA instance. We can provide an API to retrieve the package/descriptor using the name, as well as the ID. This will simplify machine-to-machine communication.

To this end, we have the best out of the two, I'd say.

Regarding the human error: Your are right, that is an issue that needs to be addressed. However, we can do it the same way, Java Maven addresses it. The Gatekeeper/Catalog has to perform checks any way. It can check the name and compare it to names and maybe MD5 hashes of data that has been uploaded before. Also signatures can help to detect errors (or even misbehavior).

jbonnet commented 8 years ago

Ok, so we'll have Package retrieval both by (UI)ID and name. Both should be unique. One doubt: by it's definition, names can't overlap between different providers, right? I mean my 'ABC' package should be named like

com.alticelabs.abc

and your 'ABC' package should be named

com.nec.abc

Am I right?

mbredel commented 8 years ago

Just to clarify: The (UU)ID only lives inside a service platform. Moreover, it might be different for different service platforms although the package is exactly the same.

Regarding the naming: You are right.

More precisely: A package would be identified uniquely by

Another package might be:

You need all three fields to identify the package. BTW: I called it group, but we can call it vendor ... which might be more aligned with the ETSI spec.

shuaibsiddiqui commented 8 years ago

So, if I understand correctly, The NSD, in itself, will not contain the (UU)ID and it will be generated by SP --> Now, within SP, who will generate it ? Gatekeeper will generate it or Catalogue? Because Catalogue would need to store (UU)ID as well along with that particular NSD.

mbredel commented 8 years ago

I would assume the catalog creates the (UU)ID. In relational databases this would be the primary key and that could be generated inside the database. Not sure how this is handled in MongoDB though.