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

Comments

Projects
None yet
6 participants
@mheon
Copy link
Collaborator

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?

@mheon mheon added the enhancement label Feb 15, 2018

@baude

This comment has been minimized.

Copy link
Collaborator

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?

@mheon

This comment has been minimized.

Copy link
Collaborator Author

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.

@mheon

This comment has been minimized.

Copy link
Collaborator Author

mheon commented Feb 15, 2018

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

@rhatdan

This comment has been minimized.

Copy link
Member

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

@baude

This comment has been minimized.

Copy link
Collaborator

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.
@mheon

This comment has been minimized.

Copy link
Collaborator Author

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?

@rhatdan

This comment has been minimized.

Copy link
Member

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.

@TomSweeneyRedHat

This comment has been minimized.

Copy link
Collaborator

TomSweeneyRedHat commented Feb 15, 2018

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

@rhatdan

This comment has been minimized.

Copy link
Member

rhatdan commented Jun 4, 2018

Bumping this up.
@haircommander PTAL

@vrothberg

This comment has been minimized.

Copy link
Member

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 :)

@haircommander

This comment has been minimized.

Copy link
Collaborator

haircommander commented Aug 21, 2018

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

@haircommander

This comment has been minimized.

Copy link
Collaborator

haircommander commented Aug 23, 2018

Should be good to close via #1298 !

@rhatdan rhatdan closed this Aug 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment