Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • 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 https://github.com/juju/juju-gui/issues 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.

    Credits

    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 jujucharms.com,
    • 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.

    export JUJU_DEV_FEATURE_FLAGS=jes
    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 https://jujucharms.com/u/yellow/juju-gui 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 https://jujucharms.com/development/juju-gui 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:

    wordpress-single:
      services: ...
      relations: ...
      series: trusty
    
    wordpress-scalable:
      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:

    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.

    service-1:
      charm: ...
      num-units: 2
    service-2:
      charm: ...
      num-units: 2
      to:
        // 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 demo.jujucharms.com 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 onjujucharms.com 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: freenode.net #juju and #juju-gui
    Twitter: @jujuui
    Email: juju@lists.ubuntu.com
    Bugs: https://bugs.launchpad.net/juju-gui

     
  • 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.

    Installation

    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.

    Enjoy!

    quickstart-index

     
  • 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: freenode.net #juju and #juju-gui
    Twitter: @jujuui
    Email: juju@lists.ubuntu.com
    Bugs: https://bugs.launchpad.net/juju-gui

     
  • jeffpihach 6:01 pm on April 2, 2015 Permalink | Reply  

    Juju GUI 1.3.5 "Cutting Ties" Release 

    Introducing a faster, more responsive GUI thanks to the new Charmstore v4 API. We have finished porting all API calls in the GUI to the new version of the Charmstore API which provides a considerable boost in responsiveness.

    For those who have their own tools relying on the old Charmstore API we will be keeping it around for a while but it is a good idea to start working on porting over to v4. You can find the documentation for the new Charmstore API here: https://github.com/juju/charmstore/blob/v4/docs/API.md

    Screenshot from 2015-04-02 11:04:45

    Changes in this release:

    • Completed converting all API calls to the new Charmstore v4 API.
    • (FIX) Charms which were duplicates of promulgated charms weren’t shown.
    • Add React JSX compilation support to the Makefile.

    To upgrade an existing deployment:

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

    If you run into any bugs from this transition please file them here:https://bugs.launchpad.net/juju-gui

     
  • jeffpihach 9:00 pm on March 19, 2015 Permalink | Reply  

    Juju GUI 1.3.4 “Not so sticky” Release 

    Here comes another bug fix release for the Juju GUI which contains fixes for bugs reported by you since the last release.

    Screenshot from 2015-03-19 15:26:09

    In this release you’ll find the following updates:

    • (FIX) Service icons on the canvas no longer bounce back to their original
      positions when being repositioned.
    • (FIX) Bundle deploys no longer fail with invalid name error.
    • Removed the Features tab from the charm details pane.
    • Updated a number of api calls to the new v4 api.
    • Updated sysdeps makefile target for easier development.

    To upgrade an existing deployment:

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

    As we move forward on updating the api calls to the new v4 api if you run into any bugs please file them here: https://bugs.launchpad.net/juju-gui

     
  • mitechie 4:29 am on March 9, 2015 Permalink | Reply  

    Juju GUI release 1.3.3 out, get your bug fixes. 

    Our Juju GUI release 1.3.2 last week brought out some bugs that we ironed out. Make sure to upgrade to get all the yummy bug fixes. To upgrade make sure to:

    juju upgrade-charm juju-gui
    juju set juju-gui “juju-gui-source=1.3.3”

    Changelog:

    • (FIX) bug #1428751: prevent incorrect lowercasing of config options.
    • (FIX) bug #1427162: Show local charm icon in inspector.
    • Downconvert apiv4 bundle yaml to apiv3 format temporarily to fix issue with multiple bundles per yaml.
    • (FIX) Show charm details using the available data if it’s a local charm.

    The charm has also been upgraded. We’ve finally removed the old apache/haproxy legacy server built into the GUI charm. We also fixed up the git branch support which had a regression in there.

    As always, make sure to let us know if you hit any issues by filing a bug at https://bugs.launchpad.net/juju-gui and enjoy the release!

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel