Comments (10)
Yeah I agree that quarkus.docker.podman.*
isn't intuitive.
Really everything works out of the box just by setting quarkus.docker.executable-name=podman
EXCEPT for building multi-arch images. For that, the sequence of commands is different between docker buildx & podman. Thats where the differentiation would need to be.
I like the idea of stripping out common stuff from container-image-docker
. Probably 95% of whats there now would be common.
It would basically come down to
if (buildingMultiArchImages) {
if executable-name == docker then do these steps
else if executable-name == podman then do these steps instead
}
Everything else would remain exactly the same.
from quarkus.
/cc @geoand (jib,openshift), @iocanel (openshift)
from quarkus.
I was thinking about this a bit. Right now if you use the container-image-docker
extension and set quarkus.docker.executable-name=podman
, then container image building/pushing/etc works with Podman right out of the box.
Do we really need a separate extension?
The only real difference I see is if we want to build multi-arch images. RIght now we have the quarkus.docker.buildx
sub-config item which uses the docker buildx Docker extension.
For podman, building multi-arch images is built in. The only difference is the sequence of commands you need to use. Rather than pretty much copy/pasting the entire container-image-docker
extension and just changing a few things, couldn't we instead invent a new sub-config item (maybe quarkus.docker.podman.*
?) and add the multi-arch stuff in there?
This way the amount of change will be much, much less, and we won't need to invent a new extension which is 90% copy/pasted code (plus a bunch of new BuildItem
s that are copy/pastes of the docker ones (DockerStatusProcessor
, IsDockerWorking
, DockerStatusBuildItem
, etc).
If we decide in the future we want to support podman-specific ways of building images using things like containerfiles, then sure maybe we need a new extension. But for now we just want to build/push images.
If we just add a new sub-config item and leave just a container-image-docker
extension, then we're only changing a little bit in a couple of methods within DockerProcessor
.
Thoughts?
from quarkus.
(maybe quarkus.docker.podman.*?)
This is rather unintuitive.
I would do one of the following:
-
keep the extension as it and do nothing but update the docs.
-
split up the existing docker extension into a base and a docker specific one, then build a podman one on top of the base one
from quarkus.
What about if I only have a single processor, but 2 sets of config items
- The current
quarkus.docker
config item - A new
quarkus.podman
config item
Then the processor brings in both, errors out if both are configured, then goes down the correct path. Maybe there are 2 processors with a base class that has shared logic, but ulitimately only quarkus.docker.*
or quarkus.podman.*
can be configured at any given time, unless we allow them to use something like quarkus.container-image.builder=docker|podman
for them to say which they want to use.
from quarkus.
i'll throw something together and do a draft PR and we can discuss/review and make any changes. Might be easier that way so there's something concrete rather than talking in the abstract.
from quarkus.
What about if I only have a single processor, but 2 sets of config items
I think that's suboptimal because a user that wants podman would just add that extension to the classpath and the tooling can help autocomplete the necessary properties.
from quarkus.
a user that wants podman would just add that extension to the classpath
Are you saying that it should be split into 2 completely separate extensions (container-image-docker
and container-image-podman
)? Or keep a single extension (container-image-docker
) and just do some refactoring and add some new config?
from quarkus.
I'm saying that I propose two different extensions (that can share code however), or just keep things as they are and simply document what users should do when using podman
from quarkus.
or just keep things as they are and simply document what users should do when using podman
If they want to build multi-arch images, they can not do this currently using the container-image-docker
extension. There would need to be changes to allow that feature. So 2 extensions it is.
from quarkus.
Related Issues (20)
- Integrate the TLS registry with Quarkus Messaging connector
- When Updating to 15.1, use the new Version method in dev services
- If running quarkusDev using org.apache.camel.quarkus:camel-quarkus-grpc gradle plugin ClassNotFoundException: VirtualThreadsConfig occurs HOT 4
- Quarkus with latest io.kubernetes:client-java throws java.lang.NoClassDefFoundError: com/google/protobuf/RuntimeVersion$RuntimeDomain HOT 6
- 3.8.4 OidcClientFilter not being called on deployed Quarkus Service HOT 4
- Picocli - Some expected errors lead to a stacktrace and they shouldn't HOT 1
- Allow Agroal to create a new connection for healthcheck purpose
- Quarkus LTS versioning HOT 4
- Change default OpenTelemetry protocol to `http/protobuf` HOT 1
- Customizing the JSON logging formatter HOT 1
- Log records show the hostname on which the native executable was generated HOT 1
- Allow adding labels to routes HOT 2
- Make sure Quarkus is referenced with recent examples in the htmx ecosystem
- Documentation: Clarify possible self-invocation as CDI extension HOT 5
- Restore access to HttpSecurityPolicy retriever for current RoutingContext HOT 12
- Redis error: Pool initialized with SSL but connection requested plain socket HOT 9
- App crashes when connection to OIDC server times out HOT 6
- Add documentation for Vertx and Qute integration HOT 1
- Can't use other dataformat of Jackson like xml for Jackson Rest Client HOT 2
- Missing OIDC enabled property for tenants HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from quarkus.