[question] clarification of image id in PodManifest

[blalor]

I want to work on extending Nomad's support for rkt, and would like to pave the way for other ACEs. Most of rkt's command-line arguments can be replaced by a PodManifest document. My thought is that instead of having Nomad build up a string of arguments to be passed to the rkt binary, it could instead generate a PodManifest and use rkt's --pod-manifest argument instead. The thing I'm struggling with is that the PodManifest requires an element in apps to have the image object's id property specified. But the only way I see within rkt to resolve an image's ID is to use rkt fetch. Furthermore, rkt will not create a pod from a PodManifest if the image doesn't exist in the local store, even if the image ID is provided along with the name and labels.

If instead a PodManifest did not require the image ID and was able to drive image discovery using the provided name and labels, it seems to me that the PodManifest could be a truly portable input to an ACE.

I haven't fully internalized the appc spec, but could someone help me understand the purpose of the PodManifest, and what an appropriate workflow to determine the image ID should be in the confines of the current spec? I don't expect the command-line interface to an ACE to be standardized or captured in the spec, but the PodManifest very nearly achieves the goal of being a portable definition of a pod.

[jonboulle]

We do something similar in rktnetes.. @yifan-gu @euank can you help with
this one?

On 16 June 2016 at 19:16, Brian Lalor [email protected] wrote:

I want to work on extending Nomad's support for rkt, and would like to
pave the way for other ACEs. Most of rkt's command-line arguments can be
replaced by a PodManifest document. My thought is that instead of having
Nomad build up a string of arguments to be passed to the rkt binary, it
could instead generate a PodManifest and use rkt's --pod-manifest
argument instead. The thing I'm struggling with is that the PodManifest
requires an element in apps to have the image object's id property
specified. But the only way I see within rkt to resolve an image's ID is to
use rkt fetch. Furthermore, rkt will not create a pod from a PodManifest
if the image doesn't exist in the local store, even if the image ID is
provided along with the name and labels.

If instead a PodManifest did not require the image ID and was able to
drive image discovery using the provided name and labels, it seems to me
that the PodManifest could be a truly portable input to an ACE.

I haven't fully internalized the appc spec, but could someone help me
understand the purpose of the PodManifest, and what an appropriate workflow
to determine the image ID should be in the confines of the current spec? I
don't expect the command-line interface to an ACE to be standardized or
captured in the spec, but the PodManifest very nearly achieves the goal of
being a portable definition of a pod.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#627, or mute the thread
https://github.com/notifications/unsubscribe/ACewNwcFh1yomS4qH1DtJYKUdQMVD3F4ks5qMYTdgaJpZM4I3m9m
.

[euank]

What we do in rktnetes is basically a combination of rkt fetch and rkt list to get the image referenced, and we create the pod-manifest only once we have the image id.

The pod spec makes a suggestion for exactly this problem; it mentions that you could use an incomplete manifest as a deployment template where image ids are resolved before it is passed along to the executor.

I do think it makes sense to keep the discovery+fetching and execution distinct, which that id being required helps express.

Perhaps there is room for the idea of a PodManifestTemplate (a unit of deployment) which expects to be resolved into a PodManifest (a unit of execution), though I'm not convinced that such a thing is really helpful if the only difference is that the id is optional and it's expected the resolution is just discovery/fetching as needed.

[blalor]

Thank you, @euank and @jonboulle!

The pod spec makes a suggestion for exactly this problem; it mentions that you could use an incomplete manifest as a deployment template where image ids are resolved before it is passed along to the executor.

Is it intended that this be a feature of the executor, or part of a tool that runs outside of it?

I see a use for a reified PodManifest as a tool for precisely reproducing a Pod, but I think a PodManifestTemplate would be extremely valuable to users and third-party tools responsible for deploying pods. Yes, the difference would be the presence of the image ID (which I feel could be made optional in a PodManifest, as the purpose of the PodManifest isn't clearly documented as a unit of execution, in my opinion), but it would remove the burden (and ACE-specific task) of discovery+fetching on the third-party tool. In the case of rkt, a PodManifest document cannot be executed if the image is not already in the local store: rkt will not perform discovery to resolve the referenced image if it's missing.

I think PodManifestTemplate would open the door for wider appc adoption, as it would provide a method for decoupling the specification of a pod to be run from the ACE-specific interface. Alternatively, I think there's room in the spec for PodManifest to define its role as unit of deployment or execution based on the presence of the image ID. I'd also like to see the rationale for and purpose of the PodManifest clarified in the spec.

[yifan-gu]

It's a matter of whether we want to do image fetching with a pod manifest. At this point, I don't see strong reason why not.
Ref rkt/rkt#1326

[blalor]

I'd love to see this implemented in rkt, but it'd be impossible to validate such a PodManifest with the current spec.

[jonboulle]

I think PodManifestTemplate would open the door for wider appc adoption, as it would provide a method for decoupling the specification of a pod to be run from the ACE-specific interface. Alternatively, I think there's room in the spec for PodManifest to define its role as unit of deployment or execution based on the presence of the image ID. I'd also like to see the rationale for and purpose of the PodManifest clarified in the spec.

hmm, is this not clear with the current wording?

The definition of the pod - namely, the list of constituent apps, and any isolators that apply to the entire pod - is codified in a Pod Manifest. Pod Manifests can serve the role of both deployable template and runtime manifest: a template can be a candidate for a series of transformations before execution. For example, a Pod Manifest might reference an app with a label requirement of version=latest, which another tool might subsequently resolve to a specific version. Another example would be that volumes are "late-bound" by the executor; alternatively, an executor might add annotations. Pod Manifests also provide the ability to override application execution parameters for their constituent ACIs (i.e. the app section of the respective Image Manifests).

When I first added this functionality I did actually have a separate PodManifestTemplate type, but if memory serves we came to the conclusion it was a bit redundant with the current situation, where the pod manifest can essentially play both roles.