Stuck on "Trying to connect to the Juju environment"

[Marius B. Kotsbak]

Now the Juju-gui site is spinning endlessly on "Trying to connect to the Juju environment".

I have tried rebooting the machine without any difference. "juju status" gives no errors.

[Gary Poster (gary)]

Hi Marius. My suspicion is that you are running on something that does not have its public address properly set in Juju, at least as far as the GUI can tell, and the websocket address in the GUI is pointing to somewhere unreachable. We actually plan to address this today in trunk (bug 1130228) and we'll make a new release with it next week.

If this is the problem, a more specific symptom is that, when you open the network panel in your browser's debugger, the GUI keeps trying to open the "ws" resource over and over again. You can verify further by going to /juju-ui/assets/config.js on the GUI's public address. "socket_url" will show a URL that cannot resolve from where you are.

If that's the problem, you can hack around the problem by manually changing that file, within [PATH TO GUI CODE]/build-prod/juju-ui/assets/config.js, to point to the actual working public address (wss://[public address to machine]/ws). If you are using the charm and can't find it, I'll spin an instance up and remind myself where it is. /var/lib/juju/units/juju-gui/juju-gui/build-prod/juju-ui/assets/config.js, I think?

[Marius B. Kotsbak (mariusko)]

Will check. At least I have set up elastic IPs on some of the machines, which is reflected in "juju status" in the machine list, but not on the service entries.

[Marius B. Kotsbak (mariusko)]

It tries to connect to the "ws" endlessly yes. The elastic IP was set up for another node. But I tried locally from the machine:

$ wget http://localhost:8080/ws
--2013-03-06 14:01:59-- http://localhost:8080/ws
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... No data received.
Retrying.

Shouldn't that work?

[Gary Poster (gary)]

On 03/06/2013 09:02 AM, Marius B. Kotsbak wrote:
> It tries to connect to the "ws" endlessly yes. The elastic IP was set up
> for another node. But I tried locally from the machine:
>
> $ wget http://localhost:8080/ws
...

wget is not designed to talk to a websocket connection, so it's not a
surprise that this doesn't work. Your output does show that something
is listening.

Could you try looking for the websocket url as I described? Go to
/juju-ui/assets/config.js on the GUI's public address. "socket_url" will
show a URL that cannot resolve from where you are. If that is true, the
temporary hack should work for you, and the fix we plan should be the
longer term solution.

Gary

[Marius B. Kotsbak (mariusko)]

I checked, and the URL seems right (only odd thing after using elastic IP is that it appear as public address on another charm). How could I test the service from localhost?

[Gary Poster (gary)]

The websocket URL should have the exact same host as the GUI's. If it doesn't, that's the problem. I still think that's what you are encountering.

If we can connect to the websocket it's usually fine by me. We haven't encountered problems like what you describe other than what I described initially. You might be able to use https://github.com/progrium/wssh or something similar, but within a 2 minute look I didn't get it working with secure websockets. I'll look at it again later.

[Gary Poster (gary)]

Trunk has the fix for what I believe you encountered. If you are using the charm, IIRC you can set the source to lp:juju-gui and it should get the updated code.

[Marius B. Kotsbak (mariusko)]

I reproduced the bug #1130228 by attaching an elastic IP, and the workaround worked. Then this bug must have been something else, but now I destroyed the machine so I'm not able to debug it any further.

[Marius B. Kotsbak (mariusko)]

I also once experienced that it took quite a long time before it finished loading.

[Marius B. Kotsbak (mariusko)]

I found this in /var/log/juju/api-agent.log:

 KeyError: 'result'
2013-03-12 16:30:31,763: juju.rapi.delta@ERROR: An error occurred 'result'
Traceback (most recent call last):
  File "/var/lib/juju/units/juju-gui-4/charm/juju/juju/rapi/delta.py", line 59, in pump
    current = (yield self.context.status())['result']

where line 59 is:

current = (yield self.context.status())['result']

[Gary Poster (gary)]

Hi Marius. I take it that you encountered this problem again? Under what circumstances–what versions of the charm and GUI? ~juju-gui's trunk of the charm + juju GUI trunk should do what you need but everything else will not at the moment. We are blocked by ~charmers in getting the charm published, but we will make another release of the GUI no later than next week.

The rapi error you gave probably is unrelated, unless you are encountering a behavior we've never seen (possible).

Gary

On Mar 14, 2013, at 6:10 AM, "Marius B. Kotsbak" <email address hidden> wrote:

> I found this in /var/log/juju/api-agent.log:
>
> KeyError: 'result'
> 2013-03-12 16:30:31,763: juju.rapi.delta@ERROR: An error occurred 'result'
> Traceback (most recent call last):
> File "/var/lib/juju/units/juju-gui-4/charm/juju/juju/rapi/delta.py", line 59, in pump
> current = (yield self.context.status())['result']
>
> where line 59 is:
>
> current = (yield self.context.status())['result']
>
> ** Also affects: juju (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Juju GUI
> Hackers, which is subscribed to juju-gui.
> https://bugs.launchpad.net/bugs/1149410
>
> Title:
> Stuck on "Trying to connect to the Juju environment"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-gui/+bug/1149410/+subscriptions

[Marius B. Kotsbak (mariusko)]

Yes, I encountered it again, using juju-gui-source: trunk. and "cs:precise/juju-gui". Maybe this was a slightly different problem, but still at loading the main page and failing to connect to the API. I also saw this in the log:

"Starting or restarting Juju API agent." and "Failed to perform start on service juju-api-agent"

I changed back to "stable" and deployed again, and then it worked fine. What other combo is recommended for a newer version?

[Gary Poster (gary)]

On 03/14/2013 08:17 AM, Marius B. Kotsbak wrote:
> Yes, I encountered it again, using juju-gui-source: trunk. and
> "cs:precise/juju-gui". Maybe this was a slightly different problem, but
> still at loading the main page and failing to connect to the API. I also
> saw this in the log:
>
> "Starting or restarting Juju API agent." and "Failed to perform start
> on service juju-api-agent"

This is new to me. I'll pass it along to a pyjuju dev in case anyone
else has seen it. A pastebin of a longer bit of log output might be
helpful.

> I changed back to "stable" and deployed again, and then it worked fine.
> What other combo is recommended for a newer version?

ATM, for what I believe to be the specific issue you are encountering:

charm: cs:~juju-gui/precise/juju-gui
juju-gui-source: lp:juju-gui

That's bleeding edge. Using the GUI release (the charm default
behavior) means it has been better tested. Moreover, on the charm
trunk, using a GUI release is also about eight minutes faster to deploy
on ec2 than a branch. Once we make a release with this fix (version
number > 0.2.2) we suggest you go back to using releases.

Gary

[Launchpad Janitor (janitor)]

[Expired for juju (Ubuntu) because there has been no activity for 60 days.]

[Gary Poster (gary)]

For anyone looking at this bug, the Juju GUI fix mentioned has been released for several months now.

[Richard Harding (rharding)]

Marking invalid as fixes have been released and things have been quite for a while. If the issue returns please open a new bug.

[David Medberry (med)]

Okay, opening a new bug with content from 2013-11-08

[brian mullan (bmullan)]

I have the same problem as reported in the original post of this bug ... except ... my use case is different.

I created an OpenStack "instance" of ubuntu 14.04.
I installed juju on that "instance" and configured it for Local Provider (re lxc).
I then bootstrapped and deployed Juju-GUI which successfully installed into its own LXC container.

If I install a desktop on that Openstack Ubuntu instance and log into it via a remote desktop capability I can start Firefox and point it to the 10.0.30.x address of the juju-gui container and login to juju-gui.

While logged into the OpenStack Ubuntu "instance" I can obviously ping to/from the juju-gui container and the Ubuntu Host.

But because my OpenStack Ubuntu instance is a 173.39.x.x address and the juju-gui container is a non-routable 10.x.x.x address I obviously cannot use Firefox from my Laptop and connect to the juju-gui.

However, I thought I could solve that by installing a Reverse Proxy on the OpenStack Ubuntu Host and point it to the 10.0.3.x address of Juju-gui container.

I used NGINX and it almost seems to work.

From my laptop I point Firefox to the 173.39.x.x address of the Ubuntu Host and the NGINX Proxy starts to redirect to the juju-gui. I see the Juju-Gui login screen start to appear but it just keeps spinning its circle and is stuck on "Trying to connect to the Juju environment" message.

So I am piggy backing on this Bug report since the resulting message is the same. I had thought that a Reverse Proxy like this would enable this access.

My use-case is to have people that from their desktop at work use their browser to connect to Juju-Gui then deploy "services" to LXC containers on the OpenStack ubuntu "instance". Its our own Openstack on our own hardware so I can install this on a very large compute & network resource machine.

note: yes I understand I could deploy juju-gui to a cloud server but then ... that server & the juju-gui would not be utilizing LXC afterwards for deployment of charm services.

[Richard Harding (rharding)]

Brian, can you do me a favor and check out the network inspector tool of the browser in your scenario? The client you load the GUI from needs to be able to login/pull down the JS from the GUI charm, however it also needs to talk on other ports as it holds a websocket connection to the juju state server. If the screen is spinning that it's unable to connect to the environment, I suspect the proxy is not proxying the secure websocket connection through to the juju state server.

A look at the network tab while loading the GUI should show the websocket connection attempting but failing.