[
https://issues.apache.org/jira/browse/QPID-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17777809#comment-17777809
]
ASF GitHub Bot commented on QPID-8352:
--------------------------------------
gemmellr commented on PR #225:
URL: https://github.com/apache/qpid-broker-j/pull/225#issuecomment-1772859490
Considering we have never had a single image all this time, this feels over
elaborate as a starting point.
Are there seriously going to be 192 image variants with the different
os/jvm/protocol/store options as described? That seems excessive. Which ones
would actually be getting pushed and why?
The 'protocol' images having amqp-all, amqp-0-8, amqp-0-10, amqp-1-0 means
it doesnt even allow picking e.g just AMQP 0-9 or 0-9-1 (and doesnt make it
obvious the 0-8 one would probably actually include them). The broker already
allows selecting specific protocols through its configuration, so I dont see a
good reason to complicate things by having 4 (or 6..so make that 288 variants?)
different image variations for that. If someone wants a seriously customised
image with different protocol deps in it then they can easily [/continue to]
roll their own. For everything else they can just configure it.
I also see no good reason to have a postgres specific image (or derby, or
memory store either). Are we going to add one for every DB someone likes and
explode the matrix of image options even further? We dont even test with
postgres at all so its unclear why would we ever have that as a default image
option to begin with.
Having a single basic out-the-image setup that gets people started, like the
regular broker distribution does itself, and then having ways for people to
easily supply custom config (including users if appropriate, as opposed to the
hard coded ones) to use instead to meet their specific needs, seem easier to
justify and maintain later, while actually being more general for people to get
whatever behaviour they want and without needing yet more image variants to be
created later.
Even the 4 OS and 3 JVM options seems a bit much.
As comparison, some other Apache projects with brokers that also only
started deploying images this year, currently have 1 or 2 images that they
actually push, and perhaps a few for local dev that they dont. That seems like
a more appropriate path to start with.
> Official Docker image for Broker-J
> ----------------------------------
>
> Key: QPID-8352
> URL: https://issues.apache.org/jira/browse/QPID-8352
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Chris O'Brien
> Priority: Minor
>
> Currently there is no official Docker image for Broker-J.
> It would be great if one was provided, as there are more than a few people
> interested in running Broker-J in a container, shown by the handful of
> inflexible and un-maintained Dockerfiles/images for Broker-J floating around
> GitHub/Docker Hub.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
