runtime: Remove "features the runtime chooses to support"

wking · wking · commit 78e15a92bc40 · 2017-03-15T23:03:32.000-07:00
Step 3 of the lifecycle from before this commit had two sentences which both landed in be59415 (Split create and start, 2016-04-01, #384). I pushed back a bit on the entry then [1,2], but we seem to be pretty comfortable with the current "keep all lifecyle entries in a one-layer enumerated list" approach, so I'm leaving that alone in this commit. Step 3 isn't really a lifecycle step though, it's more about clarifying that you can jump around in the lifecycle instead of hitting all the steps in consecutive order. In this commit, I've addressed that in a new paragraph that follows the list. The other sentence from the old step 3 doesn't need replacing, because the limits are already covered in more detail in the operation sections themselves. For example, the 'delete' operation has: Attempting to delete a container that does not exist MUST generate an error. Attempting to delete a container whose process is still running MUST generate an error. I don't see the need to call generic attention to that idea, and especially do not think that an entry in the lifecycle list is the right place for such a generic call-out. [1]: #384 (comment) [2]: #384 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
diff --git a/runtime.md b/runtime.md
@@ -18,8 +18,8 @@ The value MAY be one of:
 
     * `creating`: the container is being created (step 2 in the [lifecycle](#lifecycle))
     * `created`: the runtime has finished the [create operation](#create) (after step 2 in the [lifecycle](#lifecycle)), and the container process has neither exited nor executed the user-specified program
-    * `running`: the container process has executed the user-specified program but has not exited (after step 4 in the [lifecycle](#lifecycle))
-    * `stopped`: the container process has exited (step 5 in the [lifecycle](#lifecycle))
+    * `running`: the container process has executed the user-specified program but has not exited (after step 5 in the [lifecycle](#lifecycle))
+    * `stopped`: the container process has exited (step 7 in the [lifecycle](#lifecycle))
 
     Additional values MAY be defined by the runtime, however, they MUST be used to represent new runtime states not defined above.
 * **`pid`** (int, REQUIRED when `status` is `created` or `running`) is the ID of the container process, as seen by the host.
@@ -55,21 +55,23 @@ The lifecycle describes the timeline of events that happen from when a container
    If the runtime is unable to create the environment specified in the [`config.json`](config.md), it MUST [generate an error](#errors).
    While the resources requested in the [`config.json`](config.md) MUST be created, the user-specified program (from [`process`](config.md#process)) MUST NOT be run at this time.
    Any updates to [`config.json`](config.md) after this step MUST NOT affect the container.
-3. Once the container is created additional actions MAY be performed based on the features the runtime chooses to support.
-   However, some actions might only be available based on the current state of the container (e.g. only available while it is started).
-4. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
-5. The [prestart hooks](config.md#prestart) MUST be invoked by the runtime.
-   If any prestart hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 10.
-6. The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
-7. The [poststart hooks](config.md#poststart) MUST be invoked by the runtime.
+3. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
+4. The [prestart hooks](config.md#prestart) MUST be invoked by the runtime.
+   If any prestart hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 9.
+5. The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
+6. The [poststart hooks](config.md#poststart) MUST be invoked by the runtime.
    If any poststart hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
-8. The container process exits.
+7. The container process exits.
    This MAY happen due to erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
-9. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
-10. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
-11. The [poststop hooks](config.md#poststop) MUST be invoked by the runtime.
+8. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
+9. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
+10. The [poststop hooks](config.md#poststop) MUST be invoked by the runtime.
     If any poststop hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
 
+Some stages in the lifecycle are optional.
+For example, the container process may exit (step 7) before the `start` command is invoked (step 3).
+In that case, the lifecycle continues at the new location, and the intervening steps (e.g. steps 3 through 6) never occur for that container.
+
 ## <a name="runtimeErrors" />Errors
 
 In cases where the specified operation generates an error, this specification does not mandate how, or even if, that error is returned or exposed to the user of an implementation.
