Skip to content

support charms that communicate with the workload or set workload version#19

Merged
dwilding merged 4 commits into
mainfrom
support-container-comms
Jun 12, 2026
Merged

support charms that communicate with the workload or set workload version#19
dwilding merged 4 commits into
mainfrom
support-container-comms

Conversation

@dwilding

@dwilding dwilding commented Jun 12, 2026

Copy link
Copy Markdown
Owner

Main change: Support charms that try to communicate with the workload at 0.0.0.0. In a real K8s deployment, this works because the charm container and workload container are in the same pod. But with jjx, the charm code is running outside the docker container (under bubblewrap). This poses a challenge.

One solution would be to ask Docker to use the host network. I rejected that solution because I don't want a workload to be able to bind to arbitrary ports on my system.

After a lengthy investigation, Copilot produced this solution: At hook time, determine the IP of the container. Then inject a Python shim that rewrites connections to 0.0.0.0 so that they point at the container instead. I'm good with this solution.

We also introduced an environment variable JJX_DOCKER_PUBLISH that can be set (at the pytest level) in case someone wants to publish the workload to a port on the host network.

@dwilding dwilding merged commit 096c5da into main Jun 12, 2026
5 checks passed
@dwilding dwilding deleted the support-container-comms branch June 12, 2026 03:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant