Skip to content
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

Merged

Conversation

patrox
Copy link
Contributor

@patrox patrox commented Jun 26, 2021

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.

@patrox patrox force-pushed the common_label_based_container_locator branch from f51c039 to dc16a05 Compare June 26, 2021 20:25
@patrox patrox changed the title Common label based container locator Implement label-based container discovery for Redis Dev Service Jun 26, 2021
@patrox
Copy link
Contributor Author

patrox commented Jun 26, 2021

@machi1990 @stuartwdouglas @cescoffier @Ladicek Can I please kindly ask you for a review?

Copy link
Member

@machi1990 machi1990 left a 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?

docs/src/main/asciidoc/redis.adoc 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) {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@patrox patrox Jun 28, 2021

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 the shared container is not used. (lines 155-172).

WDYT?

Copy link
Member

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.

Copy link
Contributor Author

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);
Copy link
Member

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).

@quarkus-bot
Copy link

quarkus-bot bot commented Jun 28, 2021

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building dc16a05

Status Name Step Test failures Logs Raw logs
Initial JDK 11 Build Build ⚠️ Check → Logs Raw logs

@patrox
Copy link
Contributor Author

patrox commented Jun 28, 2021

lgtm, thanks @patrox

Can you squash the commits?

Sure, they will be squashed.

@Ladicek
Copy link
Contributor

Ladicek commented Jun 28, 2021

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?

@machi1990
Copy link
Member

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:

  • Implementing the label based discovery on the Redis extension using the logic from existing extension
  • Avoiding duplicates of the label-based discovery logic by extracting common code in a module and applying it through out.

I am all +1 on having atomic commits, that can easily be cherry-picked and have the build pass.

@Ladicek
Copy link
Contributor

Ladicek commented Jun 28, 2021

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 :-) )

@patrox
Copy link
Contributor Author

patrox commented Jun 28, 2021

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.
But, before merging it, I prefer to squash them and leave just a small number of commits that are related to separate changes.

In this case, I would leave just two commits:

  • Implement label-based container lookup for Redis Dev Service
  • Introduce a common label-based container locator + refactoring

@patrox patrox force-pushed the common_label_based_container_locator branch from 6083f73 to 1bf2b3c Compare June 28, 2021 12:40
@patrox
Copy link
Contributor Author

patrox commented Jun 28, 2021

@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.

@machi1990 machi1990 requested review from cescoffier and Ladicek June 28, 2021 18:41
Copy link
Member

@cescoffier cescoffier left a 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.

@quarkus-bot
Copy link

quarkus-bot bot commented Jun 29, 2021

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building a8d4b35

Status Name Step Test failures Logs Raw logs
Initial JDK 11 Build Build ⚠️ Check → Logs Raw logs

@patrox
Copy link
Contributor Author

patrox commented Jun 29, 2021

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.

@patrox patrox force-pushed the common_label_based_container_locator branch 3 times, most recently from 35b32af to a95ae34 Compare June 30, 2021 12:21
:extension-status: preview
include::./attributes.adoc[]

Quarkus supports a feature called DevServices that allows you to create various datasources without any config.
Copy link
Member

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?

Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor Author

@patrox patrox Jul 1, 2021

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.

gsmet
gsmet previously requested changes Jul 1, 2021
Copy link
Member

@gsmet gsmet left a 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.

@patrox
Copy link
Contributor Author

patrox commented Jul 1, 2021

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 :)

patrox added 2 commits July 1, 2021 10:18
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
@patrox patrox force-pushed the common_label_based_container_locator branch from a95ae34 to bb67c2a Compare July 1, 2021 08:18
@patrox
Copy link
Contributor Author

patrox commented Jul 1, 2021

Once the dust has settled, please try to squash the commits a bit to have proper semantic ones if possible.

@gsmet The commits were squashed and the branch was rebased to the latest master, sorry main.

@machi1990 machi1990 requested a review from gsmet July 1, 2021 17:49
@patrox
Copy link
Contributor Author

patrox commented Jul 2, 2021

@gsmet @Ladicek I have squashed the commits so there are only two commits left.
Can you please have a look and approve if there are no more comments from your side ?

Copy link
Contributor

@Ladicek Ladicek left a 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 :-)

@patrox
Copy link
Contributor Author

patrox commented Jul 2, 2021

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.

@machi1990 machi1990 dismissed gsmet’s stale review July 3, 2021 15:12

commits have been squashed.

@machi1990 machi1990 merged commit fdc95c6 into quarkusio:main Jul 3, 2021
@quarkus-bot quarkus-bot bot added this to the 2.1 - main milestone Jul 3, 2021
@machi1990
Copy link
Member

Thanks @patrox for the great work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement shared Redis Server with DevServices
6 participants