Add support for inspecting Mounts which include SubPaths.
Handle SubPaths for kubernetes image volumes.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
If volume ls was called while another volume was removed at the right
time it could have failed with "no such volume" as we did not ignore
such error during listing. As we list things and this no longer exists
the correct thing is to ignore the error and continue like we do with
containers, pods, etc...
This was pretty easy to reproduce with these two commands running in
different terminals:
while :; do bin/podman volume create test && bin/podman volume rm test || break; done
while :; do bin/podman volume ls || break ; done
I have a slight feeling that this might solve #23913 but I am not to
sure there so I am not adding a Fixes here.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
move the podman roadmap into a separate file and began a feature
development log. also, small statements on our process of feature
prioritization.
Signed-off-by: Brent Baude <bbaude@redhat.com>
This is not needed and was added by during debugging but it turned out
to be something else. We should not lock the thread unless needed
because this just raises question why it is here otherwise.
Also the lock would not do much as we spawn a goroutine below anyway so
it runs on another thread no matter what.
From the review comment by Miloslav but it was merged before I had the
chance to fix it:
https://github.com/containers/podman/pull/24406#discussion_r1828102666
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
By default today, the container is always started if its pod is also
started. This prevents to create custom with systemd where containers in
a pod could be started through their `[Install]` section.
We add a key `StartWithPod=`, enabled by default, that enables one to
disable that behavior.
This prevents the pod service from changing the state of the container
service.
Fixes#24401
Signed-off-by: Farya L. Maerten <me@ltow.me>
API clients expect the status code quickly otherwise they can time out.
If we do not flush we may not write the header immediately and only when
futher logs are send.
Fixes#23712
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
One of the problems with the Events() API was that you had to call it in
a new goroutine. This meant the the error returned by it had to be read
back via a second channel. This cuased other bugs in the past but here
the biggest problem is that basic errors such as invalid since/until
options were not directly returned to the caller.
It meant in the API we were not able to write http code 200 quickly
because we always waited for the first event or error from the
channels. This in turn made some clients not happy as they assume the
server hangs on time out if no such events are generated.
To fix this we resturcture the entire event flow. First we spawn the
goroutine inside the eventer Read() function so not all the callers have
to. Then we can return the basic error quickly without the goroutine.
The caller then checks the error like any normal function and the API
can use this one to decide which status code to return.
Second we now return errors/event in one channel then the callers can
decide to ignore or log them which makes it a bit more clear.
Fixes c46884aa93 ("podman events: check for an error after we finish reading events")
Fixes#23712
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This type is unsused, undocumented and basically broken. If this would
be used anywhere it will just deadlock after writing 100+ events without
reading as the channel will just be full.
It was added in commit 8da5f3f733 but never used there nor is there any
justification why this was added in the commit message or PR comments.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Using the internal Wait() API over the events API as this is much more
efficient. Reading events will need to read a lot of data otherwise.
For the function here it should work fine and it is even better as it
does not depend on the event logger at all.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
We never want the toolchain as the default is to use the same as the go
version. So the only purpose of toolchain is to force a newer compiler
than necessary which we do not want as we are getting build by many
different distributions and block builds that would otherwise work fine
is just not helpful to anyone.
Also update the go.mod comments remind people that there should be no
toolchain. The make vendor target with the toolchain will now guarantee
this so the CI will fail otherwise.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Clarifies the behavior of --interactive in both attached and unattached
scenarios.
Adds a caveat and explanation for --interactive being hungry as
described in https://github.com/containers/podman/issues/24370.
Signed-off-by: Alicia Boya García <aboya@igalia.com>
Debug for #23913, I though if we have no idea which process is nuking
the volume then we need to figure this out. As there is no reproducer
we can (ab)use the cleanup tracer. Simply trace all unlink syscalls to
see which process deletes our special named volume. Given the volume
name is used as path on the fs and is deleted on volume rm we should
know exactly which process deleted it the next time hopefully.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
In the user session there is no boot-complete.target so the Requires=
fails. We do not need it and I am not sure if we need it for the root
unit either but I deicded to keep it there to not change anything and
for the user session we patch it out.
I patched this in the Makefile, while we could try to define two
different source files for that it would make the Makefile logic even
more complicated. In particular as this file is a .in we would need to
add it to PODMAN_GENERATED_UNIT_FILES and then somehow fix the loop. To
much work IMO so the sed trick to patch the user file is simpler.
Fixes#23790
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
