Skip to content
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

ENH: Podman Pod commands #341

Closed
mheon opened this issue Feb 15, 2018 · 12 comments
Closed

ENH: Podman Pod commands #341

mheon opened this issue Feb 15, 2018 · 12 comments
Assignees

Comments

@mheon
Copy link
Collaborator

@mheon mheon commented Feb 15, 2018

Libpod now has the ability to create and manage pods. We'd like to expose this through the Podman CLI to allow the management of pods. Our proposed command line is described below

Creating and joining pods

  • Pods are created and joined like containers, via podman run
  • To create a new pod: podman run --pod new
  • To create a new pod with a specific name: podman run --pod new=a_specific_name
  • To join an existing pod by name or ID: podman run --pod pod:name_or_id
  • To join the pod of an existing container: podman run --pod ctr:name_or_id

Managing pods

  • We will add a podman pod subcommand with several management commands under it
  • To list pods, podman pod list (or perhaps podman pod ps?)
  • To start all containers in a pod: podman pod start name_or_id
  • To stop all containers in a pod: podman pod stop name_or_id
  • To send a signal to all containers in a pod: podman kill name_or_id signal

Open Questions:

  • Does creating empty pods make sense? Do we need a podman pod create command?
@baude
Copy link
Collaborator

@baude baude commented Feb 15, 2018

My initial feedback:

  • on creating a new pod with run, i would drop the "new" and if the pod doesn't exist, we create it.
  • to join an existing pod, just give the name or id

I'm also having second thoughts on the pod subcommand. I think it would be cool if podman could take the responsibility of determining if it is a pod or container away from the user. What would you think if we did something like:

podman start pod_name|pod_id|container_name|container_id

but also added a --type pod|container for name collision?

And that abstraction would be applied to the rest of the pod commands?

Loading

@mheon
Copy link
Collaborator Author

@mheon mheon commented Feb 15, 2018

Name collision shouldn't be an issue, names and IDs have to be globally unique - no pod and container can share a name or ID.

Loading

@mheon
Copy link
Collaborator Author

@mheon mheon commented Feb 15, 2018

On reusing start/stop/kill: I wouldn't mind it. It has the advantage of simplicity.

Loading

@rhatdan
Copy link
Member

@rhatdan rhatdan commented Feb 15, 2018

Yes I like that idea. The tough one is run, but that could take a pod command
podman run --pod new -ti fedora sh

Would create a new pod with a container attached.
If we use --pod new --name test

Would we create a name for the pod as test_pod?

podman run --pod UUID -ti fedora sh
podman run --pod test_pod -ti fedora sh

Would join the new container to the existing POD

Loading

@baude
Copy link
Collaborator

@baude baude commented Feb 15, 2018

I think the arguement to the pod would be used like:

  • if now pod exists named that, it would create it.
  • if a pod with that name exists, it will run the container there.

Loading

@mheon
Copy link
Collaborator Author

@mheon mheon commented Feb 15, 2018

Does urfave/cli support flags with optional arguments? I can see things working like this:

  • --pod to make a new pod with a randomly-generated name
  • --pod NAME to make a new pod with the given name, or join the given pod if it exists
  • --pod-from CONTAINER to join the pod from another container

The only potential issue would be not knowing for sure whether you created or joined a pod with --pod NAME -- maybe hvae a --pod-join ID flag that will only join and error if the pod doesn't exist?

Loading

@rhatdan
Copy link
Member

@rhatdan rhatdan commented Feb 15, 2018

I would rather have a keyword like "new" or "scratch" to give --pod to cause it to create a new pod.
I really don't want additional options. And I don't want pod to magically get created on a typo.

Loading

@TomSweeneyRedHat
Copy link
Collaborator

@TomSweeneyRedHat TomSweeneyRedHat commented Feb 15, 2018

+1 to the scratch idea. I was looking for that the other day.

Loading

@rhatdan
Copy link
Member

@rhatdan rhatdan commented Jun 4, 2018

Bumping this up.
@haircommander PTAL

Loading

@vrothberg
Copy link
Member

@vrothberg vrothberg commented Aug 21, 2018

@haircommander Are there remaining open items for this issue or can we close it? I am under the impression that all desired functionality has been implemented but I may be totally wrong :)

Loading

@haircommander
Copy link
Collaborator

@haircommander haircommander commented Aug 21, 2018

@vrothburg pod top is the last one and should be done today! I'll close once it's upstream

Loading

@haircommander
Copy link
Collaborator

@haircommander haircommander commented Aug 23, 2018

Should be good to close via #1298 !

Loading

@rhatdan rhatdan closed this Aug 23, 2018
baude pushed a commit to baude/libpod that referenced this issue Aug 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants