#juju-gui

[fromanegg]

New Release: Juju GUI 1.1.0

Last week we released a new version of the Juju GUI which brings with it one major UI change plus a huge refactoring of the application state system.

We moved the inspectors default rendering position to the left over top of the charm browser to give you more room to work with your active environment.

A new uni-directional data flow system was implemented which dramatically simplified the GUI's data flow and execution.

Charm searching has been improved in the charm browser and will continue to be improved over time.

Work for the new machine view continues under the 'mv' flag. To check out this work load up the GUI with '<hostname>:flags:/mv'.

Plus many many fixes. See the repository for more information.

If you have any questions about Juju or the Juju GUI, you can read the official documentation for Juju and join us on freenode.net in #juju and #juju-gui

[fromanegg]

Unidirectional data flow architecture

Since Facebook released Flux there has been a lot of chatter about the unidirectional data flow architecture and how it helps large scale applications be easier to reason about and develop. With the Juju GUI nearing 70,000 lines of code in the core application we were running into an issue where it was becoming difficult to maintain the correct state throughout the many rendered UI components which are being consistently changed from the user interactions and changes coming in over the websocket from the users Juju environment.

In an effort to remedy this we determined that the only way to solve our current issues and prevent new ones going forward is to develop a unidirectional data flow architecture vs our MVC event style system which was currently in place. The execution flow we decided on was as follows:

When a user visits a url or a delta comes in over the websocket it is parsed and split into disparate sections of state for each component that's involved.

That state is then saved into the state system.

When the state system changes it diffs from it's previous state and passes the diff off to the dispatcher.

The dispatcher scans through the diff and passes off the various state components to their registered handlers.

Those handlers then pass the updated data into the UI components.

The UI components are then responsible for updating their DOM representation.

If the user makes a change to the UI, that UI component requests a change from the state system and the cycle repeats.

You'll notice that this is strikingly similar to the Flux architecture:

It's great to see cases of the multiple discovery hypothesis in action. It's a sign that you're on the right track for solving the bigger picture problems. It's also nice to see someone formalizing this architecture for client side applications in the hopes that others will be able to skip these scalability problems. While our implementation differs from Flux, the architecture is nearly identical. I highly recommend this architecture to anyone writing a large complex application of any kind, client or server side, as it dramatically reduces the complexity of the applications execution.

Do you work on a large application? Do you think this architecture could help simplify your app? Let me know in the comments below, @fromanegg, or +Jeff Pihach Thanks for reading!

[fromanegg]

New release: Juju GUI 0.15.0

Last week the latest version of the Juju GUI was released. With the holidays and our move from Bazaar and Launchpad to Git and Github there was unfortunately over a month from our last release. Have no fear however because this one brings with it some big changes.

We made a large number of bug fixes most of which were reported by you, like incorrect unit counts in bundle details and fixing the inspector height calculations so that it doesn't hide some of the lower buttons for environments with a lot of units.

90% speed improvement in the inspector for environments with thousands of units.

Inspector relations tab now shows the relation statuses and any units that are in error

The biggest change that we made in this release was entirely removing the full screen browser. This allowed us to remove over 4000 lines of code from our code base speeding up the application start up time and lowering the size of the application sent over the wire.

If you have any questions about Juju or the Juju GUI, you can read the official documentation for Juju and join us on freenode.net in #juju and #juju-gui .

[fromanegg]

New releases: Juju GUI 0.14.0 & Juju Quickstart 0.5.0

It's been a few weeks since our last Juju GUI release which means here comes another! This GUI release brings with it the latest beta version of the Juju quickstart plugin...

Juju GUI

Our latest work focuses on making the Juju GUI a more effective day-to-day tool:

The service inspectors now categorize errors and pending units by their types instead of grouped as 'error' and 'pending' so that it's easier to see your services status at a glance.

Services that are in the process of being destroyed no longer disappear immediately from the canvas so you can follow along and make sure that there aren’t any problems in the teardown.

Service level relation status is now shown on the inspector relation tab.

You can now drag and drop from a bundle file or the Charm browser.

Bundle deployments now give you better feedback during deployment so you have some insight into what’s going on.

The remaining notes can be found in the changelog

More exciting work in this direction is coming, including long-requested features like per-unit debug logs and local charm deployments!

Juju Quickstart

The quickstart plugin is nearing feature completion and has a lot of great improvements.

For new users, if you don’t have Juju installed, after it adds the stable PPA to your system and installs Juju, it will create an environments.yaml file that you need to edit.

For everyone, when you run quickstart, it will automatically log into the GUI for you as long as you accept the security certificate in your browser within two minutes of it appearing.

We also fixed a bug triggered when your default series was not precise.

The next release will guide new users through creating environments.yaml interactively.

To try out our new releases, existing users can upgrade their GUI charm to cs:precise/juju-gui-81; or run:

juju deploy juju-gui && juju expose juju-gui

...or update the juju-quickstart plugin via apt and run:

juju quickstart

New users on Ubuntu can do the following to get everything installed and start an environment with the GUI running and ready:

sudo add-apt-repository ppa:juju/stable sudo apt-get update && sudo apt-get install juju-quickstart juju-quickstart ## ...edit ~/.juju/environments.yaml file... juju-quickstart

Next quickstart release will hopefully remove those last two steps.

New users on other operating systems can’t use Quickstart right now, but the Juju installation instructions can get you started, and..

juju deploy juju-gui && juju expose juju-gui

..can add the GUI to your bootstrapped environment.

Juju GUI Installation documentation can be found here.

[fromanegg]

A Juju Charm designed to fail

While writing code for the next features in the Juju GUI I needed to test instances when charms would fail in various stages of their setup or execution. After a lot of messing around it became apparent that most charms are just too stable for this kind of testing so, I wrote a Juju Charm which is designed to fail in a large number of hooks depending on the configuration set on deploy (or later), and can relate to itself to test relation failures.

The charm, innovatively named 'failtester', can be found on launchpad or on jujuCharms.com. In depth details on proper use can be found in its README but it's really simple to use:

Note: This charm should only be used for Juju or Juju GUI development. It has no other functionality than to fail predictably.

// bootstrap your juju environment juju bootstrap // deploy the failtester charm juju deploy cs:~hatch/precise/failtester // set the failure type you want to occur // the failtester charm will now fail in its install hook juju set failtester install=true

Known Issue

The charm settings are at the service level which means that any failures happen to every unit of the failtester service. The fix for this should be fairly simple to do but I don't have any use for it at this time. If you need it feel free to ask or issue a pull request.

[fromanegg]

Juju GUI 0.13.0 release and updates

Over the past month and a half we have done 3 releases of the Juju GUI and with each release came a lot of great functionality. If you are not on 0.13.0 you should definitely upgrade your GUI charm to take advantage of these great new features.

Bundles!

This is probably the biggest release of the Juju GUI since it was officially unveiled. The GUI now supports importing, exporting, browsing and deploying bundles. A Bundle is a collection of charms, settings and their relations allowing you to deploy entire environments with one click. There is an excellent overview of this feature on the Juju GUI Blog.

Jorge Castro also wrote a great blog post on bundles and juju quickstart where he deploys a bundle with 17 charms, their settings and relations all with a single command.

Juju Quickstart plugin (Alpha)

The alpha release of the Juju Quickstart plugin was also released in the past month. The Juju Quickstart plugin is an opinionated plugin for Juju which makes for quick and easy deployment of the Juju bootstrap node and the Juju GUI. Follow the link for detailed information on it's functionality.

As always, if you would like more information about Juju or full details about each release they can be found in our changelog.

[fromanegg]

Juju GUI 0.10.1 Released - Bug fixes and updates

About a week after releasing the new service inspector in the Juju GUI we are following it up with another quick release which consists primarily of bug fixes.

The largest of those fixes are:

Changing settings did not work in Juju Core. (Fixed)

The GUI was unable to deploy charms without config options. (Fixed)

Remove unit button did not work in Juju Core. (Fixed)

Plus a number of additional fixes. You can read the full changelog here.

Additional information on Juju can be found on https://juju.ubuntu.com or join us in #juju on irc.freenode.net.

[fromanegg]

Juju GUI 0.10.0 Released - Brand new service inspector!

After a few months of hard work we have released the Juju GUI v0.10.0 which has the awesome new service Inspector as the default!

Quickly following up on v0.9.0 which added IE10 support, this release switches the new deployment and service inspector to be the default, switches to the new Go sandbox by default, and adds internal support for the upcoming charm bundles!

Additional information on Juju can be found on the newly redesigned https://juju.ubuntu.com or join us in #juju on irc.freenode.net. Interested about more of the changes in this release? You can read the full changelog to see all of the other updates that come with this version and what we have been up to over the past few releases.