Why does the oci runtime spec define the runtime operation after the proposal of" runtime CLI spec" has been rejected?

[yaoxin1995]

I am a beginner. I checked the OCI runtime specification.

I found that the OCI runtime specification defines runtime operations. These include create, start, delete, state, and kill. It also states that these operations do not specify any command line API.

I checked Add Runtime CLI Spec

I found that the operations defined in the runtime specification are very similar to those defined in the CLI spec.

But the proposal "Add Runtime CLI Spec" has been rejected.

So why does the OCI runtime spec still define operations similar to the Runtime CLI Spec?

[cyphar]

The runtime-cli specification was a proposal to define a CLI interface that all runtimes must support. The operations you mention are all operations that could be implemented as a CLI, GUI, or any other interface (they are needed to describe the container lifecycle). The operations were all already defined in the early draft versions of the specification, they are core to the specification and the runtime-cli spec proposal came a while afterwards.

In practice, most OCI runtime-spec implementations have a CLI interface, and in retrospect it may have made sense to have a runtime-cli specification (at the moment, most runtimes implement what runc does and add features on top when necessary -- which is a bit unfortunate) but there were pretty serious concerns with the proposal (from memory, I was one of the main people against the proposal) and so the proposal never went forward.

[yaoxin1995]

thanks @cyphar .

Yes, I know the runc command line api is not a good idea for a VM based runtime.

Currently, kata (v2) has abandoned the command line api in favor of the contaienrd shim v2 api.

From my understanding, the shim v2 api includes operations from the OCI runtime specification (start, kill, create etc.,) and extends it.

Are there any plans in the OCI community to standardize the shim v2 api and add it to the runtime spec?