Before this PR:
LeaderLearnerResource is registered as a Jersey resource.
After this PR:
LeaderLearnerResource is registered as both a Jersey resource and an Undertow resource by means of adding conjure-undertow annotations.
Priority:
P2
Concerns / possible downsides (what feedback would you like?):
See LeaderAcceptorResource for a very similar/analogous resource that was already migrated.
This resource uses {seq:.+}. The difference between that and {seq} (I lost the doc ref somewhere here) is that the latter won't match backslashes whereas the former matches all nonempty strings. It doesn't make sense to use it for a long here (not used in the sister class mentioned above).
I verified outputs were the same on IL some days ago. I will try sending the results async.
Testing on internal stack is pending.
PaxosValue has some protobuf serialization logic. As far as I can see, this is used for db/local storage. From reading docs in the guide linked above, it does not seem jax-rs uses this (or the Serializable implements) for serDe. I also asked in the internal dev infra forum for how conjure-undertow/jersey serDe is configured at the internal server layer - all of it is Jackson based. This coupled with the manual test I performed in IL wherein I sent and received PaxosValue elements in json indicate this is fine.
We are still registering both endpoints. I will take care of that after everything is migrated.
Is documentation needed?:
No
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?:
Potential breaks are the failure cases. Old succeeds (resp. fails) iff new succeds (resp. fails). The success cases are identical in behaviour. The failure (this is failure to match pathing and parse input) cases might not.
Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?:
No
The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.):
Yes
Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?:
No
Does this PR need a schema migration?
No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?:
N/A
What was existing testing like? What have you done to improve it?:
N/A
If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.:
N/A
If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?:
N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.):
B/G upgrades succeed, B/G rollbacks succeed, leader elections succeed, we see no 500s and performance is not meaningfully impacted. Timestamp and lock service work and consumers along with timelock are healthy.
Has the safety of all log arguments been decided correctly?:
Yes
Will this change significantly affect our spending on metrics or logs?:
No
How would I tell that this PR does not work in production? (monitors, etc.):
Any way in which the conjugate question's answer fails.
If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?:
Recall and rollback
If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.:
No
Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?:
No
Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?:
No
Development Process
Where should we start reviewing?:
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?:
Please tag any other people who should be aware of this PR:
@jeremyk-91
@sverma30
@raiju
General
Before this PR: LeaderLearnerResource is registered as a Jersey resource. After this PR: LeaderLearnerResource is registered as both a Jersey resource and an Undertow resource by means of adding conjure-undertow annotations.
Priority: P2 Concerns / possible downsides (what feedback would you like?):
Is documentation needed?: No
Compatibility
Does this PR create any API breaks (e.g. at the Java or HTTP layers) - if so, do we have compatibility?: Potential breaks are the failure cases. Old succeeds (resp. fails) iff new succeds (resp. fails). The success cases are identical in behaviour. The failure (this is failure to match pathing and parse input) cases might not. Does this PR change the persisted format of any data - if so, do we have forward and backward compatibility?: No The code in this PR may be part of a blue-green deploy. Can upgrades from previous versions safely coexist? (Consider restarts of blue or green nodes.): Yes Does this PR rely on statements being true about other products at a deployment - if so, do we have correct product dependencies on these products (or other ways of verifying that these statements are true)?: No Does this PR need a schema migration? No
Testing and Correctness
What, if any, assumptions are made about the current state of the world? If they change over time, how will we find out?: N/A What was existing testing like? What have you done to improve it?: N/A If this PR contains complex concurrent or asynchronous code, is it correct? The onus is on the PR writer to demonstrate this.: N/A If this PR involves acquiring locks or other shared resources, how do we ensure that these are always released?: N/A
Execution
How would I tell this PR works in production? (Metrics, logs, etc.): B/G upgrades succeed, B/G rollbacks succeed, leader elections succeed, we see no 500s and performance is not meaningfully impacted. Timestamp and lock service work and consumers along with timelock are healthy. Has the safety of all log arguments been decided correctly?: Yes Will this change significantly affect our spending on metrics or logs?: No How would I tell that this PR does not work in production? (monitors, etc.): Any way in which the conjugate question's answer fails. If this PR does not work as expected, how do I fix that state? Would rollback be straightforward?: Recall and rollback If the above plan is more complex than “recall and rollback”, please tag the support PoC here (if it is the end of the week, tag both the current and next PoC):
Scale
Would this PR be expected to pose a risk at scale? Think of the shopping product at our largest stack.: No Would this PR be expected to perform a large number of database calls, and/or expensive database calls (e.g., row range scans, concurrent CAS)?: No Would this PR ever, with time and scale, become the wrong thing to do - and if so, how would we know that we need to do something differently?: No
Development Process
Where should we start reviewing?:
If this PR is in excess of 500 lines excluding versions lock-files, why does it not make sense to split it?:
Please tag any other people who should be aware of this PR: @jeremyk-91 @sverma30 @raiju