Works in all other cases.

Error:
TypeError: window.juju_config is undefined
startTheApp()

Adding units to a service from inspector works, adding units in MV2 opens up a list of services, one can write the number of units there but "add units" button below the list of services in MV2 does nothing.

The GUI currently allows the user to create multiple relations between the same two services as long as they differ by at least one endpoint and that the services have not yet been committed to the environment. However once the services have been deployed you are no longer able to add multiple relations between two services where an interface on one service is already being used.

This is because the logic that was originally written back in 2012 did not allow multiple relations on the same endpoint.

This only works by chance with the ghost services because the relations do not have an interface defined and as such the comparison function simply returns when checking if they match ('http' !== undefined). A complete fix here would be to make sure that ghost relations are provided with the appropriate relation interface data and then update the logic in the comparison function to allow many to one style relations.

When creating relations between two services which allow multiple relations (wordpress, apache2) you are only able to create multiple relations if they are in the ghost state. Once they are deployed you're no longer able to create multiple relations.

The issue appears to be related to the logic in: https://github.com/juju/juju-gui/blob/develop/jujugui/static/gui/src/app/models/endpoints.js#L98 as it returns that there are no available endpoints for relation.

When you have a subordinate in the canvas and then switch to the new machine view and 'add services' you can add subordinate units. This isn't actually possible so should not be presented to the user.

If you load the new GUI into a non JES enabled model you will see that the model switcher is still shown and there is an error in the console that it's not supported. We should not show the switcher if it's not supported to prevent this error.

When you "add to canvas" a bundle it takes a considerable amount of time to actually show up on the canvas. This is because we will get a few wss errors about invalid frame headers before it eventually succeeds:

WebSocket connection to 'wss://demo.jujucharms.com/ws' failed: Invalid frame header

We should show a notification when this action is performed in the event of a delay but the above issue should be fixed as well.

If with DnD a mistake is made and a unit is placed wrongly, one has to destroy that unit, create a new one and place it again.

It would be best if it could go the other way around as well, once a unit is in machine and is not committed, it can be moved around freely.

Most of the GUI requires that series be provided in the id of the charm. Multi-series charms do not provide this information causing everything from search results, charm details, to deploys to fail. Api v4 is being updated to not return multi-series charms but in the in term the GUI will need to ignore these charms.

Reproduce:

• Visit <host>/?search=meteor-test
• Visit <host>/?store=~tvansteenburgh/meteor-test-0

Tasks:

• Update the regex to accept charm id's without series.
• Disable and show a message for multi-series charms in the charm details.

When you mark a machine to destroy, you can still place units and containers on it. Committing this then causes Juju to return an error and put the GUI in a broken state.

When processing "cs:~uros-jovanovic/wordpress-multi-0" there is a JS error as the computed id is nil which causes parts to be undefined, which throws an uncaught exception in app/models/charm.js:162

We should warn users that they will lose any uncommitted changes when switching to anoter model.

Travel to Australia (preferably Mooloolaba) and run the karma tests. You should get a failing revisions test due to a timezone mismatch with the expected date.

To reproduce this one deploy ceph into a real environment without modifying any of its configs - it will deploy and fail in config-changed.

Now try and delete the service. Because the unit is in error it will not destroy the service so it does nothing.

Whenever we switch to the models, we should:

• put the deployed items in the center
• if user moved the canvas, remember the translation and restore it (2.1 feature)

We currently require two clicks to do search. First to open the dialog, second to put focus on the search text box. Users should be able to just start typing what they want to search.

When placing a precise unit on a trusty machine it silently fails because juju-core returns an error ""unable to place a precise unit on the trusty machine 2/lxc/0"" which we do not surface.

1. We need to surface these errors emitted from the ECS (placeUnit fn)
2. Should we allow the user to place this and we --force?

It would be nice if there was a 'series' property(list - for multi series charms) in the inspector for services so that you know what you have deployed.

The new mockups call for a "resolve & retry" and "remove" button in the error unit list. Unfortunately if that unit is in error it cannot be removed (https://bugs.launchpad.net/juju-core/+bug/1528073) and because we can't mark the unit as 'resolved' without automatically 'retrying' the hook which is failing it's impossible to remove the unit without dropping to the CLI.

There is difference between search and store functionality. Store behaviour is the correct one.

Juju-gui does not connect to juju environment. After a deploy, this is all I get:

When a unit doesn't have any other unit to relate to, the unit from which we want to create a relation disappears as well.

Hitting the x in the header should close the whitebox instead of just the search field.
Move the X to the far right.

When using force to destroy a machine we have to then cascade that down to mark all units and containers on the machine recursively in the ecs and then add the ability to revert those changes.

The browser starts an endless redirect loop.
This affects both real models and sandbox mode.

Add unit, place it to machine/container. Leave uncommitted. Try to export.

I was using mv flag.

With a fresh deploy of the GUI into a fresh JES enabled env (JES may not be required) the screen appears to load a blank canvas. You have to pan/zoom to see the GUI icon.

Click on store and trying to scroll down to see all the results. The window starts to rerender instead (was using trackpad not mouse wheel).

The behaviour is same in FF and chrome.

should look like

The charm details pages need a list of other available series for that charm which link to the details for that series.

I think this will require a new API endpoint to provide us with the details or those other series.

Solution:
quick: warn user that switching might end up in inconsistent state (same as with uncommitted state)
proper: queue API calls, leave socket open and execute the calls in the background

Browser reload requires user to login again.

When clicking to 'Add Machine' in the context menu in the machine view it then shows the constraints values input. After submitting that form it should select that newly created machine.

Neither in the boxes nor in the tags or names inside them

This happens when windows narrow. Apparently, I use a somewhat narrow web browser window.

When new model is created, and switched to it, the name in the env switcher does not update.

Switching between models doesn't update the name properly as well.

Spec required.

From Uros: I had two browsers open on the same model. The first one had uncommitted state. The second one was empty. Once i committed the changes, the environment switcher in the second one failed to respond or switch between models until i reloaded the gui in the browser.

From Frankban: I wonder if that's related to the fact that we never close the mega-watcher, and so there is a race between switching connections and incoming data from the mega-watcher (as a result of a change in the state, like committing a bundle). By closing the mega-watcher I mean sending a request like {Type: 'AllWatcher', Request: 'Stop', Id: ...}. Anyway, this is just an idea, might be totally unrelated.

When creating a machine in a real environment, after the machine details has switched from "Machine details aren't available to showing the machine details they are first shown as Nan" After a few moments it then updates to the real values.

When a notification appears at the lower left in Safari, the text is not inside the box as shown in the attached screen shot.

When manually placing units on machines it would be nice if you knew what the series/os of the machine is.

This window should go away once I've maximized (assuming it is wide enough). It doesn't go away until I click on it.

We've lost functionality to export bundles in new GUI.

Deploy openstack-base in snadbox mode. Remove relations between mysql, glance and nova controller. Try to recreate those relations.

@makyo @kadams54 Please take a look at this one.

In a real JES enabled model I deployed Wordpress, when to commit, and then deploy. I noticed however that it still had changes. It didn't auto-select "Automatically Place" as the default. This could be confusing to new users so we should make sure that it's the default.