Use docker label as primary source for WebUI #1117
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, I propose the use of the docker label
net.unraid.docker.webuiasthe primary source when parsing the container's web UI address. In the case that
the label is missing (i.e. for containers that were created before upgrading to
OS 6.10.X), we will fallback to the retrieving the details from the XML template.
There are 2 reasons for proposing this PR:
docker-compose. The current set up only explicitlyrefers to the XML template for the web UI address. This rules out all
Compose files that are spun up that do not reference a container that were
once spun up before using a template. Thus, no web UI option will be provided
for such containers.
retrieving the address format from the XML template in the private
function
getControlURL. This is called within the public functiongetAllInfo. However, before callinggetControlURL, we would already haveread through the container's labels and assigned
net.unraid.docker.webuitoa temporary variable. For all recently created containers with defined web UI
addresses, this variable will be non-empty and, if spun up using a template,
is the same as the template value obtained from the XML template. It would be
much faster to just use the label's value instead of calling another function
that furnishes the same value after an I/O operation.
On my server with about 60 running containers, I have measured a drop from 9.5s
to 9.0s, over an average of 10 tests, with and without applying the changes of
this PR. I only have 1 server and it is running an i7-8770. The difference would
not be as pronounced with faster CPUs but it should still be present. I believe
that this result shows some support in my claims in reason #2 above.