Some documentation could be improved by adding some options to runsc spec to allow users to specify the command and some other common OCI options. This could also improve the getting started experience for folks who are kicking the tires with runsc.

I'm thinking of the following options:

• Option to specify the command
• Option to specify working directory
• Option to specify network names

Copied from briandealwis/cram#5: @student-06 asked

It would be great if we can supply auth creds for registry using parameters since it removes the dependency on credential helpers.

My exact use case is: We are setting up a CI system for UI projects, where we need to push docker images (without daemon) to a local registry which has auth.

https://github.com/opencontainers/runc/blob/master/tests/integration/cgroups.bats

The current test suite doesn't cover resource limitation stuff except memory.kernel.

Discussed at Hangzhou Alibaba Group containerd meetup:
Suggestions on topics where core containerd maintainers may have general ideas/workflow, but as the project grows we should be more specific on:

• clearer process and documentation for maintainers/contributors for backport to release/1.x
• how to decide about Golang upgrades on stable release branches? Issue: Golang lifecycle/support

Ⅰ. Issue Description

A standard git & GitHub workflow guide would be important to help new users understand how to collaborate.

Ⅱ. Describe what happened

Ⅲ. Describe what you expected to happen

Ⅳ. How to reproduce it (as minimally and precisely as possible)

Ⅴ. Anything else we need to know?

Ⅵ. Environment:

• pouch version (use `pouch v

Dockerfile:

FROM alpine
RUN exit 1

Build log:

# buildctl build --frontend dockerfile.v0 --local dockerfile=. --local context=. --output type=oci,dest=`pwd`/oci.tar
[+] Building 7.9s (5/5) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                              

The CRI-O daemon can be restarted while containers are running, this should have no impact on the container lifecycle. This assumption is true when CRI-O relies on systemd to manage the cgroups. But when CRI-O is configured to be used with cgroupfs, when the daemon terminates, all other processes are terminated too (which means the containers are stopped). This is due to some technical details on

Kata shimv2 does not have any tracing yet. Will be useful to add this.

The spec markdown files include verbose documentation and the Go code has terse comments for most fields, but the JSON Schema includes only a few descriptions.

I'd love to improve what's in JSON Schema, but I'd also hate to write it by hand differently than the other sources.

A few ideas in no particular order:

• Make JSON Schema canonical with descriptions and generate commented Go sourc

If you are in the ignite-spawn container, you have root and can change host files like /etc/resolv.conf using ignite <= v0.6.1 || v.0.5.3.

The Bind interface should be updated to support ro/rw or arbitrary mount options.
IMO specifying this should be required.

I think the image index needs a bit more clarification on how an image is intended to be processed by a runtime spec when there are multiple manifests within one image. While it is clear what is meant when there is exactly one manifest within an image or two manifests for different platform or architectures within an image, it is unclear when there are manifests for the same platform and architect

Right now when a container exits you get some confusing error logs like this:

time="2019-12-11T20:03:38.436612731Z" level=error msg="error copying io" ExecID= TaskID=container-80-3 error="read unix @->firecracker.vsock: use of closed network connection" runtime=aws.firecracker stream=stdout vmID=80

or this:

time="2019-12-11T20:03:38.443037999Z" level=debug msg="[   81.326403] a

Hi,
I have test runv for few weeks， make it a runtime work with docker, and it works well. but I still got problem when testing it, and I wanna to look for help from docs, unfortunately, I just find one doc in runv project. I think docs can add some docs like architecture about runv, guide about how to use .
maybe I not found them in network, but if you maintainer can put docs together in th

It will be much easier to use crun if it is add to the offical repository which podman is available and mark crun as a recommended for podman.

Note that the cli library we are using (on paper) supports auto-generating shell completion files so we should investigate that before we go on and write our own (if it's automated we can auto-update it on every cli change and add verification to the CI).

While exploring in the repl, I'd like to be able to type 'help' and get a list of box commands. i'd like to be able to type help <command> and get a description and usage on that command. much like the web docs, but in the repl. This should, I think, respect the --omit commandline arg and not show help for unavailable commands.

I will be submitting a patch for this, unless the idea gets tota

Now, we can only tell the markdown place. For some config items which include several 'MUST/SHOULD', it might be difficult for user to find out the detailed error.

The level of detail in the docs is great, but it would also be nice to have end-to-end examples of using the Go package for persons looking for a quick copy-paste (similar to whats at the bottom of README currently)

On current master, under the heading "Initiate Monolithic Blob Upload", the spec says (here):

This upload will not be resumable unless a recoverable error is returned.

This is the only occurrence of the word "recoverable" in the spec, and it is not cl