Issues regarding system containers not using runc

[yuqi-zhang]

Some considerations came up from the azure container, which uses systemd but not runc. If we run this container from the atomic CLI, there are a few issues I noticed:

1. We generate a default config.json for a container image missing a config.json.template. For containers that don't use runc, should we somehow check that and not generate that file?

2. In follow up to 1, I recall that we use the file at /run/runc/container/state.json for some things before, would that be affected?

3. In the info file, we still have:
   "EXEC_START": "/bin/runc run 'azure'"
   "EXEC_STOP": "/bin/runc kill 'azure'"
   which doesn't match up to the service file

Perhaps I'm misunderstanding the method of running said containers and we shouldn't be using the atomic CLI. What do you think @giuseppe

[giuseppe]

1. I think it is still useful to generate a default configuration OCI file, even if not present, so that users can manually edit it, I find it quite handly to test out with busybox. I've added a warning recently when the config.json.template file is missing so that it is clear the image won't automatically work as a system container.

2, yes, that is generated by atomic install --system but the containers are not forced to use it. For example we could have a oneshot system container that uses only EXEC_START

[rhatdan]

I would prefer if the info file would not talk about runc, or there was a way for the container image developer to indicate if he is using runc or not.

[ashcrow]

@giuseppe is this still an ongoing conversation?

[giuseppe]

we have the possibility to specify another runtime now, so atomic is less bound to runc and bwrap-oci, if that helps for this issue

[ashcrow]

@yuqi-zhang please advise