summaryrefslogtreecommitdiff
path: root/libpod
diff options
context:
space:
mode:
authorMatthew Heon <mheon@redhat.com>2019-11-14 10:19:17 -0500
committerBrent Baude <bbaude@redhat.com>2020-02-04 08:10:23 -0600
commit4567f39800ecce469b7642de3b9613ab59ea4a83 (patch)
treed47f76b0244fb4c8c44646fd69bae2bbfaf22a82 /libpod
parentc4f6d5615a34ea67b1335a2a446bd09789d98015 (diff)
downloadpodman-4567f39800ecce469b7642de3b9613ab59ea4a83.tar.gz
podman-4567f39800ecce469b7642de3b9613ab59ea4a83.tar.bz2
podman-4567f39800ecce469b7642de3b9613ab59ea4a83.zip
Initial implementation of a spec generator package
The current Libpod pkg/spec has become a victim of the better part of three years of development that tied it extremely closely to the current Podman CLI. Defaults are spread across multiple places, there is no easy way to produce a CreateConfig that will actually produce a valid container, and the logic for generating configs has sprawled across at least three packages. This is an initial pass at a package that generates OCI specs that will supersede large parts of the current pkg/spec. The CreateConfig will still exist, but will effectively turn into a parsed CLI. This will be compiled down into the new SpecGenerator struct, which will generate the OCI spec and Libpod create options. The preferred integration point for plugging into Podman's Go API to create containers will be the new CreateConfig, as it's less tied to Podman's command line. CRI-O, for example, will likely tie in here. Signed-off-by: Matthew Heon <mheon@redhat.com>
Diffstat (limited to 'libpod')
-rw-r--r--libpod/container.go2
1 files changed, 1 insertions, 1 deletions
diff --git a/libpod/container.go b/libpod/container.go
index f29cebf20..5e5c8ab26 100644
--- a/libpod/container.go
+++ b/libpod/container.go
@@ -244,7 +244,7 @@ type ContainerConfig struct {
// UID/GID mappings used by the storage
IDMappings storage.IDMappingOptions `json:"idMappingsOptions,omitempty"`
- // Information on the image used for the root filesystem/
+ // Information on the image used for the root filesystem
RootfsImageID string `json:"rootfsImageID,omitempty"`
RootfsImageName string `json:"rootfsImageName,omitempty"`
// Rootfs to use for the container, this conflicts with RootfsImageID