appc: document a suggested CLI format for apps

[philips]

From @philips on December 8, 2014 17:6

We implemented a serialization format for the app and labels in the discovery package but never documented it. It isn't really necessary in the appc spec itself but is a reasonable suggestion:

https://github.com/coreos/rocket/blob/master/app-container/discovery/parse.go#L37

Copied from original issue: coreos/rocket#239

[philips]

From @jonboulle on December 8, 2014 18:33

I agree that it shouldn't necessarily be codified in the app spec, but I suggest we at least describe it as an example when talking about image discovery.

[philips]

From @elcct on December 8, 2014 20:26

If in my discovery page I have following template:

example.com https://example.com/{name}-{version}.{ext}

Then I want to fetch following image:

example.com/hello,version=1.0.0,os=linux,arch=amd64

Is there a particular reason why {name} will be example.com/hello and not just hello ?

It will be resolved to following URL:

https://example.com/example.com/hello-1.0.0.aci

Which looks silly.

Workaround is then to have service return template that explicitly states image name like:

example.com https://example.com/hello-{version}.{ext}

Also is there a reason why Name can't be a direct URL? (App-Container Name specification doesn't allow that)

[philips]

On Mon, Dec 8, 2014 at 12:26 PM, Pawel Szymanski notifications@github.com wrote:

If in my discovery page I have following template:

example.com https://example.com/{name}-{version}.{ext}

Then I want to fetch following image:

example.com/hello,version=1.0.0,os=linux,arch=amd64

In this case you would simply make the template https://{name}-{version}-{arch}-{os}.{ext}, right?

Also is there a reason why Name can't be a direct URL? (App-Container Name specification doesn't allow that)

You can run a direct URL in rkt. Essentially this will fetch the image, look at the name/hash and run that name/hash. The discovery stuff is an optional but very handy mechanism.

[philips]

From @elcct on December 8, 2014 21:5

In this case you would simply make the template https://{name}-{version}-{arch}-{os}.{ext}, right?

True.

You can run a direct URL in rkt. Essentially this will fetch the image,

Yes, but if you want to have dependent images (with certs for example) you can't use direct URLs inside the manifest. That's related to #140. Fileset Dependency Name is of App-Container Name type.

[philips]

From @jonboulle on December 8, 2014 21:18

@elcct check out #241 which should help clarify the dependency resolution.

Yes, but if you want to have dependent images (with certs for example) you can't use direct URLs inside the manifest.

I don't really understand the problem because this still follows the standard image discovery process, so you can just have the same https://{name}-{version}-{arch}-{os}.{ext} template, no?

[philips]

From @elcct on December 8, 2014 21:36

Sorry, I meant to say that if you want to have dependencies you have to use discovery mechanism and/or you can't use name like "example.com/hello:1.0.0" in the manifest as this is not valid App-Container Name

[philips]

@elcct At one point in the spec we said that dependencies could have an explicit list of mirrors. We removed it after adding the discovery; although I can see the utility if you don't want to use the discovery mechanism.

[jonboulle]

@xiang90 Please take a look at this after you finish with https://github.com/coreos/rocket/pull/283