Skip to content

(fr-6) Use dedicated startup probe with higher failure threshold #604

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.

Sign up for GitHub

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

Open
Deydra71 wants to merge 1 commit into
base: 18.0-fr6
Choose a base branch
from
+16 −1
Open

(fr-6) Use dedicated startup probe with higher failure threshold #604

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion internal/horizon/deployment.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ func Deployment(

livenessProbe := formatProbes()
readinessProbe := formatProbes()
startupProbe := formatProbes()
startupProbe := formatStartupProbe()

envVars := getEnvVars(configHash, enabledServices)

Expand Down Expand Up @@ -210,6 +210,21 @@ func formatProbes() *corev1.Probe {
}
}

func formatStartupProbe() *corev1.Probe {

return &corev1.Probe{
TimeoutSeconds: 5,

@fmount fmount Jun 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@Deydra71 o/
We recently introduced a new module [1] to provide an interface for probes.
Using cinder here as just a simple example [2] that shows how to use the interface, you can basically create a Probeset struct with something like:

	apiProbes, err := probes.CreateProbeSet(
		int32(cinder.CinderPublicPort),
		&scheme,
		instance.Spec.Override.Probes,
		cinder.GetDefaultProbesAPI(timeout),
	)

or, for more advanced usage, like mariadb does [3], it is possible to also pass a command and the handler type.
In general I think we could improve this code in main and add the probe interface as well, so we can take advantage of the override in case we need to tune this statefulset in production.
Let me know if that aligns with the goal of this patch, otherwise we can create a dedicated follow up that enhances the interface in main and then we backport to fr6 as well.

[1] github.com/openstack-k8s-operators/lib-common/modules/common/probes
[2] https://github.com/openstack-k8s-operators/cinder-operator/blob/main/internal/cinderapi/statefuleset.go#L56C2-L62C3
[3] https://github.com/openstack-k8s-operators/mariadb-operator/blob/main/internal/mariadb/statefulset.go#L138

@Deydra71 Deydra71 Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I see, I overlooked the lib-common module :/

Looking at the examples I think it's pretty straightforward to update it in main, and then create backport only from the new one (and close this one).

I can work on it this week. @fmount Is there any Jira ttracking the implementation of probes.OverrideSpec across controlplane? So far I could find only support in storage operators and mariadb

@stuggi stuggi Jun 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

but keep in mind that this will be a CRD change. we can not just backport it and expect it to show up without an openstack-operator change. we need to plan for when it has to be released. otherwise we have to do an short term update and a longer term transition to this

@fmount fmount Jun 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hi,

Is there any Jira ttracking the implementation of probes.OverrideSpec across controlplane? So far I could find only support in storage operators and mariadb

Because the interface has grown over the time, the idea is to add overrides only where we need, and I assume we can create stories under https://redhat.atlassian.net/browse/OSPRH-2490 to track the work.
I agree that we need to coordinate to make sure it will be available on a specific maintenance release and bump the openstack-operator (fr6) to get the CRD change as well.
For cinder we have an associated bug that will go out soon, not sure we want to take a similar approach, or we just close 2490 w/ FR6 and work on dedicated items (e.g. a new horizon bug that creates the bug-epic and the associated stream).

PeriodSeconds: 10,
FailureThreshold: 12,
ProbeHandler: corev1.ProbeHandler{
HTTPGet: &corev1.HTTPGetAction{
Path: horizonDashboardURL,
Port: intstr.FromString(horizonContainerPortName),
},
},
}
}

func (t *TLSRequiredOptions) formatTLSOptions(instance *horizonv1.Horizon) error {

var err error
Expand Down
Loading