997de2f8e9
Basic theory: We remove the container, but *only from the DB*. We leave it in c/storage, we leave the lock allocated, we leave it running (if it is). Then we create an identical container with an altered name, and add that back to the database. Theoretically we now have a renamed container. The advantage of this approach is that it doesn't just apply to rename - we can use this to make *any* configuration change to a container that does not alter its container ID. Potential problems are numerous. This process is *THOROUGHLY* non-atomic at present - if you `kill -9` Podman mid-rename things will be in a bad place, for example. Also, we can't rename containers that can't be removed normally - IE, containers with dependencies (pod infra containers, for example). The largest potential improvement will be to move the majority of the work into the DB, with a `RecreateContainer()` method - that will add atomicity, and let us remove the container without worrying about depencies and similar issues. Potential problems: long-running processes that edit the DB and may have an older version of the configuration around. Most notable example is `podman run --rm` - the removal command needed to be manually edited to avoid this one. This begins to get at the heart of me not wanting to do this in the first place... This provides CLI and API implementations for frontend, but no tunnel implementation. It will be added in a future release (just held back for time now - we need this in 3.0 and are running low on time). This is honestly kind of horrifying, but I think it will work. Signed-off-by: Matthew Heon <mheon@redhat.com> |
||
|---|---|---|
| .. | ||
| source | ||
| tutorials | ||
| dckrman.sh | ||
| links-to-html.lua | ||
| make.bat | ||
| Makefile | ||
| play.png | ||
| podman-derivative-api | ||
| Readme.md | ||
| remote-docs.sh | ||
| requirements.txt | ||
Podman Documentation
The online man pages and other documents regarding Podman can be found at Read The Docs. The man pages can be found under the Commands link on that page.
Build the Docs
Directory Structure
| Directory | |
|---|---|
| Markdown source for man pages | docs/source/markdown/ |
| man pages aliases as .so files | docs/source/markdown/links/ |
| restructured text for readthedocs.io | docs/rst/ |
| target for output | docs/build |
| man pages | docs/build/man |
| remote linux man pages | docs/build/remote/linux |
| remote darwin man pages | docs/build/remote/darwin |
| remote windows html pages | docs/build/remote/windows |
Support files
| docs/remote-docs.sh | Read the docs/source/markdown files and format for each platform |
| docs/links-to-html.lua | pandoc filter to do aliases for html files |
API Reference
The latest online documentation is
automatically generated by two cooperating automation systems based on committed upstream
source code. Firstly, the Cirrus-CI docs task builds
pkg/api/swagger.yaml and uploads it to a public-facing location (Google Storage Bucket -
an online service for storing unstructured data). Second, Read The Docs
reacts to the github.com repository change, building the content for the libpod documentation
site. This site includes for the API section,
some javascript which consumes the uploaded swagger.yaml file directly from the Google
Storage Bucket.
Since there are multiple systems and local cache is involved, it's possible that updates to documentation (especially the swagger/API docs) will lag by 10-or-so minutes. However, because the client (i.e. your web browser) is fetching content from multiple locations that do not share a common domain, accessing the API section may show a stack-trace similar to the following:
If reloading the page, or clearing your local cache does not fix the problem, it is
likely caused by broken metadata needed to protect clients from cross-site-scripting
style attacks. Please notify a maintainer
so they may investigate how/why the swagger.yaml file's CORS-metadata is
incorrect, or the file isn't accessible for some other reason.