Congratulations guys, Lens is looking better and better!
Yes, it should just be a question of remembering multiple IP addresses, and trying to connect to a different on if your original one isn’t working. It may also be worth monitoring to see if new addresses show up, because Juju can expand itself automatically if a controller instance fails, and you would want to know about the new addresses.
I’ve not tried it yet with Juju Lens, but I usually setup HA controllers with DNS, i.e. when I bootstrap, I use the
--config autocert-dns-name=juju.mydomain.com option. Once Juju provisions the machine, I add that machine to DNS.
Then I follow up with the command
juju enable-ha. And once the two machines are provisioned, I add those IPs to DNS.
In this scenario, I simply add the DNS associated to my HA controller setup, i.e. “juju.mydomain.com”, to Juju Lens. @zicklag can comment more, but with this setup, it is left to DNS to manage availability to the IPs and Lens should operate without issue.
If however, for some reason you don’t have control over a DNS management facility, I can see that having the ability to add multiple IPs to the “Host” field might be helpful. Although I would probably opt to put local host entries on my machine before I would do that.
Currently Juju Lens does attempt reconnects on any connection failures so if you have your DNS pointed to all of your controller nodes then Juju Lens should work perfectly fine for HA controllers without any changes.
@dvnt If you have a use-case where you have an HA controller without DNS configured to point at the controller, then we could add the ability to specify multiple hosts easily enough.
Wow. Awesome work.
I have installed the deb version and looks great. Just playing around with it a bit, I already had a localhost controller (LXD provider) running so I connected to that. I tried the one click ssh to a unit I just deployed and the console window comes up but the progress circle just sits there. I can ssh into the unit from the Juju CLI so not sure what’s happening there.
One suggestion - I entered the controller IP address and port 17070 and user/password by looking at the YAML files I had locally in
~/.local/share/juju. Perhaps the GUI could read those files and automatically populate any controllers at start up, to save the user having to do it manually. Given the default port is 443, it seems this is aimed at JAAS controllers but a small tweak here and there would make it even more awesome for use with stand alone controllers also.
Hmm. That’s interesting. You could try doing
export RUST_LOG=juju_lens::ssh_plugin=trace and then running
juju-lens from the commandline to see what the output is there. Maybe it’s trying to connect to the wrong IP address. It will show you exactly what it’s trying to connect to in the logs. I’m not sure the the IP address detection is foolproof yet. I just picks the first public IP that Juju lists for the unit. There could also be any number of other edge cases that we haven’t covered yet. So far I have been able to get it working in a vagrant machine using Juju with LXD so I know that LXD can work, we just have to figure out what’s going wrong in your environment.
We’ll also try to make the logging more accessible and complete so that it is easier to debug when things go wrong.
That’s a great idea and it would be simple to implement. I created a GitHub issue:
Our use-case so far has been self-deployed controllers hosted with the auto-cert generation, but we definitely want to make it simple for any controllers that you use.
Funny, I started juju-lens again and this time it worked fine. And I added a new unit and that worked too.
I’m guessing there was an issue if you start from scratch and enter a controller IP address and try straight away to access a unit. So I deleted the controller from juju-lens, and restarted. I then added the controller again. The model showed the 2 units but ssh failed to work. So that’s the issue.
I set RUST_LOG. Where do I find the logs?
Oh, perfect, that gave me enough info to figure out what was wrong.
When you first connect to a controller, Juju Lens will add its SSH key to all of the models you have access to in the controller. It takes Juju just a bit to update the authorized keys on the host and if you try to SSH to a host before it finishes, the SSH connection attempt will hang. Juju lens also does not currently time out on SSH connections and it prevents other connections from being established while one is in progress, which leaves every connection to hang until Juju finishes updating the authorized keys and you restart Juju Lens.
I think the solution to this is twofold:
- The first time you connect to a controller, if you try to SSH into a node within, say, five minutes, we show a dialog that warns you that it may take a second for Juju to authorize Juju Lens to perform SSH operations.
- This dialog would have a “Do not show again checkbox”, too.
- We make sure that Juju Lens will not spend an unlimited time trying to establish SSH connections, and maybe attempt to reduce the locking on the SSH session creation as well.
That should not be too difficult to fix.
You should be able to see the logs in the console when running
juju-lens from the commandline.
The next update we make will be focused on getting easy access to the Juju Lens logs so that there is no hassle getting to them when encountering Juju lens bugs. I’m going to go through and make sure all relevant information is logged at appropriate log levels so that we have as much information as possible for figuring out what the problem is without having the user test a bunch of stuff for us.
We’re also going to add an in-app log window with controls for filtering the logs and for copying the logs so that you can send them to us for debugging purposes. We can even have a button for copying the logs and stripping sensitive information like IP addresses out of them automatically.
Just tried the latest update of Juju Lens…So nice.
A breathe of fresh air. Can’t wait for app logs and a deeper CLI integration.
Juju Lens 0.1.1 Release
A new release of Juju Lens! This time we focused on fixing a couple of user experience problems with the desktop application and on getting easy access to the Lens logs useful for reporting Juju Lens bugs.
Local Controller Import
At the request of @wallyworld we added a new feature that allows you to import your locally registered controllers right into Juju Lens with a click!
Better SSH Timeout Handling
Also related to @wallyworld 's testing ( thank you! ) we discovered that trying to SSH into a unit immediately after connecting a controller can lead to timeouts caused by the fact that Juju is still applying Juju Lens’s SSH key. This caused an apparent error where the SSH dialog would get stuck eternally loading. We fixed that by gracefully handling connection failures and presenting a dialog window that explains the potential problem when connections time out:
To help with debugging Juju Lens we’ve added support for viewing the Juju Lens logs inside of the app. This will help us understand what went wrong when users find bugs.
The log window can be shown from the new settings window:
Tell Us About Your Experience!
If you try out Juju Lens we would love to hear about it! If possible, it would also be great to see screenshots what your Juju deployments look like inside of Juju lens. We want Juju Lens to be a joy to use and we want to know how it’s serving our users. It makes us happy to see it getting to help people do cool stuff!
Awesome update, thank you.
Love the new feature to load existing controllers.
Sweet. Thanks for the feature suggestion.
So I spent the last day giving Juju Lens a good run through with an actual use case. I was needing to add some features to a few Lucky Charms and decided to test drive the workflow. What I found was; the combination of Lucky Charms and Juju Lens provided an experience that was pleasant and rapid.
I don’t know about anybody else’s charming experience, but I didn’t even want to attempt it until Lucky came available. It is all shell based and surprisingly intuitive to work with. Getting up and running is quick and easy and there are no dependencies other than the Lucky binary itself. If you want to push your charms to the store, then you need charm-tools in addition to Lucky.
Now even though Lucky made charming bearable in my opinion, there were still a lot of challenges when debugging and troubleshooting issues with the charms. That’s where Juju Lens came to the rescue. It was a breath of fresh air to be able to “one-click” SSH into the machines without having to leave the GUI. And then being able to move the windows as well as configure the charms was priceless. One of the major challenges I’ve had in the past is first having to break out into a shell to get logged into the machine, and then tailing the logs to see what happens as I change configuration. While it was possible, it still seemed very klunky. However, with Juju Lens, I was able to easily troubleshoot a charm relation bug by shelling into both machines with two clicks, tail the logs; move the windows to the bottom left and bottom right; and then configure my main charm and watch the logs after saving the changes. All within the Juju Lens UI! With that I was able to diagnose that my main charm was not actually firing the relation hook on the related charm. I quickly knew where to look in the Lucky Charming framework, and resolved the issue quickly.
An amazing experience. I’m on Windows, and there are still some quirks with the UX that need to be worked out…like scrolling sometimes gets wonky, and I can’t copy/paste from the shell window. But the time I saved through these awesome set of tools was unprecedented so far in my charm development.
Moving over here to avoid cluttering that thread.
Glad you like the idea!
About the connection failure, do you have valid HTTPS certificates for your controller or no? Also were you using the web interface or the desktop app.
If you don’t have valid HTTPS certificates that will be trusted by your workstation, you will need to use the desktop app and check the “Insecure” option when adding the controller.
running in insecure (staging test, so no security is yet a concern). It fixed my connectivity issue to seeing my models. Really great UI, fast experience! Well done! Is it too forward to call it beautiful?
Thank you! I’m so glad you like it!
Let us know if you notice any bugs or have feature requests!
Also, if you ever need to create any charms, check out Lucky. Especially if you want to develop container based charms, and are more comfortable in bash than python.
I’ve been unable to install the desktop version using the dmg file for MAC i’ve tried using the app.tgz file as well. I keep receiving the error that I can’t open the application because it is damaged or incomplete. I’ve tried re-downloading it and still the same error message. I’ve tried this on Catalina and Big Sur. I appreciate any insight on getting this resolved.
Hi @geoisinc, so sorry I didn’t reply to this earlier! I didn’t notice this in my Email.
Unfortunately I don’t have a mac to test on, so I’m not sure if this will help, but I’ve updated the project dependencies and re-built it. I did notice that that the App.tgz was including folders that it shouldn’t have so I tried to fix that.
Here are a couple more builds to try out:
Let me know how that goes.
sorry @zicklag for the late response, I hadn’t received any notifications that you had responded to my post. I tried the builds that you posted and I still receive the same error