Drop custom{Liveness,Readiness,Startup}Probe options in favor of just re-configuring the default probes #189

Closed
opened 2021-06-29 11:05:12 +00:00 by justusbunsi · 4 comments
justusbunsi commented 2021-06-29 11:05:12 +00:00 (Migrated from gitea.com)

It is not really necessary to provide different probe objects to override the default ones. One could just change the default configuration for the corresponding probe.

It is not really necessary to provide different probe objects to override the default ones. One could just change the default configuration for the corresponding probe.
safaG commented 2021-06-29 11:43:51 +00:00 (Migrated from gitea.com)

@justusbunsi is it possible to leave probes as it is now? I am using GCP and without using custom probes I am NOT able to route traffic to my load balancer. These Probes saved me tones of time. Removing them now would force me to go back to manual steps to configure my load balancer.

@justusbunsi is it possible to leave probes as it is now? I am using GCP and without using custom probes I am **NOT** able to route traffic to my load balancer. These Probes saved me tones of time. Removing them now would force me to go back to manual steps to configure my load balancer.
justusbunsi commented 2021-06-29 11:56:52 +00:00 (Migrated from gitea.com)

Hi @safaG. Thanks for your feedback. The idea is not to fully drop the customization of these probes. Right now there are two mostly identical options to configure them. The settings for livenessProbe, readinessProbe and startupProbe are not fully configurable. They are missing the actual action that will be done. That should be supported. Meaning: Take the whole content of these objects and use them as it is done with the current customLivenessProbe, customReadinessProbe and customStartupProbe. Something similar is already possible for e.g. securityContext.

Doing so should eliminate the need of two configuration options for the same thing each.

You know what I mean?

Hi @safaG. Thanks for your feedback. The idea is not to fully drop the customization of these probes. Right now there are two mostly identical options to configure them. The settings for `livenessProbe`, `readinessProbe` and `startupProbe` are not fully configurable. They are missing the actual action that will be done. That should be supported. Meaning: Take the whole content of these objects and use them as it is done with the current `customLivenessProbe`, `customReadinessProbe` and `customStartupProbe`. Something similar is already possible for e.g. `securityContext`. Doing so should eliminate the need of two configuration options for the same thing each. You know what I mean?
safaG commented 2021-06-29 12:49:20 +00:00 (Migrated from gitea.com)

@justusbunsi ahh ok I see what you mean. Basically convert custom probes to the default probes and remove the custom probes.

@justusbunsi ahh ok I see what you mean. Basically convert custom probes to the default probes and remove the custom probes.
justusbunsi commented 2021-06-29 13:02:08 +00:00 (Migrated from gitea.com)

Yep.

Yep.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: lunny/helm-chart#189
No description provided.