2:28 a.m.
Hi there!
I discovered Podman recently and started to use it as a great alternative to Docker.
My question is about application updates. Let's say you have a pod running and you
want to update the code for the app in that pod. Is there a simple manner to manage
something similar to a Kubernetes rolling update? By rolling update, I mean performing an
update with no service interruptions (i.e. starting a new pod running the new app version,
switch the network traffic to the new pod and terminate the old pod).
Kind Regards,
Laurent Pellegrino
12:28 p.m.
On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com wrote:
Hi there!
I discovered Podman recently and started to use it as a great alternative to Docker.
My question is about application updates. Let's say you have a pod running and you
want to update the code for the app in that pod. Is there a simple manner to manage
something similar to a Kubernetes rolling update? By rolling update, I mean performing an
update with no service interruptions (i.e. starting a new pod running the new app version,
switch the network traffic to the new pod and terminate the old pod).
Kind Regards,
Laurent Pellegrino
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
We are actually investigating this workflow. But have not taken as far
as you want. The idea would be to be running a container, and then have
a job start periodically that would see if their was an update to the
image that the container was running on. It would pull the image down
and restart the container service, which would destroy the old container
and create a new container with the same params. This however would not
maintain the the connections.
6:28 a.m.
Thanks for the information.
Just to understand, why are you considering a periodic job?
This however would not maintain the the connections.
OK, so for now, the only solution seems to deploy a proxy that supports
dynamic configurations with no restarts?
Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com wrote:
> Hi there!
>
> I discovered Podman recently and started to use it as a great
alternative to Docker.
>
> My question is about application updates. Let's say you have a pod
running and you want to update the code for the app in that pod. Is there a
simple manner to manage something similar to a Kubernetes rolling update?
By rolling update, I mean performing an update with no service
interruptions (i.e. starting a new pod running the new app version, switch
the network traffic to the new pod and terminate the old pod).
>
> Kind Regards,
>
> Laurent Pellegrino
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
We are actually investigating this workflow. But have not taken as far
as you want. The idea would be to be running a container, and then have
a job start periodically that would see if their was an update to the
image that the container was running on. It would pull the image down
and restart the container service, which would destroy the old container
and create a new container with the same params. This however would not
maintain the the connections.
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
7:46 a.m.
On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
Thanks for the information.
Just to understand, why are you considering a periodic job?
We don't know when the image that the container is based on will be
updated. So checking once a day seems like a reasonable thing to do.
How else would you suggest we do this?
> This however would not maintain the the connections.
OK, so for now, the only solution seems to deploy a proxy that
supports dynamic configurations with no restarts?
Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>> a écrit :
On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com
<mailto:laurent.pellegrino@gmail.com> wrote:
> Hi there!
>
> I discovered Podman recently and started to use it as a great
alternative to Docker.
>
> My question is about application updates. Let's say you have a
pod running and you want to update the code for the app in that
pod. Is there a simple manner to manage something similar to a
Kubernetes rolling update? By rolling update, I mean performing an
update with no service interruptions (i.e. starting a new pod
running the new app version, switch the network traffic to the new
pod and terminate the old pod).
>
> Kind Regards,
>
> Laurent Pellegrino
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
We are actually investigating this workflow. But have not taken as far
as you want. The idea would be to be running a container, and
then have
a job start periodically that would see if their was an update to the
image that the container was running on. It would pull the image down
and restart the container service, which would destroy the old
container
and create a new container with the same params. This however
would not
maintain the the connections.
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
8:04 a.m.
I don't know about internals so it may not apply but regarding the use case
I described briefly, I know what pod to update and what new image to use.
Also, the image is available at the time the update must be performed.
Taking Kubernetes as an example [1], from a CLI point of view, I would see
something like this:
podman rolling-update PODNAME --image=IMAGE:TAG
The main point is about updating the service/pod without an outage.
[1]
https://kubernetes.io/docs/tasks/run-application/rolling-update-replicati...
Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
Thanks for the information.
Just to understand, why are you considering a periodic job?
We don't know when the image that the container is based on will be
updated. So checking once a day seems like a reasonable thing to do. How
else would you suggest we do this?
> This however would not maintain the the connections.
OK, so for now, the only solution seems to deploy a proxy that supports
dynamic configurations with no restarts?
Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com wrote:
> > Hi there!
> >
> > I discovered Podman recently and started to use it as a great
> alternative to Docker.
> >
> > My question is about application updates. Let's say you have a pod
> running and you want to update the code for the app in that pod. Is there a
> simple manner to manage something similar to a Kubernetes rolling update?
> By rolling update, I mean performing an update with no service
> interruptions (i.e. starting a new pod running the new app version, switch
> the network traffic to the new pod and terminate the old pod).
> >
> > Kind Regards,
> >
> > Laurent Pellegrino
> > _______________________________________________
> > Podman mailing list -- podman(a)lists.podman.io
> > To unsubscribe send an email to podman-leave(a)lists.podman.io
>
> We are actually investigating this workflow. But have not taken as far
> as you want. The idea would be to be running a container, and then have
> a job start periodically that would see if their was an update to the
> image that the container was running on. It would pull the image down
> and restart the container service, which would destroy the old container
> and create a new container with the same params. This however would not
> maintain the the connections.
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> To unsubscribe send an email to podman-leave(a)lists.podman.io
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
9:12 a.m.
On 2/4/20 9:04 AM, Laurent Pellegrino wrote:
I don't know about internals so it may not apply but regarding
the use
case I described briefly, I know what pod to update and what new image
to use. Also, the image is available at the time the update must be
performed.
Taking Kubernetes as an example [1], from a CLI point of view, I would
see something like this:
> podman rolling-update PODNAME --image=IMAGE:TAG
Sure but you could script up the same thing.
podman pull images related to pod.
Then stop/destroy the pod/containers. Recreate the pod/containers.
I am not against your idea, but it brings in the Human element, I want
to automate this process which is why I suggested a cron job.
In your case the admin needs to realize that one of the containers in
the Pod uses an image that has been updated, and now triggers the service.
I would prefer to just have the system figure out whether an update is
needed.
The main point is about updating the service/pod without an outage.
[1] https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/#updating-the-container-image
Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>> a écrit :
On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
> Thanks for the information.
>
> Just to understand, why are you considering a periodic job?
>
We don't know when the image that the container is based on will
be updated. So checking once a day seems like a reasonable thing
to do. How else would you suggest we do this?
> > This however would not maintain the the connections.
>
> OK, so for now, the only solution seems to deploy a proxy that
> supports dynamic configurations with no restarts?
>
> Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com
> <mailto:dwalsh@redhat.com>> a écrit :
>
> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com
> <mailto:laurent.pellegrino@gmail.com> wrote:
> > Hi there!
> >
> > I discovered Podman recently and started to use it as a
> great alternative to Docker.
> >
> > My question is about application updates. Let's say you
> have a pod running and you want to update the code for the
> app in that pod. Is there a simple manner to manage something
> similar to a Kubernetes rolling update? By rolling update, I
> mean performing an update with no service interruptions (i.e.
> starting a new pod running the new app version, switch the
> network traffic to the new pod and terminate the old pod).
> >
> > Kind Regards,
> >
> > Laurent Pellegrino
> > _______________________________________________
> > Podman mailing list -- podman(a)lists.podman.io
> <mailto:podman@lists.podman.io>
> > To unsubscribe send an email to
> podman-leave(a)lists.podman.io
> <mailto:podman-leave@lists.podman.io>
>
> We are actually investigating this workflow. But have not
> taken as far
> as you want. The idea would be to be running a container,
> and then have
> a job start periodically that would see if their was an
> update to the
> image that the container was running on. It would pull the
> image down
> and restart the container service, which would destroy the
> old container
> and create a new container with the same params. This
> however would not
> maintain the the connections.
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> <mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
> <mailto:podman-leave@lists.podman.io>
>
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
10:02 a.m.
OK, I better understand.
For sure, if the purpose is just to recreate the pod/containers with a new
image then the command suggested previously has low interest, the main
value would be to keep the connections (i.e. updating the service/pod
without an outage).
In your case the admin needs to realize that one of the containers in
the
Pod uses an image that has been updated, and now triggers the service.
In my case, the admin is a continuous deployment script. The update is
triggered for instance by a Github action on a new commit in a Git
repository.
Le mar. 4 févr. 2020 à 16:13, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
> On 2/4/20 9:04 AM, Laurent Pellegrino wrote:
>
> I don't know about internals so it may not apply but regarding the use
> case I described briefly, I know what pod to update and what new image to
> use. Also, the image is available at the time the update must be
> performed.
>
> Taking Kubernetes as an example [1], from a CLI point of view, I would see
> something like this:
>
> > podman rolling-update PODNAME --image=IMAGE:TAG
>
> Sure but you could script up the same thing.
>
> podman pull images related to pod.
>
> Then stop/destroy the pod/containers. Recreate the pod/containers.
>
> I am not against your idea, but it brings in the Human element, I want to
> automate this process which is why I suggested a cron job.
>
In your case the admin needs to realize that one of the containers in
the
> Pod uses an image that has been updated, and now triggers the service.
>
> I would prefer to just have the system figure out whether an update is
> needed.
>
>
> The main point is about updating the service/pod without an outage.
>
> [1]
>
https://kubernetes.io/docs/tasks/run-application/rolling-update-replicati...
>
> Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
>
>> On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
>>
>> Thanks for the information.
>>
>> Just to understand, why are you considering a periodic job?
>>
>> We don't know when the image that the container is based on will be
>> updated. So checking once a day seems like a reasonable thing to do. How
>> else would you suggest we do this?
>>
>> > This however would not maintain the the connections.
>>
>> OK, so for now, the only solution seems to deploy a proxy that supports
>> dynamic configurations with no restarts?
>>
>> Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
>>
>>> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com wrote:
>>> > Hi there!
>>> >
>>> > I discovered Podman recently and started to use it as a great
>>> alternative to Docker.
>>> >
>>> > My question is about application updates. Let's say you have a pod
>>> running and you want to update the code for the app in that pod. Is there a
>>> simple manner to manage something similar to a Kubernetes rolling update?
>>> By rolling update, I mean performing an update with no service
>>> interruptions (i.e. starting a new pod running the new app version, switch
>>> the network traffic to the new pod and terminate the old pod).
>>> >
>>> > Kind Regards,
>>> >
>>> > Laurent Pellegrino
>>> > _______________________________________________
>>> > Podman mailing list -- podman(a)lists.podman.io
>>> > To unsubscribe send an email to podman-leave(a)lists.podman.io
>>>
>>> We are actually investigating this workflow. But have not taken as far
>>> as you want. The idea would be to be running a container, and then have
>>> a job start periodically that would see if their was an update to the
>>> image that the container was running on. It would pull the image down
>>> and restart the container service, which would destroy the old container
>>> and create a new container with the same params. This however would not
>>> maintain the the connections.
>>> _______________________________________________
>>> Podman mailing list -- podman(a)lists.podman.io
>>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>>
>>
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>
>>
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>
>
>
2:57 p.m.
On 2/4/20 11:02 AM, Laurent Pellegrino wrote:
OK, I better understand.
For sure, if the purpose is just to recreate the pod/containers with a
new image then the command suggested previously has low interest, the
main value would be to keep the connections (i.e. updating the
service/pod without an outage).
> In your case the admin needs to realize that one of the containers
in the Pod uses an image that has been updated, and now triggers the
service.
In my case, the admin is a continuous deployment script. The update is
triggered for instance by a Github action on a new commit in a Git
repository.
Valentin WDYT?
Le mar. 4 févr. 2020 à 16:13, Daniel Walsh <dwalsh(a)redhat.com
<mailto:dwalsh@redhat.com>> a écrit :
On 2/4/20 9:04 AM, Laurent Pellegrino wrote:
> I don't know about internals so it may not apply but regarding
> the use case I described briefly, I know what pod to update and
> what new image to use. Also, the image is available at the time
> the update must be performed.
>
> Taking Kubernetes as an example [1], from a CLI point of view, I
> would see something like this:
>
> > podman rolling-update PODNAME --image=IMAGE:TAG
>
Sure but you could script up the same thing.
podman pull images related to pod.
Then stop/destroy the pod/containers. Recreate the pod/containers.
I am not against your idea, but it brings in the Human element, I
want to automate this process which is why I suggested a cron job.
In your case the admin needs to realize that one of the containers
in the Pod uses an image that has been updated, and now triggers
the service.
I would prefer to just have the system figure out whether an
update is needed.
> The main point is about updating the service/pod without an outage.
>
>
[1] https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/#updating-the-container-image
>
> Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com
> <mailto:dwalsh@redhat.com>> a écrit :
>
> On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
>> Thanks for the information.
>>
>> Just to understand, why are you considering a periodic job?
>>
> We don't know when the image that the container is based on
> will be updated. So checking once a day seems like a
> reasonable thing to do. How else would you suggest we do this?
>> > This however would not maintain the the connections.
>>
>> OK, so for now, the only solution seems to deploy a proxy
>> that supports dynamic configurations with no restarts?
>>
>> Le lun. 3 févr. 2020 à 19:28, Daniel Walsh
>> <dwalsh(a)redhat.com <mailto:dwalsh@redhat.com>> a écrit :
>>
>> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com
>> <mailto:laurent.pellegrino@gmail.com> wrote:
>> > Hi there!
>> >
>> > I discovered Podman recently and started to use it as
>> a great alternative to Docker.
>> >
>> > My question is about application updates. Let's say
>> you have a pod running and you want to update the code
>> for the app in that pod. Is there a simple manner to
>> manage something similar to a Kubernetes rolling update?
>> By rolling update, I mean performing an update with no
>> service interruptions (i.e. starting a new pod running
>> the new app version, switch the network traffic to the
>> new pod and terminate the old pod).
>> >
>> > Kind Regards,
>> >
>> > Laurent Pellegrino
>> > _______________________________________________
>> > Podman mailing list -- podman(a)lists.podman.io
>> <mailto:podman@lists.podman.io>
>> > To unsubscribe send an email to
>> podman-leave(a)lists.podman.io
>> <mailto:podman-leave@lists.podman.io>
>>
>> We are actually investigating this workflow. But have
>> not taken as far
>> as you want. The idea would be to be running a
>> container, and then have
>> a job start periodically that would see if their was an
>> update to the
>> image that the container was running on. It would pull
>> the image down
>> and restart the container service, which would destroy
>> the old container
>> and create a new container with the same params. This
>> however would not
>> maintain the the connections.
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
>> <mailto:podman@lists.podman.io>
>> To unsubscribe send an email to
>> podman-leave(a)lists.podman.io
>> <mailto:podman-leave@lists.podman.io>
>>
>>
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
<mailto:podman@lists.podman.io>
>> To unsubscribe send an email to podman-leave(a)lists.podman.io
<mailto:podman-leave@lists.podman.io>
>
>
> _______________________________________________
> Podman mailing list -- podman(a)lists.podman.io
> <mailto:podman@lists.podman.io>
> To unsubscribe send an email to podman-leave(a)lists.podman.io
> <mailto:podman-leave@lists.podman.io>
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
3:36 a.m.
On Tue, Feb 4, 2020 at 9:57 PM Daniel Walsh <dwalsh(a)redhat.com> wrote:
On 2/4/20 11:02 AM, Laurent Pellegrino wrote:
OK, I better understand.
For sure, if the purpose is just to recreate the pod/containers with a new
image then the command suggested previously has low interest, the main
value would be to keep the connections (i.e. updating the service/pod
without an outage).
> In your case the admin needs to realize that one of the containers in
the Pod uses an image that has been updated, and now triggers the service.
In my case, the admin is a continuous deployment script. The update is
triggered for instance by a Github action on a new commit in a Git
repository.
Valentin WDYT?
TL;DR : My 2 cents are that a *podman-update* command is possible (maybe
restricted to K8s yaml) but no-downtime and rollbacks are IMHO out of scope.
The two scenarios seem quite related. If we had a *podman-update* command
that *could* do that, then both scenarios would be covered.
However, we did not plan for such a command but to implement updates by
restarting systemd services that recreate containers. This certainly
includes some downtime of the service. Doing that in Podman without a
downtime is at least incredibly complex, if not impossible for some cases
(e.g., duplicate ports etc.).
Use cases that require a downtime-free update, maybe even rollbacks, are
IMHO leaving the single-node use case that Podman targets and enter the
orchestration & Kubernetes world. A concrete technical challenge for Podman
is recreating the *same* Pod/Container we want to update. In the Kubernetes
world, that's fairly easy since everything is created via yaml files where
bumping the image to a newer version is trivial. We don't have this
guarantee in Podman as there are *many* different ways to create a Pod or
container (e..g, via the CLI, the remote API, the native golang API, or K8s
yaml). This makes the cloning of a pod/container much more complex and
prone to errors. On the other hand, we could enforce that we only support
rolling updates for Pods created via *podman-play-kube (i.e., via a K8s
yaml) *but the downtime issue would still remain. IMHO, no downtime
requires a cluster and that's out of Podman's scope.
Le mar. 4 févr. 2020 à 16:13, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
> On 2/4/20 9:04 AM, Laurent Pellegrino wrote:
>
> I don't know about internals so it may not apply but regarding the use
> case I described briefly, I know what pod to update and what new image to
> use. Also, the image is available at the time the update must be
> performed.
>
> Taking Kubernetes as an example [1], from a CLI point of view, I would
> see something like this:
>
> > podman rolling-update PODNAME --image=IMAGE:TAG
>
> Sure but you could script up the same thing.
>
> podman pull images related to pod.
>
> Then stop/destroy the pod/containers. Recreate the pod/containers.
>
> I am not against your idea, but it brings in the Human element, I want to
> automate this process which is why I suggested a cron job.
>
> In your case the admin needs to realize that one of the containers in the
> Pod uses an image that has been updated, and now triggers the service.
>
> I would prefer to just have the system figure out whether an update is
> needed.
>
>
> The main point is about updating the service/pod without an outage.
>
> [1]
>
https://kubernetes.io/docs/tasks/run-application/rolling-update-replicati...
>
> Le mar. 4 févr. 2020 à 14:46, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
>
>> On 2/4/20 7:28 AM, Laurent Pellegrino wrote:
>>
>> Thanks for the information.
>>
>> Just to understand, why are you considering a periodic job?
>>
>> We don't know when the image that the container is based on will be
>> updated. So checking once a day seems like a reasonable thing to do. How
>> else would you suggest we do this?
>>
>> > This however would not maintain the the connections.
>>
>> OK, so for now, the only solution seems to deploy a proxy that supports
>> dynamic configurations with no restarts?
>>
>> Le lun. 3 févr. 2020 à 19:28, Daniel Walsh <dwalsh(a)redhat.com> a écrit :
>>
>>> On 2/1/20 3:28 AM, laurent.pellegrino(a)gmail.com wrote:
>>> > Hi there!
>>> >
>>> > I discovered Podman recently and started to use it as a great
>>> alternative to Docker.
>>> >
>>> > My question is about application updates. Let's say you have a pod
>>> running and you want to update the code for the app in that pod. Is there a
>>> simple manner to manage something similar to a Kubernetes rolling update?
>>> By rolling update, I mean performing an update with no service
>>> interruptions (i.e. starting a new pod running the new app version, switch
>>> the network traffic to the new pod and terminate the old pod).
>>> >
>>> > Kind Regards,
>>> >
>>> > Laurent Pellegrino
>>> > _______________________________________________
>>> > Podman mailing list -- podman(a)lists.podman.io
>>> > To unsubscribe send an email to podman-leave(a)lists.podman.io
>>>
>>> We are actually investigating this workflow. But have not taken as far
>>> as you want. The idea would be to be running a container, and then have
>>> a job start periodically that would see if their was an update to the
>>> image that the container was running on. It would pull the image down
>>> and restart the container service, which would destroy the old container
>>> and create a new container with the same params. This however would not
>>> maintain the the connections.
>>> _______________________________________________
>>> Podman mailing list -- podman(a)lists.podman.io
>>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>>
>>
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>
>>
>> _______________________________________________
>> Podman mailing list -- podman(a)lists.podman.io
>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>>
>
>
_______________________________________________
Podman mailing list -- podman(a)lists.podman.io
To unsubscribe send an email to podman-leave(a)lists.podman.io
1782
days inactive
1786
days old
8 comments
4 participants
participants (4)
-
Daniel Walsh -
Laurent Pellegrino -
laurent.pellegrino＠gmail.com
-
Valentin Rothberg