Hello everybody, Katharos Technology is proud to release Juju Lens v0.1.0! This is our first official release of Juju Lens and now it features a native Desktop application!
While you have been able to use Juju Lens on the web with juju-lens.katharostech.com, now you can also download a desktop application to get advanced features not possible with the web application:
One-click SSH access to your units: just click the terminal icon on any unit and get an instant shell into your Juju machine
Virtual taskbar for SSH sessions: All of your terminal sessions can be minimized into a taskbar allowing you to hide and resume them when you are ready
Full support for insecure controllers: because of imperfect browser support, connecting to insecure controllers with Juju Lens on the web was rather buggy. Now, in the desktop application, there is an “Insecure” checkbox that allows you to flawlessly connect to insecure controllers for use in your development environment.
And you get all of the great features of the Juju Lens web application such as:
Painless multi-controller visibility
No changes necessary to connect to your existing controllers
Pleasant animations and UI components
Beautiful dark and light themes
Download and Install
We have native installers for Linux, Mac, and Windows. All of them under 5 MB with fully offline installers!
Note: Download links have been updated to version 0.1.1. See comment below for the new features included.
This is Pretty sweet! I just gave the Windows client a test drive.
It did crash on me a couple times but there is so much promise here.
Adding a controller is super straight forward. Would be nice to know how to handle HA controllers.
The design elements are super clean.
One click SSH is so nice.
The best part for me is being able to edit the application config right from the GUI. This is fantastic! This is something the JaaS Dashboard could definitely take a few notes on.
Hmm, that’s interesting. We haven’t run into crashes on Windows yet, but there is a lot of brand new stuff that isn’t heavily tested yet. If you notice anything particular that causes a crash let us know.
Oh, that’s a good question. I don’t know exactly how Juju handles HA controllers yet, so we’ll have to look into it. My first evaluation is that it is probably as simple as putting multiple IP addresses in when adding the controller.
Oh, good. That was where most of the recent work went, but it was so worth it.
So glad you liked that! That feature was driven by a request by our primary user @danhaws, so it’s cool to see that it is satisfying actual needs of the community.
Thank you so much for the kind words and for trying it out. It means a lot.
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.
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.
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.
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:
Logging Access
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!
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.
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?
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.
That was where most of the recent work went, but it was so worth it.
