Closed jonboulle closed 7 years ago
Sounds like a sane thing to have to me.
I'm slightly iffy on the name because it implies the use of a copy-up filesystem, which really is an implementation detail. Maybe something like 'appData' or 'existingData'? Neither of those seem particularly better tan copyUp to me though, and I'm fine with copyUp too.
rkt have a usecase for this (mostly for interoperability), so thanks for adding it. I'm not much into bikeshedding here, so feel free to pick the name you prefer. (If you actually need a tie-breaker, appData
sounds like the most obvious keyword to me)
What happens if multiple apps in the pod mount the volume and have data to initialize?
We may need to declare this as a MountPoint option as well.
Renamed to appData
@squeed can you take this over?
Hyup.
@squeed bump?
@jonboulle any thoughts on the ordering semantics?
@squeed honestly I'd lean towards saying that's unspecified and discouraged behaviour. Is there a sensible usecase for something more controlled?
As much as I don't like UB, I think this is probably one of those cases where it has to be. At best, this is related to application add/start ordering inside a both. Do we say explicitly say anything about that somewhere else in the spec? In that case, we could just refer to it.
branch is at https://github.com/jonboulle/spec/tree/volthiing
Add a new volume type, similar to
empty
but prepopulated with data from the app filesystem, similar to how Docker volumes work.@lucab wdyt?