determine what to do about Aggregate unique identifier

[chaos@bbn.com]

Sorry to make a "decide what to do" ticket, but we need this, so we'll have to do that. Recap of the situation:

• We need to pick a unique identifier for the Aggregate object
• We believe aggregate URNs are not necessarily unique
• In the call, we settled on AM API URL as the identifier. However, we later realised that this may not work: the AM API URL may have an AM API version embedded in it, for instance, tau-verde's URL is:

  https://foam5.gpolab.bbn.com:3626/foam/gapi/1/
  

  and as far as i know, that '1' is mandatory, and there is no default version URL for a FOAM aggregate. Also as far as i know, the AM API does not require a default version URL. The downside of this, of course, is that when the default version of an aggregate changes, it will become a different Aggregate object. No one wants that.

Find and implement a solution we can live with for this problem.

[chaos@bbn.com]

Offhand, here are some solutions which might work:

1. Use FQDN + type as a two-item unique identifier, as we previously discussed doing. I'm dubious about this basically because i think it will be prohibitively difficult to implement, and will lead to a lot of hours of debugging.
2. Use URL and ignore the problem for now, hoping to come up with a good solution later (maybe the AM API could require a default URL?)
3. Use <fqdn>:<port> as the unique identifier. This isn't totally guaranteed to be unique, but i can't think of a situation where it wouldn't be involving existing GENI AMs.

Given those options, i like C: it's not incredibly clean, but in practice i think it will refrain from biting us for longer than B will.

IMO, the long-term solution is for the AM API folks to determine a way to make aggregate URNs more definitely unique and get people to code to it. But i think that will take a while to do, even if it is judged to be worthwhile. So we need a short-term solution.

What do others think?

[jbs@bbn.com]

Replying to chaos@bbn.com:

IMO, the long-term solution is for the AM API folks to determine a way to make aggregate URNs more definitely unique and get people to code to it. But i think that will take a while to do, even if it is judged to be worthwhile. So we need a short-term solution.

It would be interesting to know what the clearinghouse people think, because one thing they might think is that any AM that wants to talk to the CH will need a unique aggregate ID.

(I don't have an opinion about short-term options, other than that it'd be better to go with something that would be easy to transition to the long-term option later.)

[sedwards@bbn.com]

Kevin says he'll do C.

[chaos@bbn.com]

Works for me. Thanks for following up on this.

[sedwards@bbn.com]

Verified this works in 0.6.1. Closing.