Punt to the operating system for character encodings #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To match the specs convention [1]. [1]: https://github.com/opencontainers/specs/blob/v0.1.1/README.md#markdown-style Signed-off-by: W. Trevor King <wking@tremily.us>
Otherwise they're rendered as a single paragraph. Signed-off-by: W. Trevor King <wking@tremily.us>
See [1]. 'sh' keyword comes from [2], and seemed more explicit to the POSIX semantics than 'shell'. [1]: https://help.github.com/articles/github-flavored-markdown/#syntax-highlighting [2]: https://github.com/github/linguist/blob/master/lib/linguist/languages.yml Signed-off-by: W. Trevor King <wking@tremily.us>
It's pretty clear that the header describes the rest of the file's contents without the colon ;). Signed-off-by: W. Trevor King <wking@tremily.us>
I think that's the possessive form of 'process' ;). Signed-off-by: W. Trevor King <wking@tremily.us>
To give space for more detail about the streams. I'm not sure what platform-agnostic language for this should look like, but on POSIX I'm expecting just exec'ing the application process and inheriting the file descriptors. Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
Catch up with [1]. [1]: opencontainers/runtime-spec#88 Signed-off-by: W. Trevor King <wking@tremily.us>
Use GNU-style long options to avoid ambiguous, one-character options in the spec, while still allowing the runtime to support one-character options with packing. Signed-off-by: W. Trevor King <wking@tremily.us>
Let folks do whatever they want as long as they don't clobber our command namespace. Signed-off-by: W. Trevor King <wking@tremily.us>
Make it easy for a caller to report which runtime they're using. Signed-off-by: W. Trevor King <wking@tremily.us>
Give the user a consistent way to pick their container ID. For example, they may want to use: --id $(dirname "$PWD") or they may want to use: --id $(uuidgen) or they may want to leave ID generation to the runtime. Signed-off-by: W. Trevor King <wking@tremily.us>
You shouldn't need these for any other operations. Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
Mostly for stopping them, but also useful for any number of signals (e.g. many applications use HUP to reload their configuration). Signed-off-by: W. Trevor King <wking@tremily.us>
On IRC just now: 10:56 < crosbymichael> if the main process dies in the container, all other process are killed ... 10:58 < julz> crosbymichael: Im assuming what you mean is you kill everything in the cgroup -> everything in the container dies? 10:58 < crosbymichael> julz: yes, that is how its implemented ... 10:59 < crosbymichael> julz: we actually freeze first, send the KILL, then unfreeze so we don't have races We don't have lifecycle docs for that yet, but once we do, we can update this to link to them. Signed-off-by: W. Trevor King <wking@tremily.us>
These are useful for checkpointing, since getting a consistent checkpoint of a running container is hard ;). This doesn't handle the checkpoints themselves though, which are currently not specified. Checkpoint behavior will look something like: $ funC pause --wait container-id $ checkpoint ... $ funC resume container-id Signed-off-by: W. Trevor King <wking@tremily.us>
This landed in runC with [1], but the bundle-author <-> runtime specs explicitly avoid talking about how this is set (since the bundle-author doesn't care about the runtime-caller <-> runtime interface) [2]. However, *this* spec is about the runtime-caller <-> runtime interface, so we need to document it here. I've left LISTEN_PID [3,4] out, since I don't see how the runtime-caller would choose anything other than 1 for its value. It seems like something that a process would have to set for itself (because guessing the PID of a child before spawning it seems racy ;). In any event, the runC implementation seems to set this to 1 regardless of what systemd passes to it [4]. I've borrowed Shishir's wording for the example [4]. [1]: opencontainers/runc#231 [2]: opencontainers/runtime-spec#113 (comment) [3]: http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html [4]: opencontainers/runc#231 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Michael Crosby <crosbymichael@gmail.com> Cherry-picked from [1]. [1]: opencontainers/runtime-spec@84707b0 Signed-off-by: W. Trevor King <wking@tremily.us>
See https://github.com/blog/1184-contributing-guidelines Also strip some trailing whitespace. Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
wking
force-pushed
the
character-encodings
branch
from
bac8c59 to
bbb5fc9
Compare
Without this, "may contain any Unicode characters" seemed too
ambiguous.
I wish there were cleaner references for the {language}.{encoding}
locales like en_US.UTF-8 and UTF-8. But [1,2] seems too glib, and I
can't find a more targetted UTF-8 link than just dropping folks into a
Unicode chapter (which is what [1] does):
The Unicode Standard, Version 6.0, §3.9 D92, §3.10 D95 (2011)
With the current v8.0 (2015-06-17), it's still §3.9 D92 and §3.10 D95.
The TR35 link is for:
In addition, POSIX locales may also specify the character encoding,
which requires the data to be transformed into that target encoding.
and the POSIX §6.2 link is for:
In other locales, the presence, meaning, and representation of any
additional characters are locale-specific.
[1]: https://en.wikipedia.org/wiki/UTF-8
[2]: https://en.wikipedia.org/wiki/Locale#POSIX_platforms
wking
added a commit
that referenced
this pull request
Dec 17, 2015
This gives us an easy way to share state JSON (because sometimes the PID is insufficient, e.g. on Linux you may need externalFds for efficient checkpointing [1,2]) [3]. Possible alternatives for transmitting state information, and why I feel this approach is superior: * Writing a state file from a pre-start hook [4]. This is pretty close to the --state option, but the --state option allows callers to recover the JSON via a named pipe like /dev/fd/3. That sort of direct connection would be trickier to setup with a hook-based approach. Pre-start and post-stop hooks may still be the best solution for (de)registering a container with a monitoring service, but that's not quite the same application. * Writing a state file to a global directory [5]. Atomic changes, change-monitoring, garbage collection, and ownership/access issues on a global directory are all hard to get right (or have ambiguous values of "right") [6]. * Requiring runtimes to maintain an internal registry of containers they launch [7]. This gives runtimes more flexibility than having a single, global directory. But ownership/access issues are still difficult (if one unprivileged user registers a container, can another unprivileged user see that entry? What elevated permissions would you need to see that entry? To remove that entry?). And the easiest way to get atomic changes and garbage-collection is by registering with a daemon, while not requiring a daemon is currently the #1 feature listed on [8]. In the event that any of those arguments seem leaky, callers that prefer a different approach can easily use hooks (without setting --state) or write wrappers that use a named pipe approach like (--state /dev/fd/3) to collect the JSON and then write it to their preferred registry. So the --state approach seems easy for the runtime to implement reliably, and also compatible with any of the suggested alternatives. The converse is not true; requiring a write to a global or per-runtime registry is not compatible with use-cases that prefer the anonymity of not writing the state at all (which is possible just by leaving off the --state option). [1]: opencontainers/runtime-spec#87 (comment) [2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/z25xQsF3pHA/ixyeTrxyFwAJ Subject: Re: Drop /run/opencontainer entirely? Date: Fri, 4 Sep 2015 21:30:24 -0700 Message-ID: <20150905043024.GB25638@odin.tremily.us> [3]: https://groups.google.com/a/opencontainers.org/d/msg/dev/q6TYqVZOcX8/W1RVyCXCCQAJ Subject: Re: removal of /run/opencontainer/containers, add --state? Date: Tue, 8 Dec 2015 15:49:57 -0800 Message-ID: <20151208234957.GK2767@odin.tremily.us> [4]: https://groups.google.com/a/opencontainers.org/d/msg/dev/q6TYqVZOcX8/GQs0zkRHBwAJ Subject: Re: removal of /run/opencontainer/containers Date: Mon, 30 Nov 2015 13:55:40 -0800 Message-ID: <20151130215540.GF23595@odin.tremily.us> [5]: https://github.com/opencontainers/specs/blob/v0.1.1/runtime.md#state [6]: https://groups.google.com/a/opencontainers.org/d/msg/dev/q6TYqVZOcX8/JRm4auylBQAJ Subject: removal of /run/opencontainer/containers Date: Wed, 25 Nov 2015 14:29:35 +0000 Message-ID: <CAD2oYtNipt3i_C6=J4Bc-jwauo5YAvKXUqTROnPNP3vZ9+C5Vw@mail.gmail.com> [7]: https://groups.google.com/a/opencontainers.org/d/msg/dev/q6TYqVZOcX8/wHYucS-rBQAJ Subject: Re: removal of /run/opencontainer/containers Date: Wed, 25 Nov 2015 08:06:10 -0800 Message-ID: <CANEZBD7VCWj6w5dFAEbULrL6WsY=FSRhVsWFreYXUOHwsUJkwA@mail.gmail.com> [8]: http://runc.io/ Embeddable Containers are started as a child process of runC and can be embedded into various other systems without having to run a Docker daemon. Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Without this, “may contain any Unicode characters” seemed too
ambiguous.
I wish there were cleaner references for the
{language}.{encoding}locales like
en_US.UTF-8and UTF-8. But Wikipedia linksseem too glib, and I can't find a more targetted UTF-8 link than just
dropping folks into a Unicode chapter (which is what Wikipedia
does):
With the current v8.0 (2015-06-17), it's still §3.9 D92 and §3.10 D95.
The TR35 link is for:
and the POSIX §6.2 link is for: