Juju Lens: A New Juju GUI You Don't Have to Deploy

[zicklag]

Katharos Technology is proud to announce the first working version of the Juju Lens GUI!

We previously released a prototype demo ( see the announcement ) that just displayed some simple example data as it was unable to connect to any real controllers, but now we’ve finished the extra work necessary to make Juju lens actually work and connect to real live controllers!

There are many features and fixes that will need to be made to mature the project, but it is currently usable and updates can be made quickly.

Getting Started

To get started, you don’t need to install anything! ( assuming you already have a Juju controller to connect to ) Just open the link to Juju Lens, add one or more controllers, and you’re all set. All data is stored locally in your browser, so if you access the Lens from a different browser you will have to re-add your controllers.

Adding a controller

To add a controller, first go to the Controllers tab:

Then click the big plus button:

Fill out the form and click Add:

Juju Lens will connect to your controller and display the number of machines, models, applications, and units in the controller list. Then click on the models tab:

Juju Lens will show you all your models and units!

Feedback

Lots of buttons don’t actually do anything yet, and there are tons of little things to do here and there, but if you have any feedback or ideas, just comment here.

If you have any trouble getting it connected to your controller let us know and we will try to figure out what went wrong. We’d love to here from you even if you just tried it out and everything went fine!

We’re very excited to experiment and see what we can do with Juju Lens!

[danhaws]

@zicklag and Katharos Technology, nice job with this. I’ve already connected my DEV and PROD controllers! Multi-controller view is amazing. Green status icons…Love it! Collapsible application sections with unit drill-down…refreshing! Still a lot of work to be done, but very good start. And I don’t even need to deploy it…what!?!

[bianka (Sohini Bianka Roy)]

Enjoying so many of these design elements, would love to hear what people think! Thanks @zicklag!!

[zicklag]

In response to a minor security concern we are moving the Juju Lens to a new domain: https://juju-lens.katharostech.com.

If you have already connected the Juju lens to your controller from the old domain ( katharostech.github.io/juju-lens ) it is advised that you clear your browser’s cookies and site data for the katharostech.github.io domain. ( Details below ) You will have to re-connect your controllers after switching to the new site. Sorry for the inconvenience.

---

Clear Cookies and Site Data in Firefox

1. First navigate to katharostech.github.io ( it will show a 404, that is fine )
2. Click the lock icon next to the URL

3. Click “Clear Cookies and Site Data”
4. Click “Remove”

5. You’re done!

Clear Cookies and Site Data in Chrome

1. First navigate to katharostech.github.io ( it will show a 404, that is fine )
2. Click the lock icon next to the URL

3. Click “Cookies”
4. Click “Remove”

5. Click “Done”
6. You’re done!

---

[dvnt (Sean Shüping)]

Damn, excited to give this a try

[zicklag]

Awesome, let us know if you have any thoughts or questions!

[zicklag]

I just put all of our next tasks on the Juju Lens Workboard for the GitHub Repo so you can see what we are working on.

Feel free to open issues on that repo for feature requests or ideas.

[sabdfl (Mark Shuttleworth)]

Congratulations on this release, @zicklag &co! Very exciting to see your approach to the admin experience.

I wonder what the security implications are of enabling the controller serve up a different GUI? If it’s reasonable, we would be happy to make the ‘juju gui’ command use whatever GUI the controller admins preferred. So, for example, you could bootstrap and then say ‘use Juju Lens on this controller’, and then when users say ‘juju gui’ they get your GUI instead of the built-in one.

Thoughts?

[zicklag]

Thanks @sabdfl! Sorry for the delay, but somehow I missed this comment.

@sabdfl

I wonder what the security implications are of enabling the controller serve up a different GUI? If it’s reasonable, we would be happy to make the ‘juju gui’ command use whatever GUI the controller admins preferred. So, for example, you could bootstrap and then say ‘use Juju Lens on this controller’, and then when users say ‘juju gui’ they get your GUI instead of the built-in one.

I think that’s a great idea!

Right now the Juju Lens deployment just consists of a static web app so the deployment of that would be super easy. To support SSHing into severs we will need to run a single dependency-less executable on the controller, or any other machine on its network, to act as an SSH gateway for the GUI. I’m not sure how we would want to automate that. Maybe it should just be a charm deployed to the controller model?

Having it deployed to the controller model makes logical sense to me because it should have the same network access as the controller and because it is sort of a different component of the controller from an administrative perspective. That means that selecting and deploying the GUI would actually just be, in the background, a call to juju deploy essentially.

@hatch, @gomboli, or anybody else who might know, how does the Juju GUI command deploy the Juju GUI today? I noticed that it is very easy to juju upgrade-dashboard ( or whatever the command was ) and it just downloads a tar which was nice, but how does it actually host it?

[simonrichardson]

@zicklag

@hatch, @gomboli, or anybody else who might know, how does the Juju GUI command deploy the Juju GUI today? I noticed that it is very easy to juju upgrade-dashboard ( or whatever the command was ) and it just downloads a tar which was nice, but how does it actually host it?

All binaries are delivered via simplestreams, the official packages are all signed including a signed json file and the signing process is internal to canonical.

You can see information about configuring simplestreams in discourse.

[zicklag]

So simplestreams hosts the dashboard artifact, but what hosts the static files from the artifact? Is it an apt package or something that runs nginx or another webserver?

[simonrichardson]

This is the dashboard artifact: Index of /juju/gui/gui/2.16.0

[hatch (Jeff Pihach)]

I think that the best and fastest way forward for now would be to create a charm that can be deployed into a model and configured to the controller. This is how we used to distribute the Juju GUI which actually provided a lot of benefits as it had a shared server that could be easily updated out of band of Juju.

Serving this directly from Juju would require quite a bit of work:

• As @simonrichardson has said any of these assets are distributed by simplestreams which requires a non-trivial internal process to release to.
• Juju et’al serves the dashboard internally so it would need to be updated to support serving multiple UI’s for all of the various commands that interact with it including bootstrap, setup, serving, upgrades, etc.
• If it would be served from Juju it would need the same security audits and reviews.

Now with that said, I could see a world where a user could manually specify an external tarball location and Juju could effectively act as a web server for those assets. This carries with it some UX complications but it’s something that could be explored.

[zicklag]

I’m pretty sure that deploying the GUI as a charm would be the cleanest solution for handling the GUI deployment, except for one thing: having to get HTTPS certificates yourself. There are charms for using Let’s Encrypt for certificates, and that is fine, but it still adds complication, when the Juju controller already has HTTPS certificates and is already got a domain.

Could we have the Juju server just proxy requests to an arbitrarily configured backend GUI maybe, that would be deployed to the controller model in order to make sure that it is in the same subnet?

So then you would just tell Juju the backend GUI IP or maybe even just tell it to “use this charm with an http interface in the controller model”.

[simonrichardson]

@zicklag

Could we have the Juju server just proxy requests to an arbitrarily configured backend GUI maybe

We currently need to ensure that from a Juju side of affairs that everything is a known and it is secure. We go to great lengths signing our agents and our GUIs in order to double down on this.

If you as a user of Juju want to install additional GUI charms, that puts the burden on you as the user of Juju to ensure the security of those charms.

[zicklag]

We’ve gotten some nice updates done on the Juju Lens recently. Here’s some of the highlights!

---

Clickable App Icons:

You can now click these icons to show the application:

Updated Unit List:

We’ve added the charm URL and the ability to select which columns are visible. We also added the missing columns for the Unit data.

Active Application is now highlighted:

You can now see tell which application in the list is selected. There is also a new colored dot to indicate the status.

Controller name displayed on models:

The name of the controller for each model is now displayed which helps a lot when dealing with multiple controllers.

[zicklag]

More updates to the Juju Lens!

Graceful handling of unreachable charm icons:

Sometimes there are charms with icons that you cannot get to due to store permissions, now Juju Lens will display an appropriate broken image icon when that happens instead of just leaving it blank.

View and Edit Application config:

It is now possible to view and edit application config values from Juju Lens! This is the first of our changes to allow actually modifying the Juju state through the GUI. Hopefully it will be the first of many updates in our attempt to give you absolutely no reason to need the Juju CLI when you have Juju Lens!

[zicklag]

New Machines View

We just pushed an update that finally allows you to view your machines and what units are on each machine!

Like units in the applications view, hovering over them units will display their status:

With that we cover a chunk of the most common visibility needs for a Juju cluster. Now we’ve got some exciting new features that we are going to work on next. Stay tuned!

[zicklag]

Just a heads up, if you are using Juju Lens, a recent update requires you to clear your cookies and site data for juju-lens.katharostech.com to before the app will work again.

The need to clear cookies on updates will be something that we will fix once we get a little bit more stable. Then it will be unnecessary and the app should handle updates automatically.