gtully
commented
3 months ago is your custom init container image rebased on the 1.0.27 init container. It looks like possibly there is an older xsd in play.
Closed pshields2 closed 3 weeks ago
gtully
commented
3 months ago is your custom init container image rebased on the 1.0.27 init container. It looks like possibly there is an older xsd in play.
pshields2
commented
3 months ago I thought it was but I'll double check.
gtully
commented
3 months ago This interdependence on the xml schema between init container and run container is one of the reasons for moving lots of the configuration to brokerProperties.
For the web container you are limited to system properties to augment the config, those can be in JAVA_ARGS_APPEND but it should be possible to configure your custom security manager via broker properties.
In short, I think you may be able to drop your init container to avoid this sort of problem into the future and avoid the need to manage a dependent container.
pshields2
commented
3 months ago That will be a future exercise. I also need to add jar file to the broker for my security manager implementation. So I will still need the custom broker-init. For now I am trying to get the xsd in sync with the newer run container. But I don't see where it is getting out of sync. I verified my docker file. See bellow.
FROM arti.hpc.amslabs.hpecorp.net/docker-remote/maven:3.9.1-amazoncorretto-11 AS BUILDER
COPY security-manager /security-manager
RUN cd /security-manager; mvn clean install --settings settings.xml
FROM quay.io/artemiscloud/activemq-artemis-broker-init:1.0.27
USER root
RUN set -x \
&& mkdir -p /amq/scripts \
&& mkdir -p /cray/etc \
&& mkdir -p /cray/lib
RUN set -x \
&& chmod a+w /cray/etc
USER 185
COPY scripts/post-config.sh /amq/scripts
COPY config/bootstrap-security-manager.xml /cray/etc
COPY --from=builder /security-manager/target/hpc-activemq-artemis-security-manager-0.0.1.jar /cray/lib/
COPY --from=builder /security-manager/target/lib/jose4j-0.9.3.jar /cray/lib/And I have loaded the images into my local repo for the custom build, so I am at a loss to where the old xsd creeps in?
gtully
commented
3 months ago There will be a need for an init container or volume mount to make your custom classes available, but that can isolated and version independent.
pshields2
commented
3 months ago I am upgrading a system where an older version has been running. Could the older xsd be picked up somehow?
gtully
commented
3 months ago It seems so. The schema(s) are in the /opt/amq/schema/ directory, the relevant bindings type in activemq.xsd
brusdev
commented
2 months ago @pshields2 did you fix your issue?
Describe the bug testing latest ActiveMQ Artemis v 2.34.0 in kubernetes. Using these docker images: quay.io/artemiscloud/activemq-artemis-operator 1.2.2 5e0cc862ad52 6 days ago 532MB quay.io/artemiscloud/activemq-artemis-broker-init 1.0.27 af2dc8181546 7 days ago 1.08GB quay.io/artemiscloud/activemq-artemis-broker-kubernetes 1.0.26 917b2cde2da0 7 days ago 893MB
I build a custom broker-init image to configure the broker. Which adds config parameters to the broker.xml and bootstrap.xml files. The init container runs my customizations with out any problems but when the container is started it reports an exception and the container is stopped/terminated. Here is the contents of the broker log from the failed container.
And the log from my running of my custom post-config.sh script in the broker-init container:
Note the contents of the bootstrap.xml in the output above. In particular these two lines are generating the exception.
This is code provided from the activemq-artemis-broker-init imag. My post-config.sh adds the contents to the bootstrap.xml file.
I see from the Artemis documentation, https://activemq.apache.org/components/artemis/documentation/latest/web-server.html, that web syntax looks ok.