[
https://issues.apache.org/jira/browse/QPID-8708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Vavricka updated QPID-8708:
---------------------------------
Description:
In the Docker image for 9.2.1, the entrypoint.sh script, the copying of files
has been changed to use the recursive (-r) switch. This, however. leads to
issues if the original files are links, as is the case if you mount a
Kubernetes ConfigMap, for example. The script will copy the link, but not the
target of the link. This was not the case when each file was copied directly.
To further complicate the matter, the AbstractJsonConfigStore class uses
Files.exists method in setup() (line 115). This call will return false on the
path it is testing for, since what is there is a link, not a file, resulting in
an exception. The stack trace is attached.
In our case, we map a ConfigMap containing our initial config of the broker to
the /qpid-broker-j/work-override directory, so that we start from a known base
system for new pods. The resulting file structure will look like something
similar to this:
{code:java}
/qpid-broker-j/work-override/..<timestamp>/config.json
/qpid-broker-j/work-override/..data -> ..<timestamp>
/qpid-broker-j/work-override/config.json -> ..data/config.json{code}
The links are there to support updating the ConfigMap in Kubernetes and
reflecting that back to the application, I suppose, although we don't use it at
the moment. I have tried a few things to try to get the files mounted directly,
but I have not found a way to make it work.
I suggest either reverting the recursive copying of the file, or to add the -L
switch to cp, so that the targets of the links are copied, and not the links
themselves.
*Implementation*
{{cp}} command was extended with -L flag.
was:
In the Docker image for 9.2.1, the entrypoint.sh script, the copying of files
has been changed to use the recursive (-r) switch. This, however. leads to
issues if the original files are links, as is the case if you mount a
Kubernetes ConfigMap, for example. The script will copy the link, but not the
target of the link. This was not the case when each file was copied directly.
To further complicate the matter, the AbstractJsonConfigStore class uses
Files.exists method in setup() (line 115). This call will return false on the
path it is testing for, since what is there is a link, not a file, resulting in
an exception. The stack trace is attached.
In our case, we map a ConfigMap containing our initial config of the broker to
the /qpid-broker-j/work-override directory, so that we start from a known base
system for new pods. The resulting file structure will look like something
similar to this:
{code:java}
/qpid-broker-j/work-override/..<timestamp>/config.json
/qpid-broker-j/work-override/..data -> ..<timestamp>
/qpid-broker-j/work-override/config.json -> ..data/config.json{code}
The links are there to support updating the ConfigMap in Kubernetes and
reflecting that back to the application, I suppose, although we don't use it at
the moment. I have tried a few things to try to get the files mounted directly,
but I have not found a way to make it work.
I suggest either reverting the recursive copying of the file, or to add the -L
switch to cp, so that the targets of the links are copied, and not the links
themselves.
> [Broker-J] Docker entrypoint script copies links instead of files
> -----------------------------------------------------------------
>
> Key: QPID-8708
> URL: https://issues.apache.org/jira/browse/QPID-8708
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-9.2.1
> Reporter: Kyrre
> Priority: Major
> Fix For: qpid-java-broker-10.0.0
>
> Attachments: qpid_store_setup.txt
>
>
> In the Docker image for 9.2.1, the entrypoint.sh script, the copying of files
> has been changed to use the recursive (-r) switch. This, however. leads to
> issues if the original files are links, as is the case if you mount a
> Kubernetes ConfigMap, for example. The script will copy the link, but not the
> target of the link. This was not the case when each file was copied directly.
> To further complicate the matter, the AbstractJsonConfigStore class uses
> Files.exists method in setup() (line 115). This call will return false on the
> path it is testing for, since what is there is a link, not a file, resulting
> in an exception. The stack trace is attached.
> In our case, we map a ConfigMap containing our initial config of the broker
> to the /qpid-broker-j/work-override directory, so that we start from a known
> base system for new pods. The resulting file structure will look like
> something similar to this:
>
>
> {code:java}
> /qpid-broker-j/work-override/..<timestamp>/config.json
> /qpid-broker-j/work-override/..data -> ..<timestamp>
> /qpid-broker-j/work-override/config.json -> ..data/config.json{code}
> The links are there to support updating the ConfigMap in Kubernetes and
> reflecting that back to the application, I suppose, although we don't use it
> at the moment. I have tried a few things to try to get the files mounted
> directly, but I have not found a way to make it work.
>
> I suggest either reverting the recursive copying of the file, or to add the
> -L switch to cp, so that the targets of the links are copied, and not the
> links themselves.
> *Implementation*
> {{cp}} command was extended with -L flag.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
