podman/docs
Matthew Heon b53cb57680 Initial implementation of volume plugins
This implements support for mounting and unmounting volumes
backed by volume plugins. Support for actually retrieving
plugins requires a pull request to land in containers.conf and
then that to be vendored, and as such is not yet ready. Given
this, this code is only compile tested. However, the code for
everything past retrieving the plugin has been written - there is
support for creating, removing, mounting, and unmounting volumes,
which should allow full functionality once the c/common PR is
merged.

A major change is the signature of the MountPoint function for
volumes, which now, by necessity, returns an error. Named volumes
managed by a plugin do not have a mountpoint we control; instead,
it is managed entirely by the plugin. As such, we need to cache
the path in the DB, and calls to retrieve it now need to access
the DB (and may fail as such).

Notably absent is support for SELinux relabelling and chowning
these volumes. Given that we don't manage the mountpoint for
these volumes, I am extremely reluctant to try and modify it - we
could easily break the plugin trying to chown or relabel it.

Also, we had no less than *5* separate implementations of
inspecting a volume floating around in pkg/infra/abi and
pkg/api/handlers/libpod. And none of them used volume.Inspect(),
the only correct way of inspecting volumes. Remove them all and
consolidate to using the correct way. Compat API is likely still
doing things the wrong way, but that is an issue for another day.

Fixes #4304

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
2021-01-14 15:35:33 -05:00
..
source Initial implementation of volume plugins 2021-01-14 15:35:33 -05:00
tutorials Switch references of /var/run -> /run 2021-01-07 05:37:24 -05:00
dckrman.sh Fix docker man page links 2020-03-19 14:03:02 -04:00
links-to-html.lua Update XML to not embed quote in PATH on windows 2020-01-31 15:22:20 -07:00
make.bat Restructure documentation dir 2019-10-31 12:31:39 -05:00
Makefile Restructure documentation dir 2019-10-31 12:31:39 -05:00
play.png Initial checkin from CRI-O repo 2017-11-01 11:24:59 -04:00
podman-derivative-api Remove varlink support from Podman 2020-11-26 16:50:42 -05:00
Readme.md Spelling 2020-12-22 13:34:31 -05:00
remote-docs.sh Switch use of Flags to Options 2020-10-21 08:37:57 -04:00
requirements.txt Fix markdown tables on docs.podman.io 2020-11-13 16:42:13 +01:00

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:

JavaScript Stack Trace Image

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.