search

eclipse-hono / hono

Eclipse Hono™ Project
https://eclipse.dev/hono
Eclipse Public License 2.0
452 stars 137 forks source link

Remove 'vertx', 'quarkus' from module/image names #3092

Closed calohmn closed 2 years ago

calohmn commented 2 years ago

With spring boot variants removed (#3090) the adapter maven module and image names can be shortened. I guess the "vertx" part can be removed as well. E.g. renaming hono-adapter-amqp-vertx-quarkus to hono-adapter-amqp.

sophokles73 commented 2 years ago

If we want to rename the images then I would suggest to indeed also drop the -vertx suffix and use a completely new set of Docker Hub repositories. Otherwise we would start pushing Quarkus based images into the (original) Spring Boot based image repositories, e.g. renaming the hono-adapter-mqtt-vertx-quarkus image to hono-adapter-mqtt-vertx, we would push this image to the Docker repository that we used for the Spring Boot based variant. I would rather not do that as it might be very difficult later on to tell, which image is based on what dev framework/source code.

sophokles73 commented 2 years ago

So, the adapter image names then are:

while we basically keep the service image names:

Or am I mistaken? @calohmn

calohmn commented 2 years ago

@sophokles73 Why wouldn't we remove the -quarkus part also from the service image names?

sophokles73 commented 2 years ago

well, for example the hono-service-auth image name has been used for the vert.xSpring Boot based image so far. I wanted to prevent confusion caused by using the same image name for two different types of images. Starting with 2.0.0 we would use the same name for the Quarkus based images which had been vert.xSpring Boot based before. On the other hand, that is probably only an issue for people trying to use the 2.0.0 chart with older Hono versions. WDYT?

calohmn commented 2 years ago

Yes, I think it's about whether and how we support using the newest (2.0) Hono Helm chart with Hono 1.x images.

I think keeping support for Hono 1.x images would require keeping some 1.x-only logic in the Hono Helm chart, namely support for SpringBoot images and usage of the Jaeger agent sidecar container (instead of the OpenTelemetry Collector sidecar container for Hono 2.0).

On the other hand, users wanting to keep using Hono 1.x images could just stick to the current 1.x Helm chart version, using the honoImagesTag parameter to switch to newer 1.x image versions when new Hono 1.x patch versions get released.

In any case, changing the service image names here as well wouldn't matter much concerning the chart changes, I guess.

If we keep Hono 1.x image support, explicit 1.x related parameters (or 1.x-version parsing of the honoImagesTag) are needed anyway (e.g. concerning the tracing agent). So we could require setting the 1.x image names explicitly then as well (or set them internally according to the 1.x version detection).

sophokles73 commented 2 years ago

I think keeping support for Hono 1.x images would require keeping some 1.x-only logic in the Hono Helm chart,

I would rather get rid of all of the deprecated stuff and have a clean 2.0.0 based chart. As you pointed out, users who want to stick to Hono 1.x can still use the 1.x based chart. FMPOV we should strip out everything that is no longer supported in Hono 2.0.0 from the chart as well.

sophokles73 commented 2 years ago

I have created an issue with Eclipse Webmasters to create the corresponding repositories on Docker Hub.

calohmn commented 2 years ago

I think the CLI module name and created jar could be renamed as well (from hono-cli-quarkus to hono-cli, as the old CLI). We can add a note about the different versions on the Hono downloads page.

sophokles73 commented 2 years ago

@calohmn anything else to be done here?

calohmn commented 2 years ago

Should we keep the hono-adapters-quarkus and hono-services-quarkus Maven base modules? I guess they could be integrated with the respective hono-adapters and hono-services modules. WDYT?

sophokles73 commented 2 years ago

IMHO we should keep them because they help us to apply the build-docker-image and build-native-image profiles to the service implementation modules only (and not to the base class modules).

sophokles73 commented 2 years ago

However, we could remove the -quarkus suffix from the module names ...

calohmn commented 2 years ago

Naming is a bit tricky then, though. We currently have

Renaming hono-adapters-quarkus to hono-adapters-parent then?