Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Podman Test Day #17912

Closed
1 of 21 tasks
sumantro93 opened this issue Mar 24, 2023 · 3 comments
Closed
1 of 21 tasks

Podman Test Day #17912

sumantro93 opened this issue Mar 24, 2023 · 3 comments

Comments

@sumantro93
Copy link

sumantro93 commented Mar 24, 2023

Hey Folks!

We are in beta now and this is a good time to start planning for a Test Day/Week.
As discussed, we will have this post April 15th ( 2023-04-15)

Initial Tasks (to be done at least one week before test week)

To be done after the Fedora QA folks have taken action on the QA ticket:

Announcing Test Week

Should be completed after the Initial Tasks are done

  • Draft an email to [email protected] and few other relevant announcing the Test Week

    • Include a link to the Fedora Wiki
    • Include a link to the Test Day results app
    • Include a link to podman-issue-tracker for Test Week
    • Include a link to the video conference
    • Include a link to the HackMD doc
  • Cross-post announcement email to discussion.fedoraproject.org with #podman tag and whatever fits fine

  • Example format: https://hackmd.io/lCrVoW_RSMCRf2neiGhiPg

During Test Week

  • Monitor podman issue tracker for new issues reported as part of Test Week
  • Monitor #fedora-test-day #podman on IRC for new issues reported as part of Test Week
  • Ensure there is one or more representatives of Podman team present

After Test Week

  • Update podman ticket with any issues found
  • Update podman issue tracker ticket with any documentation updates made
  • Review Test Day results app and follow-up on any errors reported, if possible
  • Follow up with the Fedora Badges ticket with Fedora Account System (FAS) usernames that participated in Test Week
Luap99 added a commit to Luap99/libpod that referenced this issue Apr 20, 2023
Commit 1ab833f improved the situation but it is still not enough.
If you run short lived containers with --restart=always podman is
basically permanently restarting them. To only way to stop this is
podman stop. However podman stop does not do anything when the
container is already in a not running state. While this makes sense we
should still mark the container as explicitly stopped by the user.

Together with the change in shouldRestart() which now checks for
StoppedByUser this makes sure the cleanup process is not going to start
it back up again.

A simple reproducer is:
```
podman run --restart=always --name test -d alpine true
podman stop test
```
then check if the container is still running, the behavior is very
flaky, it took me like 20 podman stop tries before I finally hit the
correct window were it was stopped permanently.
With this patch it worked on the first try.

Fixes containers#18259

[NO NEW TESTS NEEDED] This is super flaky and hard to correctly test
in CI. MY ginkgo v2 work seems to trigger this in play kube tests so
that should catch at least some regressions. Also this may be something
that should be tested at podman test days by users (containers#17912).

Signed-off-by: Paul Holzinger <[email protected]>
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Apr 25, 2023

@sumantro93 what is happening with this issue? Is this something required for Podman?

Luap99 added a commit to Luap99/libpod that referenced this issue May 23, 2023
Commit 1ab833f improved the situation but it is still not enough.
If you run short lived containers with --restart=always podman is
basically permanently restarting them. To only way to stop this is
podman stop. However podman stop does not do anything when the
container is already in a not running state. While this makes sense we
should still mark the container as explicitly stopped by the user.

Together with the change in shouldRestart() which now checks for
StoppedByUser this makes sure the cleanup process is not going to start
it back up again.

A simple reproducer is:
```
podman run --restart=always --name test -d alpine true
podman stop test
```
then check if the container is still running, the behavior is very
flaky, it took me like 20 podman stop tries before I finally hit the
correct window were it was stopped permanently.
With this patch it worked on the first try.

Fixes containers#18259

[NO NEW TESTS NEEDED] This is super flaky and hard to correctly test
in CI. MY ginkgo v2 work seems to trigger this in play kube tests so
that should catch at least some regressions. Also this may be something
that should be tested at podman test days by users (containers#17912).

Signed-off-by: Paul Holzinger <[email protected]>
@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@containers containers locked and limited conversation to collaborators Jul 29, 2023
@rhatdan rhatdan converted this issue into discussion #19424 Jul 29, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants