Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • jeffpihach 6:51 am on March 19, 2016 Permalink | Reply
    Tags: , ,   

    Juju GUI 2.1.1 released 


    As a quick follow up to the Juju GUI 2.1.0 release we’ve got a patch release for the Juju GUI making sure that we keep the Juju GUI interactions transparent when working with either Juju or the Juju 2 beta. Along with this release we’ve added a few additional bug and usability fixes:

    • If you have uncommitted changes we now warn you when switching models so you don’t lose your changes accidentally. We will be working towards persisting this data in the future.
    • Disable container and machine creation buttons until we’ve collected enough information to successfully create the machine.
    • Added language and content direction flags so that the input fields work better for users using rtl languages.

    To upgrade an existing deployment:

    juju upgrade-charm juju-gui

    To deploy this release into your model:

    juju deploy juju-gui

    If you find any issues or have any feedback for the Juju GUI we’d love to hear it. Please let us know in our github repository and we’ll be sure to get back to you.

  • jeffpihach 6:49 pm on March 10, 2016 Permalink | Reply  

    Juju GUI 2.1.0 released – Now with Juju 2.0 support 

    2.1.0 juju screen
    We are excited to announce a new major release of the Juju GUI with support for Juju 2.0 (currently in beta). Juju 2.0 brings with it a ton of improvements, but one we’d like to highlight is the ability to create new models without needing to bootstrap them one by one. Interested? We explain all of the new updates to the GUI in the video below.

    Details about the release:

    • Added Juju 2.0-beta support.
    • Updated all API calls to support Juju 1.x and 2.x-beta facades.
    • Added the ability to create and switch between models in Juju 2.0.
    • Created user profile view which shows your models, bundles and charms after logging into the charmstore.
    • Added support for syntax highlighting in the charm details pages in the charmbrowser when the charm author provides a GitHub Flavored Markdown README file.
    • Added the ability to drag uncommitted units between machines in the machine view.
    • Unit statuses are now also shown in the machine view.
    • Fixed – when subordinates are deployed extra empty machines are no longer created.
    • Fixed – websockets are now closed properly when switching models.
    • Fixed – On logging out all cookies are now deleted.

    To upgrade an existing deployment:

    juju upgrade-charm juju-gui

    To deploy this release in your model:

    juju deploy juju-gui

    If you find any issues or have any feedback for the Juju GUI we’d love to hear it. Please let us know in our github repository and we’ll be sure to get back to you.

  • bradcrittenden 1:49 pm on March 3, 2016 Permalink | Reply  

    Update to 

    Update details

    Yesterday the Juju UI Engineering team updated with some improvements we hope you find interesting and useful.  The highlights are:

    Improved getting started page

    The Juju installation instructions have been re-written to be more straightforward and the page is more welcoming.

    Community cards

    In order to allow charm and bundle authors an engaging way to promote their work, we’ve introduced cards, a slug of Javascript and HTML that can be embedded into a web site which will then serve a visual representation of the charm or bundle. The details are fetched from our servers so the data will always be up-to-date.  Change your bundle and the representation of it on your blog will be updated for future visitors.

    Madison has written a blog post demonstrating their use.

    Note that this first implementation is Javascript-based and therefore will not work in every environment, specifically platforms that block the use of embedded Javascript.

    Improved topic pages (e.g. big data)

    A cleaner design utilizing the cards for each bundle presented.

    Charm labeling on bundle visualisations.

    Previously the rendered image for a bundle only showed the service icons which could be confusing as there was no way to intuit the role each service played. Now we are labeling each service with the custom name so you can easily identify master/slave relationships, for example.


    If you have questions or comments on these changes, you can find us in #juju-gui on Freenode or respond here.

    If you find a bug please file it at

  • jeffpihach 7:30 pm on February 17, 2016 Permalink | Reply  

    Juju GUI 2.0.3 released 

    The latest release of the Juju GUI has just been packaged up and brings with it a number of small but important bug fixes:

    • Fixed an issue where deploying the same charm multiple times would generate invalid charm names.
    • Fixed an issue where it would require two clicks to click between services on the canvas.
    • Fixed the removal of the option to serve the GUI over an insecure connection. This functionality has been re-enabled for now however in the near future we will be disabling this functionality for good forcing the GUI and its websockets over a secure connection.
    • Fixed the service inspector duplicating units when scaling up.
    • Removed and optimised the source code reducing the final size that needs to be sent over the wire.
    • When clicking stacked charm icons the active one now gets moved to the top.

    To deploy this release in your model:

    juju deploy juju-gui

    If you find any issues or have any feedback for the Juju GUI we’d love to hear it. Please let us know in our github repository and we’ll be sure to get back to you.

  • bradcrittenden 10:29 am on February 12, 2016 Permalink | Reply  

    Using Safari with the Juju GUI 

    The Juju GUI uses secure web sockets to communicate with the Juju controller. To secure that channel we use a self-signed certificate. Most browsers allow the user to easily accept the certificate and all is well.

    With Safari it is possible but a little more involved. The certificate must be accepted and placed into the Keychain. The steps to follow are below:

    1. Access the Juju GUI site.
    2. The site will start to load but then Safari will display the following alert: Screen Shot 2016-02-12 at 10.53.49.png
    3. If you simply press Continue you’ll proceed to the GUI but the web socket will not work. Press Show Certificate instead.
    4. A certificate dialog box will be shown. Open the Trust section.Screen Shot 2016-02-12 at 10.55.36.png
    5. Change the first drop down to Always Trust which will be cascaded down to the other drop downs.Screen Shot 2016-02-12 at 10.55.45.png
    6. Pressing Continue will lead to a dialog box asking for your OS X password. After entering it, the certificate will be permanently added to the Certificates section shown by the Keychain Access utility.  It’ll have a name like your-jujugui-1455269898.local which you can later delete if you wish.

    Note that the self-signed certificates are created for each instance of the Juju GUI. Unfortunately this means you’ll need to repeat this process for each instance of the GUI you wish to use.

    If at step 2 you press Continue, Safari will not be able to connect to the secure web socket and it will not present you with the certificate dialog again. To recover you must do the following:

    1. Open Preferences in Safari and go to the Privacy tab.
    2. Click the Details button and search for the site address.
    3. Select the entry and click Remove.
    4. Quit and restart Safari.
    5. Revisit the Juju GUI site.


    Massimiliano Marcon’s post at his blog.

  • bradcrittenden 7:02 pm on December 23, 2015 Permalink | Reply
    Tags: ,   

    Juju GUI 2.0 Beta released 

    We are really happy to announce availability of the new and shiny beta version of Juju GUI 2.0 with completely redesigned and rewritten user interface and improved user experience. The new GUI introduces:

    • redesigned canvas, relation management and charm handling with the new inspector,
    • improved integration with the charm store, unifying the web experience at,
    • new machine view with drag’n’drop functionality – allocating units has never been easier,
    • creation and switching between models within a controller, and
    • new bundle deploys.

    Not much has stayed the same, so it’s best if you give the new GUI a try yourself.

    We’re aware of the small details that need polish before we close the beta, but we’d like to make the 2.0 release rock solid and therefore would appreciate as much feedback from you as possible. Should you discover a bug, use the GitHub issue tracker to file a report. Please provide as much information as possible, e.g. the cloud provider, the output of ‘juju version’, steps made, errors from the browser console, etc.

    Machine view Model Empty canvas Store

    The major changes for this release are:

    GUI with controllers and models

    If you would like to test the GUI against a Juju controller, the JES feature flag needs to be enabled before bootstrapping. This will enable you to create, list and manage models directly from the GUI.

    juju bootstrap

    Deploying the Juju GUI 2.0 beta

    Juju 1.25 or older

    The charm is available via the charmstore URL cs:~yellow/trusty/juju-gui and at on the web. Just do the usual:

    juju deploy cs:~yellow/juju-gui

    Juju master (1.26 alphas)

    Recent Juju builds support a new publishing mechanism and can properly parse URLs with the development channel. If you’re using recent Juju builds, bootstrap a controller on a cloud of your choice and use the development version of the promulgated Juju GUI charm located at cs:development/juju-gui or on the web. You can deploy the development version of the charm with:

    juju deploy cs:development/juju-gui

    You should see a response similar to:

    Added charm “cs:development/trusty/juju-gui-42” to the environment.
    Deploying charm “cs:development/trusty/juju-gui-42” with the charm series “trusty”.


    We hope you find the new GUI easier to use and find the layout to be more intuitive. Enjoy using it and let us know what you think!

  • Madison Scott-Clary (Makyo) 5:11 pm on August 13, 2015 Permalink | Reply  

    Bundles Bundles Bundles! 

    You’ve gone through the process of sorting through various service orchestration solutions, and settled on Juju, since it will work with your existing frameworks and solutions, such as chef, puppet, and ansible. You’ve gone ahead and charmed up a few of your microservices so that you can get them deployed to your Juju environment. You’ve searched through the charmstore to find the databases, load balancers, and additional charms that you need to really make your project shine.

    Whew! That’s gonna be a lot of docs to write for new hires, right?

    Not necessarily! Here’s where bundles come into play!

    Bundles allow you to pull all of your services, unit placements, and relations together into one YAML file. A bundle is basically an export of a Juju environment. In fact, if you use the Juju GUI, it literally is that: the GUI will export all of your services with all of their config values, all of the relations linking them together, and the way your units are placed on machines.

    Bundles – V3 vs V4

    First, a bit of an important note. Bundles have been around for a little while. Recent work, however, has meant that there are some changes in how bundles are structured. The older format, known as the V3 format (for the third version of the API), pulled multiple bundles together into a basket – this is no longer the case with the V4 API.

    For instance, you might have a few wordpress bundles pulled together into a basket like so:

      services: ...
      relations: ...
      series: trusty
      services: ...
      relations: ...
      series: trusty

    Since baskets are deprecated, trying to upload a basket to the charmstore now will result in that V3 series of bundles being migrated to individual V4 bundles.

    The second difference between the two bundles formats is that the V4 format allows a machine specification. This means that you can have a top-level machines entry in your bundle.yaml file. This will contain a list of machine objects, which can have constraints, series, and annotationsobjects, which allow you finer-grained control over your machines:

      - "0":
        constraints: {mem: 4096, cpu-cores: 2}
      - "1":
        annotations: {foo: bar}
        series: trusty
      - "2": {}

    Finally, the unit placement directives are different between the two formats. Previously, if you wanted to collocate two units, you would use a format unique to bundles, which used an equals sign to separate the name of the service from the unit number. With V4 bundles, however, you can simply use the unit syntax that you’re familiar with from working with juju.

      charm: ...
      num-units: 2
      charm: ...
      num-units: 2
        // collocate directly onto the machine that the first unit of service-1 is
        // on
        - service-1/0
        // collocate into an LXC container installed on the machine that the second
        // unit of service-1 is on
        - lxc:service-1/1

    It’s also worth noting that placement directives can specify machines in the machine specification. That way, you can deploy units of a service to a given machine, either directly to the machine itself or to an lxc or kvm container (if supported).

    This exposes one more difference between V3 and V4 bundles: in V3 bundles, the only machine you’re allowed to refer to is machine 0 (the bootstrap node), which allows you to place a service on the only machine guaranteed to be in your environment. You can do this in V4 bundles as well, but note that it is only possible if you do not have a machine spec in the bundle. This is because the system can’t be sure whether you mean the bootstrap node or the machine named “0” in the spec, so it defaults to placing it on the named machine (or erroring if there is no machine named “0”).

    For more information on the bundle format specifications and the difference between V3 and V4 bundles, please be sure to check out the bundle doc in the charmstore! This should be kept up to date, as the Juju charmstore matures.

    Creating bundles

    The easiest way to create a bundle is through the Juju GUI. This even works in sandbox mode, so you can use to create your ideal environment without having to spin up any machines. Simply deploy and configure your services, add relations, place your units, and commit your changes to the sandbox, then you can export the environment as a bundle YAML file.

    Bundle validation

    You can easily validate a bundle.yaml file by dragging it onto the Juju GUI canvas and ensuring that all of the services, units, relations, and machines are created just how you specified. As with services, bundles dragged onto the canvas are in an uncommitted state until you hit the commit button. This means you can test in both sandbox and live environment modes without spinning up machines.

    This works through a bit of magic called Juju bundlelib, which decomposes a bundle into a set of steps that will need to be undertaken to deploy all aspects of the bundle. Since this is a python utility that lives separate from the GUI, you can validate a bundle on the command line by running pip install jujubundlelib (in a virtualenv, if you wish), and then passing your bundle.yaml file as an argument to the command that it installs, getchangeset. If you have any errors in your bundle, the getchangeset command will enumerate the items that will need to be fixed; otherwise, it will output a JSON list of changes (the changeset) that your bundle produces.

    Deploying bundles

    There are a few ways to deploy bundles of charms. If you have the YAML file on your computer, you can drag that to the Juju GUI and the GUI will attempt to deploy the bundle for you by fetching the change set. This will leave all of the services, units, machines, and relations in an uncommitted state so that you can change anything you need to. Once you’re done, you can commit your changes to your environment.

    Another way to deploy your bundle is using Juju Quickstart. This will spin up an environment for you (if you haven’t already), deploy the specified bundle along with the GUI, and get everything up and running for you. By default, Quickstart uses the Juju Deployer, but if you pass the -u option, your changes will be uncommitted and shown to you in the GUI.

    You can also use the Juju Deployer on its own. It’s available on PyPI as well.

    Once you publish your bundle to Launchpad, you will be able to navigate to view it and deploy it from the charmstore as well.

    More information

    Make sure to check out the full documentation for bundles to see all that can be done with them!

  • Madison Scott-Clary (Makyo) 4:36 pm on July 6, 2015 Permalink | Reply  

    Juju GUI 1.4.1 – Now even less committal! 

    Just kidding.  We’re pretty committed to providing a really neat and useful visual front end to your juju environment.  This latest release mostly includes some fixes to the ways in which uncommitted bundles work.

    • Config values specified within bundles now behave as expected in the ghost inspector.
    • Still have some older, V3 bundles laying around?  Legacy support is now included for uncommitted bundles, so you can use the GUI as well as the deployer to send them to your environment.
    • While we’re on the note of the deployer, if you deploy a bundle through the deployer using juju-quickstart, you will once again receive notifications about the status of the deployment inside the GUI.
    • Plus: tons of code removed, just to help slim things down (bye-bye, pyjuju support); switching from LESS to SCSS for styling; and wrapping external modules in YUI wrappers so that we can combo-load them more easily.

    To upgrade an existing deployment:

    juju upgrade-charm juju-gui
    juju set juju-gui "juju-gui-source=1.4.1"

    To deploy fresh:

    juju deploy juju-gui

    If you would like to request other features, have any questions, or run into any bugs, you can find us…

    IRC: #juju and #juju-gui
    Twitter: @jujuui

  • Francesco 12:39 pm on June 18, 2015 Permalink | Reply
    Tags: ,   

    Juju Quickstart 2.2.0 

    We are happy to announce the 2.2.0 release of Juju Quickstart!

    Juju Quickstart helps both new and experienced users to quickly start Juju and the Juju GUI, whether they’ve never installed Juju or they have an existing Juju environment running.

    From the last update on this blog, we introduced several new features like support for the Google Compute Engine provider (which increases to 9 the number of supported providers) and updates to environments’ definitions, together with other minor improvements and bug fixes.
    Here are the release notes for version 2.2.0:

    • Add support for loading uncommitted bundles on the Juju GUI.
    • Allow configuring the Juju GUI so that it listens to a customized port.
    • On existing environments, automatically detect the port used by the GUI server.
    • Fix SSH agent handling when using uncommon shells.

    From the list above, there are two noteworthy changes we would like to highlight.

    Support for uncommitted bundles

    With the release of Juju GUI 1.4.0 it is now possible to import a bundle into the GUI canvas as a set of changes to be committed later. This way the bundle can be finely tuned and tweaked before actually committing the changes. For instance, you can modify scalability settings, machine placements, configuration options and constraints for each individual service, and even the resulting topology itself, so that the workload really fits your needs, and, only at that point, send the resulting changes to the Juju environment.

    This functionality is now available from the command line too, thanks to the new Juju Quickstart’s
    -u (or --uncommitted) flag.
    You can use it like the following:

    juju-quickstart -u openstack-base

    The command above will not automatically start the bundle deployment, but instead the provided bundle will be loaded in the GUI, waiting to be customized and then committed.

    For more about uncommitted bundles, have a look at this blog post.

    Customized Juju GUI ports

    The Juju GUI, by default, listens for HTTPS connections on port 443. It also redirects insecure requests (port 80) to port 443. Sometimes it can be useful to configure the GUI so that it listens to a different port. For instance, this is handy when you want to co-locate another web service on the same machine.
    Juju Quickstart now provides the ability to directly specify a customized port for the GUI, e.g.:

    juju-quickstart --gui-port 4242

    On subsequent Quickstart runs, the application will automatically detect that the GUI is listening to the customized port and react accordingly, by establishing WebSocket connections to that port, and by opening the browser to the right URL at the end of the execution.


    The program is available on Ubuntu releases 12.04 LTS (precise), 14.04 LTS (trusty), 14.10 (utopic), 15.04 (vivid) and on OS X (10.7 and later). To install and start Juju Quickstart on Ubuntu, run these commands:

    sudo add-apt-repository ppa:juju/stable
    sudo apt-get update && sudo apt-get install juju-quickstart
    juju-quickstart [-i]

    On OS X, use Homebrew:

    brew install juju-quickstart
    juju-quickstart [-i]

    For more details, see juju-quickstart --help.



  • jeffpihach 3:48 pm on June 17, 2015 Permalink | Reply  

    Juju GUI 1.4.0 “Un Committal” Release 

    For the past two months we’ve been working on adding one of the highest requested features to date, uncommitted bundles.

    When we added the Deployer Bar, which allowed you to create and modify your environment before sending the changes to your live Juju environment, bundle support was absent. With this release you are now able to deploy a bundle from the Charm Browser, dragging and dropping or importing a bundle file, and then being able to modify it before deploying to your environment.

    This allows you to modify everything from configuration values, machine placement and scalability, to what services get deployed. Below you’ll find a short video which guides you through using this functionality so that you can take full advantage of this great feature.

    To upgrade an existing deployment:

    juju upgrade-charm juju-gui
    juju set juju-gui “juju-gui-source=1.4.0″

    To deploy fresh:

    juju deploy juju-gui

    If you would like to request other features, have any questions, or run into any bugs, you can find us…

    IRC: #juju and #juju-gui
    Twitter: @jujuui

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc