feat: support checking preconditions before starting core app #9026
Conversation
|
|
rodesai
force-pushed
the
precondition-server
branch
from
f588ba0
to
a3ab951
Compare
| } | ||
| return options; | ||
| } | ||
|
|
||
| private static void setTlsOptions( |
There was a problem hiding this comment.
All this code was moved over into a common utils class (ApiServerUtils)
| @@ -354,51 +347,6 @@ public void shouldSendCreateStreamRequestBeforeSettingReady() { | |||
| inOrder.verify(serverState).setReady(); | |||
| } | |||
|
|
|||
| @Test | |||
There was a problem hiding this comment.
As we no longer check preconditions from the rest application, we no longer need these tests.
rodesai
changed the title
There was a problem hiding this comment.
Overall makes sense to me. I think we could use some more comments for clarity on the new precondition checker executable and server.
Also, is it not possible to rework PreconditionFunctionalTest.java for this new model? We should probably have some integration test for this.
ksqldb-common/src/main/java/io/confluent/ksql/properties/PropertiesUtil.java
Show resolved
Hide resolved
| ); | ||
| } | ||
|
|
||
| private void checkPreconditions() { |
There was a problem hiding this comment.
Could you add a comment on how this function continuously runs and determines if PreconditionServer will continue running or not? And if it passes, we'll terminate the pre condition server and move onto the main KSQL server.
rodesai
force-pushed
the
precondition-server
branch
from
6309c35
to
07d2669
Compare
This patch changes up the precondition checker a bit so that it runs before the main KsqlRestApplication. This way, preconditions can look out for critical config properties to arrive, before they are handled by the actuall application. Detailed changes: - Run the precondition checker as a separate Executable implementation before running KsqlRestApplication. The precondition checker waits for any preconditions to pass, and while this is ongoing it runs a simple server that responds to all requests (other than the health probes) with a 503. - Change the precondition interface to accept a properties loader so that precondition checkers can wait on the arrival of dynamic properties. - Support multiple properties files as args (which are then overlaid)
rodesai
force-pushed
the
precondition-server
branch
from
07d2669
to
ecc9b0d
Compare
Description
This patch changes up the precondition checker a bit so that it
runs before the main KsqlRestApplication. This way, preconditions
can look out for critical config properties to arrive, before they
are handled by the actual application.
Detailed changes:
- Run the precondition checker as a separate Executable implementation
before running KsqlRestApplication. The precondition checker waits for
any preconditions to pass, and while this is ongoing it runs a simple
server that responds to all requests (other than the health probes)
with a 503.
- Change the precondition interface to accept a properties loader so
that precondition checkers can wait on the arrival of dynamic properties.
- Support multiple properties files as args (which are then overlaid)
Testing done
Added unit tests for the new precondition checker
Tested manually by updating a config file at runtime with a precondition plugin that looks
for such a change.
Reviewer checklist