Clarifications on version label default value on aci discovery.

[sgotti]

Hi,

should the spec define that, during the aci discovery process, if the version label isn't specified it should default to "latest" (as done in discovery/parse.go?)?

Thanks!

[jonboulle]

@sgotti My thinking on this is that it's more implementation dependent (although perhaps then we should clarify that it is up to the implementation). You can imagine that some discovery processes would want to get the latest by default for simplicity, and others might always want to get a specific version and fail if none is specified. What do you think?

[sgotti]

@jonboulle I think it makes sense to make the default version implementation dependent and to clarify it in the spec.

About the "latest" value: I was thinking that should be good to define it in the spec as "the standard value to ask for the latest version" (so every repository can provide it for every implementation).
Leaving it free will make it different for every implementation and also for every repository maker creating a lot of combinations and different behaviors.

[wereHamster]

Related: #56

[sgotti]

@jonboulle Something more to the above question on the "latest" value definition:

From what I asked in #73 and implemented in rkt/rkt#297 my thoughts are that the ACI imagemanifest shouldn't contain a "version" label with value "latest".

If you look at #73 "case 2" I'm imagining that "latest" is used on fetching to get the latest ACI, but the ACI in its imagemanifest has a specific version like "version" : "2.0.1" and not "latest".

What was the original idea on the latest pattern? Am I getting it correctly?

[jonboulle]

@sgotti We have discussed this (and made changes) in a few different places so I am not quite sure on the latest status with this one - can we close it?

[sgotti]

@jonboulle to summarize, over then #73, related to the version label, the basic doubt is this:

• Is the "latest" value for the "version" label a kind of special value?

Take this example case:

• (case 2 of Clarifications on dependency matching and split between fetching and getting. #73) On fetching I'm requesting an appname without a version label. The aci discovery will download something like https://example.com/appname-latest-linux-amd64.aci. On the http server it can be a link to an aci called appname-2.0.1-linux-amd64.aci and in its manifest the version label will be "2.0.1".

I'd like to know if this example is what you had in mind when you thought about the "latest" pattern.

If this is correct I'm thinking that:

• The ACI imagemanifest mustn't contain a "version" label with value "latest" as it will clash with the "latest" pattern.
• The ACI imagemanifest mustn't contain in its dependencies section an app with a "version" label with value "latest". As given in the above point an ACI cannot contain a "version": "latest" label and so an ACI will never match the required labels (as the spec in the "dependency matching" section says that the downloaded aci's labels should be compared against the labels in the retrieved ACI)
• Should be good to define in the spec that the latest value for a version label is "the standard value to ask for the latest version". So every repository can provide it for every implementation. Leaving it free will make it different for every implementation and also for every repository maker creating a lot of combinations and different behaviors.

Or, if all the above is not correct, were you thinking that my idea of the link on the http server is wrong and that can exists an ACI called appname-latest-linux-amd64.aci with a "version" : "latest" in its imagemanifest?
I excluded this because, as there isn't the possibility to provide multiple version labels, if I provide an aci like this I cannot specify its real version (I should create two identical, at the contents level ACIs, with identical imagemanifests excluding the different version label).

What do you think about all these?

Thanks!

[sgotti]

Since some time has passed I tried to update this issue opening a new discussion and proposal in #575.