Clarifications on dependency matching and split between fetching and getting.

[sgotti]

The spec in the "Dependency matching" chapter says that every dependency should be discovered using the ACI discovery process and then, just the downloaded image should be verified with the requested labels or matching ImageID.

But, in appc/spec#16 this process is split in two phases: ACI fetching and ACI rendering. I think that the splitting between the fetching phase and the rendering phase is good. Someone can, for example, not fetch the image from a repository but just import an aci manually in the store. Or there can be an offline/caching mode.

So the ACI rendering will be executed independently from the ACI fetching. In the ACI rendering phase the ACI will be requested to the store providing an imageID or an app name and some labels. In the latter case the store can find more than one ACI that matches the requested App name and labels.

Which one should be returned?

I have some possible cases in mind:

Case 1

If I'm requesting to the store an App name without any label, all the ACIs with that App Name will match your request.

Which one should be returned? Should it be implementation dependent or should it be defined in the spec?

The current implementation i tried to do in coreos/rocket#297 uses the latest aci imported in the store.

Case 2

Another example can be the "latest" pattern: If I'm requesting to the store an App without any version label, how can I satisfy the "latest" pattern?

• Fetch phase: In this phase, as I'm not passing a specific 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".
• Rendering phase: I'm requesting from the store an ACI named appname and without any version label. The store can have other ACIs previously downloaded or imported for this app name with different version (for example "1.0.0" "strangereleasename" etc...). As the version label is just a string without any SemVer or lexical ordering rule there isn't an ordering in these labels.

As in [Case 1](#Case 1) the implementation i tried to do in coreos/rocket#297 chooses the latest imported ACI but prefers ACIs imported with the "latest" flag (its saved in an appinfo additional index):

On fetching, if downloaded with the "latest" pattern, the ACI is saved in the store with the "latest" flag. When requesting an aci without specifying a version label the ones with the latest flag are preferred over the others (or perhaps only the one with the latest flag should be choosed?).

• Are my thoughts correct?
• If so, there should be possible ACI choosing logics other then the one I tried to implement? Should this logics be clarified in the SPEC?
• If so, should the spec be clarified (also with some examples)?

[sgotti]

As all the patches implementing the above behavior are landed, I assume that it's the wanted behavior (at least for rocket).

Now the question is:

• is this implementation dependent (as rocket uses the cas as a local cache) and the SPEC shouldn't be changed but perhaps some examples should be added to the Implementation Guide.

or

• the SPEC should clarify the statement in https://github.com/appc/spec/blob/master/SPEC.md#dependency-matching introducing the splitting between fetching and getting.

[jonboulle]

I think I would argue that the local cache (CAS, in Rocket's case) is essentially just another an implementation of the discovery service, at least in terms of the dependency matching - so "fetching" and "getting" are essentially the same operation in this sense, and the behaviour is implementation dependent.

We should definitely address this more clearly in the spec, though. @sgotti if this makes sense to you do you have something in mind you could put up as a PR?