mirror of
https://github.com/podman-container-tools/podman.git
synced 2026-10-21 21:37:38 +00:00
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> |
||
|---|---|---|
| .. | ||
| common | ||
| completion | ||
| containers | ||
| generate | ||
| healthcheck | ||
| images | ||
| inspect | ||
| manifest | ||
| networks | ||
| parse | ||
| play | ||
| pods | ||
| registry | ||
| system | ||
| utils | ||
| validate | ||
| volumes | ||
| auto-update.go | ||
| diff.go | ||
| early_init_linux.go | ||
| early_init_unsupported.go | ||
| inspect.go | ||
| login.go | ||
| logout.go | ||
| main.go | ||
| README.md | ||
| root.go | ||
| root_test.go | ||
| shell_completion_test.go | ||
| syslog_linux.go | ||
| syslog_unsupported.go | ||
Podman CLI
The following is an example of how to add a new primary command (manifest) and a sub-command (inspect) to the Podman CLI.
This is example code, the production code has additional error checking and the business logic provided.
See items below for details on building, installing, contributing to Podman:
Adding a new command podman manifest
$ mkdir -p $GOPATH/src/github.com/containers/podman/cmd/podmanV2/manifests
Create the file $GOPATH/src/github.com/containers/podman/cmd/podmanV2/manifests/manifest.go
package manifests
import (
"github.com/containers/podman/cmd/podman/registry"
"github.com/containers/podman/cmd/podman/validate"
"github.com/containers/podman/pkg/domain/entities"
"github.com/spf13/cobra"
)
var (
// podman _manifests_
manifestCmd = &cobra.Command{
Use: "manifest",
Short: "Manage manifests",
Args: cobra.ExactArgs(1),
Long: "Manage manifests",
Example: "podman manifest IMAGE",
TraverseChildren: true,
RunE: validate.SubCommandExists, // Report error if there is no sub command given
}
)
func init() {
// Subscribe command to podman
registry.Commands = append(registry.Commands, registry.CliCommand{
// _podman manifest_ will support both ABIMode and TunnelMode
Mode: []entities.EngineMode{entities.ABIMode, entities.TunnelMode},
// The definition for this command
Command: manifestCmd,
})
}
To "wire" in the manifest command, edit the file $GOPATH/src/github.com/containers/podman/cmd/podmanV2/main.go to add:
package main
import _ "github.com/containers/podman/cmd/podman/manifests"
Adding a new sub command podman manifests list
Create the file $GOPATH/src/github.com/containers/podman/cmd/podmanV2/manifests/inspect.go
package manifests
import (
"github.com/containers/podman/cmd/podman/registry"
"github.com/containers/podman/pkg/domain/entities"
"github.com/spf13/cobra"
)
var (
// podman manifests _inspect_
inspectCmd = &cobra.Command{
Use: "inspect IMAGE",
Short: "Display manifest from image",
Long: "Displays the low-level information on a manifest identified by image name or ID",
RunE: inspect,
Annotations: map[string]string{
// Add this annotation if this command cannot be run rootless
// registry.ParentNSRequired: "",
},
Example: "podman manifest inspect DEADBEEF",
}
)
func init() {
// Subscribe inspect sub command to manifest command
registry.Commands = append(registry.Commands, registry.CliCommand{
// _podman manifest inspect_ will support both ABIMode and TunnelMode
Mode: []entities.EngineMode{entities.ABIMode, entities.TunnelMode},
// The definition for this command
Command: inspectCmd,
// The parent command to proceed this command on the CLI
Parent: manifestCmd,
})
// This is where you would configure the cobra flags using inspectCmd.Flags()
}
// Business logic: cmd is inspectCmd, args is the positional arguments from os.Args
func inspect(cmd *cobra.Command, args []string) error {
// Business logic using registry.ImageEngine()
// Do not pull from libpod directly use the domain objects and types
return nil
}
Helper functions
The complete set can be found in the validate package, here are some examples:
cobra.Command{ Args: validate.NoArgs }used when the command does not accept errorscobra.Command{ Args: validate.IdOrLatestArgs }used to ensure either a list of ids given or the --latest flagcobra.Command{ RunE: validate.SubCommandExists }used to validate a subcommand given to a commandvalidate.ChoiceValueused to create apflag.Valuethat validate user input against a provided slice of values. For example:flags := cobraCommand.Flags() created := validate.ChoiceValue(&opts.Sort, "command", "created", "id", "image", "names", "runningfor", "size", "status") flags.Var(created, "sort", "Sort output by: "+created.Choices())