Skip to content

feat: Add stopsignal to container lifecycle field in podspec #25868

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

saolof
Copy link

@saolof saolof commented Apr 13, 2025

Addresses #25389

* Supported a StopSignal LifeCycle field in podman kube files, following KEP-4960 implemented in kubernetes 1.33.

Since the CLI and quadlets support the docker --stopsignal flag, it does look like the code does only needs a change to one place in the specgen to handle it in kube files as well. I may be wrong about this, let me know if I am

@openshift-ci openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note labels Apr 13, 2025
Copy link
Contributor

openshift-ci bot commented Apr 13, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: saolof
Once this PR has been reviewed and has the lgtm label, please assign mtrmac for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

// +enum
type Signal string

const (
Copy link
Member

Choose a reason for hiding this comment

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

can we use SignalMap we already have in pkg/signal?

Copy link
Author

@saolof saolof Apr 14, 2025

Choose a reason for hiding this comment

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

I just copied the type definitions from the upstream kubernetes API. As for using the SignalMap, I'm not sure if openapi spec generation will work if the constant values aren't defined in the same file as the +enum definition. If that isn't being used I could just leave this as type Signal string and nothing else for the sake of yaml parsing and then the ParseSignal function will validate it using the map either way.

@saolof saolof force-pushed the kube_stopsignal_field branch from 322df1c to 28da116 Compare April 23, 2025 07:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants