-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Container Rename #8955
Container Rename #8955
Conversation
Status: Libpod backend is functional, but needs to be refactored into the database to remove potentially-serious atomicity issues. That can probably wait until a follow-on PR. CLI frontend has been implemented, but needs completions and valid args tweaked. API endpoints for Compat and Libpod have been implemented. Bindings, documentation, and tests are missing. |
cmd/podman/containers/rename.go
Outdated
Long: renameDescription, | ||
RunE: rename, | ||
Args: cobra.ExactArgs(2), // TODO we can do better here - check that #1 is container ID, #2 is a name | ||
//ValidArgsFunction: common.AutocompleteContainers, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend using common.AutocompletePortCommand
as ValidArgsFunction
. This will complete only the first argument as container name or id.
ExactArgs(2)
looks fine. I am not sure why you would want to check for an ID. The code and the example also seem to allow a name as first arg.
4d9cec1
to
b12932d
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mheon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Stripping WIP |
Args: cobra.ExactArgs(2), // TODO we can do better here - check that #1 is container ID, #2 is a name | ||
//ValidArgsFunction: common.AutocompleteContainers, | ||
Args: cobra.ExactArgs(2), | ||
ValidArgsFunction: common.AutocompletePortCommand, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this correct? PortCommand?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Luap99 recommended it - it completes the first argument as an existing container and does no completion on the second argument
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok we should get a different name for it then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I will put this on my TODO list. I just need to find a descriptive name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which can probably happen in a separate PR, because this needs to merge in the next 3-ish hours 😄
Looks great, need to squash some of the commits. |
bef861c
to
36b45f2
Compare
Squashed down |
594e6ae
to
23e767e
Compare
d55d34c
to
27f33a9
Compare
## DESCRIPTION | ||
Rename changes the name of an existing container. | ||
The old name will be freed, and will be available for use. | ||
This command can be run on containers that are running without difficulty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what "without difficulty" means. Can we list the states that a container can be in instead? Or perhaps if it's easier, which state(s) the container can NOT be in?
LGTM |
1603ba9
to
3a6963c
Compare
/lgtm |
This is not going to go green. I am fighting documentation CI (specifically swagger and Ed's manpage checker). |
@@ -1463,5 +1490,34 @@ func (s *APIServer) registerContainersHandlers(r *mux.Router) error { | |||
// 500: | |||
// $ref: "#/responses/InternalError" | |||
r.HandleFunc(VersionedPath("/libpod/containers/{name}/init"), s.APIHandler(libpod.InitContainer)).Methods(http.MethodPost) | |||
// swagger:operation POST /libpod/containers/{name}/rename renameContainer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// swagger:operation POST /libpod/containers/{name}/rename renameContainer | |
// swagger:operation POST /libpod/containers/{name}/rename libpod libpodRenameContainer |
Try this. I have not tested it but I am confident that this fixes the swagger test.
LGTM |
Swagger is still angry |
7b90f11
to
310baca
Compare
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 <[email protected]>
One test flaked. I think everything else is going to go green. |
/hold cancel |
/lgtm |
Add initial support for the
podman rename
command.Very much in-progress.
Fixes #1925