configs should read ws ip addr from current url

[Richard Harding]

In development, testing would be much easier if the url of the socket_url wasn't hard coded to localhost, for example, testing froma virtualmachine. If the config would assume that the ws is available on the same host as the current url, it could be much more flexible for dev uses.

Currently doing this requires manually hacking the socket_url and then making sure to revert that change before submitting branches.

WORKAROUND: set the correct hostname in /var/lib/juju/units/juju-gui-[unit-id]/charm/juju-gui/build-prod/juju-ui/assets/config.js

[Jeff Pihach (hatch)]

+1

I agree that we need a better approach for this as this has also bitten me.

In a past project we had a similar config that was generated on build time from a json object whos properties could be overridden by environment variables. Considering that we already have most of that infrastructure in place this fix shouldn't be too much work to implement.

[Gary Poster (gary)]

Rick, +1 on making this change if you would like, as a slack or dev support task. We would appreciate it.

I (somewhat strongly) suggest that the socket_url be calculated dynamically in the browser, and not as a build time value.

In order to support the charm, the logic in the JS needs to be backwards compatible. That is, it must support either a full url (as it does now, and as the charm provides it) or what I think you would want: only a port and path.

full url -> unchanged
:port/path -> ws://[HOSTNAME]:port/path

[Gary Poster (gary)]

hm. It would be nice if we could support wss with this too. Then the charm could be taught to take advantage of it.

How about this?

full url -> unchanged
wss://:port/path -> wss://[HOSTNAME]:port/path
ws://:port/path -> ws://[HOSTNAME]:port/path

Maybe also

ws:///path -> ws://[HOSTNAME]:[CURRENT PORT]/path
wss:///path -> wss://[HOSTNAME]:[CURRENT PORT]/path

shrug. That would be slightly convenient for the charm.

I don't want to bikeshed. If you have a better idea I'll want to approve it. :-)

[Richard Harding (rharding)]

Thanks Gary. My main concern, and reason I didn't just drop something as a drive by in the other branch, was that I'm not aware of the actual deploy situation. could the web front end talking to another hostname for the ws connection? I've not done any ws tinkering other than the typical 'hello world' examples and I don't want to change the code to assume same host and then break a real world deployment story.

[Gary Poster (gary)]

In all the stories I know about, we talk to the same host name. However, we still need to support the full URL spelling. I think what I sketched, or something similar, would do the trick for both the current deploy story and for what you want.