charliecloud
charliecloud copied to clipboard
hpc
implement `ch-image modify`
@qwofford, what do you think of this proposal?
Alternate names include deform, edit, and mutate.
It would be nice not to implement the save prompt, i.e., only have the behavior with --yes as currently written and save or not depending on shell exit status.
I like this proposal. I hadn't considered the implications of running concurrent interactive sessions on the same deployed container. The note in the documentation about an explicit need for -o DEST in order to truly modify a deployed container is clear. Thumbs up from me...I know @azukaitis is interested in this feature too.
I think this might be a slightly greedy hope...but in reference to the warning block of text here...it would be really nice (and unique among container runtimes?) if we somehow stored a series of Dockerfile commands that represents the build cache too. Anything from a Dockerfile could be stored directly, and then anything from a ch-image modify would get pre-pended with RUN. That way you could build up a container interactively, then do something like a ch-image to-dockerfile DEST and snip out any commands that weren't ultimately important.
This could get us the interactive functionality we want without diverging too far from best practices at the end of the day.
if we somehow stored a series of Dockerfile commands that represents the build cache too
This is a cool idea. I can think of a couple approaches:
-
Horrible, nearly useless shell: Charliecloud interactively collects a command line, then executes it. Simple to implement, but loses essentially all shell features invented since 1975.
-
Munge Bash history variables and commands: Run a normal Bash shell, which can capture its own command history. Set that up so we can translate that into a Dockerfile. This would only work with specifically supported shells. I don't know how hard it would be to do this.
Regarding exit codes, I analyzed all man pages in §1 and §8 on man7.org to find codes that were rarely used by other software (e.g., code 0 is documented by 464 man pages and code 122 by none).
curl(1) documents the most exit codes (0–99) by quite a lot. Notably, it also says that “[m]ore error codes might appear here in future releases”. Whether or how fast this is happening, I don’t know (Git version history was hard to parse).
Thus, a plausible summary of unused or rarely-used exit codes has two parts.
Exit codes used only by curl(1)
There are quite a few, but the ones that seem most obscure to me, and thus least likely to cause a collision in practice, are:
| code | description (quoted) |
|---|---|
| 31 | FTP could not use REST. The REST command failed. This command is used for resumed FTP transfers. |
| 33 | HTTP range error. The range "command" did not work. |
| 49 | Malformed telnet option. |
| 84 | The FTP PRET command failed |
| 87 | Unable to parse FTP file list. |
| ~~88~~ | ~~FTP chunk callback reported error.~~ (edit: can be anti-semetic) |
Exit codes not documented by any man page
100–122 inclusive.
Exit codes ≥128
These are commonly used by shells and other programs that run subprocesses to indicate the child was killed by a signal. E.g. su(1): “If the command was killed by a signal, su returns the number of the signal plus 128”.