-
Notifications
You must be signed in to change notification settings - Fork 1k
Fabric8 leader election (CAN ONLY GO IN THE NEXT MAJOR RELEASE) #1658
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
base: main
Are you sure you want to change the base?
Conversation
|
Signed-off-by: wind57 <[email protected]>
Signed-off-by: wind57 <[email protected]>
Signed-off-by: wind57 <[email protected]>
...-kubernetes-commons/src/main/java/org/springframework/cloud/kubernetes/commons/PodReady.java
Show resolved
Hide resolved
@@ -44,7 +44,7 @@ | |||
@Configuration(proxyBeanMethods = false) | |||
@EnableConfigurationProperties(LeaderProperties.class) | |||
@ConditionalOnBean(KubernetesClient.class) | |||
@ConditionalOnProperty(value = "spring.cloud.kubernetes.leader.enabled", matchIfMissing = true) | |||
@ConditionalOnLeaderElectionDisabled |
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.
tagging you in here also @ryanjbaxter because I need an opinion.
So before we made this change, you could disable leader election via :
spring.cloud.kubernetes.leader.enabled=false
So you would get this dependency and for whatever reason, if you wanted to disable leader election, you could. Now, we are taking away this option from users and they are essentially left with two options only:
- use the previous implementation (via
spring.cloud.kubernetes.leader.election.enabled=false
) - use the new implementation (via
spring.cloud.kubernetes.leader.election.enabled=true
)
There are two things out of this: 1) there is no way to opt-out of leader election now; though it is weird to have the dependency on your classpath and still disable it 2) this can easily be seen as a breaking change...
Let me know if you need more details or this is clear for you. We can't this one merged until we are both on par. Thank you
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.
If the leader election functionality is still present but the underlying implementation changes, I think we can just remove the old implementation. Of course that means that this would only go in a major then.
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 actually wanted to keep both implementations :
- the old stays intact and works the same as it used to
- you can opt-in into the new one
The reason for this is that this I would like to users to be able to "test" the new functionality and raise any issues/concerns they have, but at the same time have a safe fallback.
If you agree, I will change the flags a bit to support this.
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.
OK and it needs to be documented
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.
its already documented:
There is another way you can configure leader election, and it comes with native support in the fabric8 library (k8s native client support is not yet implemented). In the long run, this will be the default way to configure leader election, while the previous one will be dropped. You can treat this one much like the JDKs "preview" features.
To be able to use it, you need to set the property:
[source]
----
spring.cloud.kubernetes.leader.election.enabled=true
----
I've added tests and left the old implementation intact.
This is finally ready to go imo.
Signed-off-by: wind57 <[email protected]>
Signed-off-by: wind57 <[email protected]>
Signed-off-by: wind57 <[email protected]>
No description provided.