-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Implement label-based container discovery for Redis Dev Service #18181
Implement label-based container discovery for Redis Dev Service #18181
Conversation
f51c039
to
dc16a05
Compare
@machi1990 @stuartwdouglas @cescoffier @Ladicek Can I please kindly ask you for a review? |
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.
lgtm, thanks @patrox
Can you squash the commits?
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerAddress.java
Show resolved
Hide resolved
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerAddress.java
Outdated
Show resolved
Hide resolved
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerAddress.java
Outdated
Show resolved
Hide resolved
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerAddress.java
Outdated
Show resolved
Hide resolved
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerLocator.java
Outdated
Show resolved
Hide resolved
...client/deployment/src/main/java/io/quarkus/redis/client/deployment/DevServicesProcessor.java
Outdated
Show resolved
Hide resolved
...client/deployment/src/main/java/io/quarkus/redis/client/deployment/DevServicesProcessor.java
Outdated
Show resolved
Hide resolved
@@ -139,7 +151,16 @@ private StartResult startContainer(String connectionName, DevServicesConfig devS | |||
|
|||
DockerImageName dockerImageName = DockerImageName.parse(devServicesConfig.imageName.orElse(REDIS_6_ALPINE)) | |||
.asCompatibleSubstituteFor(REDIS_6_ALPINE); | |||
FixedPortRedisContainer redisContainer = new FixedPortRedisContainer(dockerImageName, devServicesConfig.port); | |||
|
|||
if (devServicesConfig.shared && launchMode == DEVELOPMENT) { |
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.
Can this be extracted too?
Maybe not easily.
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'll take a look at this as well, as it would further reduce the duplicated code.
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.
@cescoffier I see two possibilities how this can be extracted:
- in a smaller (simpler) scope we could extract the conditional logic for label-based container location (lines 155-160)
- in a bit broader scope we could extract the above and also the other possibility, that is a creation of a new
Container
- which is done when theshared
container is not used. (lines 155-172).
WDYT?
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 would go with the first one.
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.
@cescoffier I pushed the latest changes, generally, the ContainerLocater
was made more "functional" by using Optional
instead of bare null
. This has shortened the code and additionally, it allowed to compose the method calls in a more fluent way.
super(dockerImageName); | ||
this.fixedExposedPort = fixedExposedPort; | ||
if (serviceName != null) { | ||
withLabel(DEV_SERVICE_LABEL, serviceName); |
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.
What about having a container decorator that adds the label.
At the moment we use a label-based mechanism, but this is likely going to change.
(can be done in another PR).
Sure, they will be squashed. |
Before I get to reviewing (which I'd really like to do per commit), what's the obsession with squashing commits? Clearly someone has made an effort to divide the work into smaller chunks that form a logical progression -- why would we want to lose that? |
It is not a obsession, but a suggestion. To me this boils down to two:
I am all +1 on having atomic commits, that can easily be cherry-picked and have the build pass. |
OK, I just went through the commits and the last one modifies multiple modules, whereas previously, each module was modified in a separate commit (which is very nice IMHO). In which case, squashing all the commits (except maybe the first one) would probably be best indeed. (Or percolate the changes from the last commit to each individual previous commit, though I can see how that's not the best use of one's time :-) ) |
About the squashing process - I usually like to create a PR with separate commits to make the review a bit easier. In this case, I would leave just two commits:
|
6083f73
to
1bf2b3c
Compare
@cescoffier @Ladicek @machi1990 I addressed all of your comments so far, can I please ask you kindly for a 2nd round? Please note that the commits will be squashed as discussed above - to 2 separate commits. |
extensions/devservices/common/src/main/java/io/quarkus/devservices/common/ContainerAddress.java
Outdated
Show resolved
Hide resolved
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.
A minor comment still missing (some tiny refactoring), the rest looks great.
@cescoffier I have this change already prepared locally, I'll push it a bit later. |
35b32af
to
a95ae34
Compare
:extension-status: preview | ||
include::./attributes.adoc[] | ||
|
||
Quarkus supports a feature called DevServices that allows you to create various datasources without any config. |
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.
Shouldn't this just go in the main redis doc as a subsection?
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.
Kafka and AMQP already use this structure. The getting started contains admonitions referring to this file. Dev service configuration is more reference content than getting started content.
return Arrays.stream(container.getPorts()) | ||
.filter(containerPort -> containerPort.getPrivatePort() != null) | ||
.filter(containerPort -> containerPort.getPublicPort() != null) | ||
.filter(containerPort -> containerPort.getPrivatePort() == port) |
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.
Minor: The 3 filters can be merged in a single one.
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.
@cescoffier Yes, I did consider it, but I didn't want to make a single line too long (I prefer "vertical" over "horizontal" code) - as right now it's easier to read.
Actually now, when I saw this code again with a fresh head - I think it could be extracted to a predicate, so we will a single filter - which won't be too long at the same time.
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.
Once the dust has settled, please try to squash the commits a bit to have proper semantic ones if possible.
@gsmet Yes, this is the next step - as I believe that the dust has already settled :) |
Refactor redis-client devservice to use a common container locator Refactor kafka-client devservice to use a common container locator Refactor amqp-client devservice to use a common container locator
a95ae34
to
bb67c2a
Compare
@gsmet The commits were squashed and the branch was rebased to the latest |
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 think this is OK, though there's certain school of thought (relatively prevalent on the Quarkus team) that prefers anonymous classes over lambdas because of memory footprint. Since the changes from anonymous classes to lambdas in this PR are in deployment
modules and hence don't affect production builds, I think that should be fine :-)
Thanks, @Ladicek for this insightful answer - I was actually wondering what's the rationale for such heavy usage of anonymous classes - and now I know. |
Thanks @patrox for the great work. |
The PR started as a copy-paste solution for label-based container discovery for Redis dev service -
in order to handle: #18029.
Based on these two PRs:
As many of you have noticed this required refactoring - so for that purpose I introduced two new classes:
Both of them are located in a new module called simply:
Quarkus - DevServices - Common
.The commits were not squashed (yet) for easier review.