-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
KEP-3542: СRI image pulling with progress notification #3547
base: master
Are you sure you want to change the base?
Conversation
byako
commented
Sep 26, 2022
- One-line PR description: adding new KEP
- Issue link: СRI image pulling with progress notification #3542
- Other comments:
Welcome @byako! |
Hi @byako. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the KEP suggestion.
keps/sig-node/3542-cri-image-pulling-with-progress-notification/README.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
KEP-3542: Add design details and info about testing.
|
KEP-3542: Update design details chapter
Following new CRI streaming API call is proposed: | ||
|
||
// PullImageWithProgress pulls an image with authentication config. | ||
// It returns periodically amount of image pulled so far. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How frequently will it stream updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PullImageWithProgressRequest
type of argument will tell it how often and based on what to send updates.
The PullImageWithProgressRequest contains base information needed to do the image pull (image name, auth config | ||
and sandbox information), and it will also contain information how often the server should send progress reports. | ||
The CRI client can restrict the progress reporting to be time-based (e.g. once every n. seconds), | ||
or based on size (amount of bytes/KiB/MiB downloaded). The size-based should be the default one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Time based one is more useful for detecting whether there is progress or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we shouldn't restrict the runtime to chose the default, I'll remove that sentence.
// - positive number up to 4294967295 (uint32 max number, approx. 136 years) | ||
// Default: 10 | ||
// +optional | ||
NoProgressTimeout int32 `json:"NoProgressTimeout,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How will this interact with the current CRI timeout?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this was meant to be much shorter than CRI timeout and tell the runtime how soon to report failure if there was no progress in image downloading. Without it the CRI timeout would cancel the call much later.
|
||
In Alpha: | ||
|
||
- image pulling operation should fail faster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
large image pulls don't timeout on CRI timeout and are completed without being restarted/cancelled
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this was about image size. Wasn't the point of no-progress timeout to fail faster when there is no progress and the image is impossible to download? I'll make it clear in phrasing here.
keps/sig-node/3542-cri-image-pulling-with-progress-notification/README.md
Outdated
Show resolved
Hide resolved
keps/sig-node/3542-cri-image-pulling-with-progress-notification/README.md
Outdated
Show resolved
Hide resolved
/milestone clear |
I cannot request exception for this, SIG leadership does not approve this, I'll have to move this to next release. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/stage alpha |
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
/milestone clear |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
With images containing LLMs and other piles of static data alongside the running software itself having some progress indication (and lack thereof) would be great. |