spec: clarify relationship between CRM and "apps"

[jonboulle]

(This is partly leading on from the discussion in rkt/rkt#294)

A Container Runtime Manifest declares one or more apps to be executed. At the time of writing the format of declaration looks like this:

• apps the list of apps that will execute inside of this container
  • app the name of the app (string, restricted to AC Name formatting)
  • imageID the content hash of the image that this app will execute inside of (string, must be of the format "type-value", where "type" is "sha512" and value is the hex encoded string of the hash)
  • isolators the list of isolators that should be applied to this app (key is restricted to the AC Name formatting and the value can be a freeform string)
  • annotations arbitrary metadata appended to the app (key is restricted to the AC Name formatting and the value can be a freeform string)

There are several issues with this schema:

• Each "app" technically refers to an app image (ACI), which may or may not actually contain an app declaration (since "app" is an optional section of the Image Manifest). The spec is unclear as to what will occur if the referenced image does not contain an app declaration. (Relatedly, "app" should likely more accurately be called "name")
• "app" references are not unique. There is a fairly simple use case of wanting to use a particular app-image multiple times within a container, but it is unclear how this behaviour should be represented in the spec, or at least how implementations should go about handling it (currently in Rocket we actually mandate that apps within a CRM must be unique)
• For each app, there is only a partial ability to override some of the parameters defined in the Image Manifest. For example, currently isolators (from the app section of the Image Manifest) and annotations can be overridden/extended; but there is no such ability to override the exec, eventHandlers or environment

This is closely related to, but not the same as, #83

One possible solution is to extend the schema of app references in the CRM to match that of the Image Manifest. In this way, all of the parameters in the Image Manifest could be explicitly overridden at a later stage. However, this does potentially mean a lot of duplication between the information contained in the IM and the CRM.

[wereHamster]

The first issue was clarified in #72.

[jonboulle]

@wereHamster I don't think we properly understood your question there; I think we should define (or at least describe) the expected behaviour in the spec.

[wereHamster]

I didn't have a question. Just mentioning that the behavior under the condition outlined in the first point was explained in the first comment on #72. That is: the executer should fail.

[jonboulle]

@wereHamster right, I think we're on the same page now, that's what this ticket should clear up ;-)

[jonboulle]

I am starting to think that what we should tweak the meaning of the "name" (née "app") field: rather than being necessarily equivalent to the name of the image (let's call that the ACI name) it would be a distinct value referring to the app inside the running container (let's call that the CRM app name).

We could then mandate in the spec that this field/value be unique within a given container/CRM.
Then implementations could provide simplifications of this abstraction: for example a basic workflow that generates CRMs would just use the ACI name as the CRM app name (i.e as Rocket does today)

+ Solves the duplication problem (multiple ACIs with the same name in their manifest)

• Gives a consistent way to uniquely refer to an app within a container (container UUID + CRM app name)
• Makes it clear that the only field in the "app" schema that actually references the app (as opposed to extending/overriding it) is the imageID
• Easy to implement "backwards compatible" simplifications where the ACI name and CRM app name are the same

• Potentially confusing since sometimes the ACI name and CRM app name would differ and sometimes they might be the same
• Incompatible with the issue/proposal described in schema: Add labels to Container Runtime Manifest #106, which essentially goes in the opposite direction (of adding labels to the "app" schema, i.e. extending rather than narrowing the reference information)

@cdaylward thoughts?

[jonboulle]

9aafd97 partially addressed this issue by introducing a new level of naming abstraction (essentially the CRM app name I described above). However it does not yet address the issue of uniqueness.