spec: dependencies details > manifest merge strategy

[frntn]

While the spec specifies how acis are being extracted on one another (as long as ̀pathWhitelist allows it), it does not gives informations about the manifest.

As first proposal what about these "merge strategy" options :

• none : keep original manifest unmodified,
• array : assembles a value from every matching level of the hierarchy,
• hash : recursively merge hash keys.

The behaviour description must be shipped inside the image but (and that's the part I don't like!!) the option it self should never be overwritten.

(I think we loose here the simplicity we want for the spec, but the problem do exists so I'm just hoping this proposal will help as a starting point for a better answer)

[jonboulle]

@frntn Actually there is no concept of manifest merging. dependencies/pathWhitelist only talks about constituent files of an ACI.

The behaviour description must be shipped inside the image but (and that's the part I don't like!!) the option it self should never be overwritten.

I don't really understand what you mean here - what specifically don't you like, and what would you rather see?

Also, to be clear, most options can be overridden in the CRM/at runtime (the exact semantics we are still trying to thrash out in #83/#84). So what is contained/codified in the image manifest within an ACI is not a totally immutable behaviour description when it comes to running the actual container.

[frntn]

OK. So the dependency concept is just another way to implement the layered mechanism.
I though it was a more powerful feature where we could fetch the filesystem, the isolators, the labels and so on...

This would have been way more complex to implement (and understand), so I am happy to see it is not !
Thanks