Skip to content

Conversation

@kiashok
Copy link
Contributor

@kiashok kiashok commented Apr 5, 2023

This PR addresses the review comments on the port PR #8247 .

  • Rename test name
  • Add a tag to the container image used in the tests instead of the latest tag
  • Add a 5 second delay between container start and stop to ensure that the
    container is running

@k8s-ci-robot
Copy link

Hi @kiashok. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@kiashok
Copy link
Contributor Author

kiashok commented Apr 5, 2023

@mikebrow Addressed the review comments you added to #8247 . Could you please take a look? Will pull in these changes to the release/1.6 PR once its merged to the main branch

t.Log("Start the container")
require.NoError(t, runtimeService.StartContainer(cn))
// Wait few seconds for the container to be completely initialized
time.Sleep(5 * time.Second)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, isn't CreateContainer synchronous? What does it return if we call StopContainer too early?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I think its more about how the underlying compute system deals with it? )
its scheduling dependent - Its possible to hit a window where the container is not running yet but the kill has been sent immediately

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I'd expect this too.. I'd think if start returns we should expect the workload to be running. I'd imagine anything thats not that case is a bug (if the command you asked to run is expected to stay alive and isn't "echo foo" or some short lived task obviously).

Copy link
Contributor Author

@kiashok kiashok Apr 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I am able to repro the window after start container where the container is not already running and we have killed it. Looks like StartContainer() is a synchronous call as well. Can add an assert after run to make sure the state of container is expected. Thoughts @mikebrow ?

Copy link
Member

@mikebrow mikebrow Apr 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waiting 5sec will probably work .. but isn't a guarantee that the code you ran in command is complete.. e.g. the command includes a sleep 5sec before proceeding with the meat of what you are testing in the container.. or gc or swapper thrash or device interrupt...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not looked around for the cplatpublic.azurecr.io/args-escaped-test-image-ns code that's being tested..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you know what to look for in result status or what not.. you could loop here waiting for it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked over the runtimeService.StartContainer() code again and I see that if it returns, the container has started successfully. If any windows exists where the container is not running, I think the 5 sec delay is more than sufficient in this case as the test image is only looking for how CMD and ENTRYPOINTs are overriden and if they start up as expected

- Rename test name
- Add a tag to the container image used in the tests instead of the latest tag
- Add a 5 second delay between container start and stop to ensure that the
  container is fully initialized

Signed-off-by: Kirtana Ashok <[email protected]>
@kiashok kiashok force-pushed the argsEscapedTestFix branch from 8bf1f9f to e0b817e Compare April 7, 2023 20:25
Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with the understanding that 5sec or such delay is sufficient to determine successful start.. if a loop on status or some other is needed to validate the success case .. will look that over :-)

@kiashok
Copy link
Contributor Author

kiashok commented Apr 11, 2023

LGTM with the understanding that 5sec or such delay is sufficient to determine successful start.. if a loop on status or some other is needed to validate the success case .. will look that over :-)

@dcantah could you please take a look when you have time? :) Thank you!

@kiashok
Copy link
Contributor Author

kiashok commented Apr 12, 2023

@dmcgowan could you please take a look if you have some time? Thanks! :)

@kzys kzys merged commit ffc70c4 into containerd:main Apr 14, 2023
@kiashok kiashok deleted the argsEscapedTestFix branch June 13, 2023 22:14
@kiashok kiashok restored the argsEscapedTestFix branch June 13, 2023 22:16
@kiashok kiashok deleted the argsEscapedTestFix branch June 13, 2023 22:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants