Allow fstab like specifications in specs/config

[ikrabbe]

When I read the Linux example about additional file systems, I immediately wonder if it's really useful and advisable to mix the well known fstab format with field names. This way the "mounts" configuration objects becomes harder to read for human beings, or at least for me.

I would prefer a configuration that looks more like fstab itself

"mounts": [
    "proc /proc proc",
    "tmpfs /dev tmpfs nosuid,strictatime,mode=755,size=65536k",
    "devpts /dev/pts devpts nosuid,strictatime,mode=755,size=65536k",
    "tmpfs /dev/shm shm nosuid,noexec,nodev,mode=1777,size=65536k"
]

This form to setup file system is well known and hasn't changed for years. Defining additional mounts could be an option and might be mixed with the object structure you propose.

But completely ignoring the form of the old fstab line format, looks to me like a bug.

[ikrabbe]

I've seen this also holds for other arguments and is part of the runC export. I'll try to propose a good solution to map the json args for default single line layouts.

[philips]

@ikrabbe I think a reasonable goal of this is to push fields into the schema for validation and explicitness. Also, I would suggest that the evolution of fstab is the systemd mount unit which breaks out the what/where/options parts of the mount: http://www.freedesktop.org/software/systemd/man/systemd.mount.html#Options

[ikrabbe]

I don't exactly see an evolution where a human being looses overview of even simplest tasks but I agree that validation is still needed. It should be possible to extend the json parser to handle default situations where a plain string is used instead of an object and I will try to write a simple example of how such thing integrates into the existing runC code.
It's good to be able to extend a legacy format with new fields, when needed. But if a legacy format still matches 90% of the use cases, it is also good to keep that format at least as an option.

[cyphar]

I prefer that we use JSON for describing logical blocks such as mount options. If you have to start parsing JSON attributes when it would be much simpler (and more readable) to make it a JSON object too.

[ikrabbe]

Of course parsing is simpler, when you keep it in JSON format. But reading and editing a container.json for a human being is much simpler with short forms, at least for simple objects.