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
leaderelection sanity e2e integration tests #1463
leaderelection sanity e2e integration tests #1463
Conversation
3df7f51
to
2a3438b
Compare
alright, this is ready now. |
this.lockType = lockType; | ||
|
||
// Lease resource requires special care with DateTime | ||
if (lockType == LockType.Lease) { |
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.
dang, the original kubernetes type requires a RFC3339 micro-sec timestamp here however joda-time wont support such precision anymore JodaOrg/joda-time#139. i think we should consider getting #1418 merged so that serialization for micro-sec timestamp can work.
@himanshug can you add a TODO comment here saying:
TODO: switch date-time library so that micro-sec timestamp can be serialized in RFC3339 format w/ correct precision
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.
done... yeah Lease
resource creation etc should just work out of the box :)
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.
that said, unrelated to this PR but, "serialization" code by default can either emit to ISO8601 or RFC3339 ... if k8s can accept RFC3339 for all the date-time fields in all the resources then we can switch the default serialization format in JSON.java
to be RFC3339 or else Lease
object serialization would need to be handled as a special case even after the switch somewhere.
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 a bunch! additionally plz squash the commits into one. otherwise LGTM
d50d858
to
606df7d
Compare
606df7d
to
9e08762
Compare
/lgtm Thanks for writing these tests! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brendandburns, himanshug The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
thanks @brendanburns , @yue9944882 |
@brendanburns can we do a new release that includes leader election code updates ? Please let me know if you would like me to help with any logistics. thanks. |
@brendanburns are these changes expected to be present in |
I think I have been tagging the wrong Brendan in my previous messages. @brendandburns please see above messages, thanks. |
@brendandburns releases pages appears to say that release 10.0.1 is built from commit hash 6267ff3 (Date: Tue Jan 5 18:26:37 2021 +0800) and released on Jan 6th , however inside maven repo I see that all files were uploaded on Dec 21st 2020 ( https://repo1.maven.org/maven2/io/kubernetes/client-java-extended/10.0.1/ ) , those files are most likely not built using commit 6267ff3 . |
follow up #1460
these tests also exercise all different Lock implementations.