Commit changes is horribly broken

Revising this now, it looks like from the last screen shot attachment that 44 unplaced units were trying to be added ... hmmmm whats even more interesting, is, if I clear the deploy queue, it resets to 44 unplaced machines when I open it to commit changes again.

unplaced units*

Hi James, thanks for the bug report.

Are you able to give me any more information about how I might reproduce this issue? Depending on how you scale up, units are added to the unplaced unit list and can be removed form that list using the expandable menu on each unit in the list (Or you can refresh the browser and it'll clear out).

I am seeing similar behaviour. Every time I commit a change a whole bunch of new machines get created, about 9. They don't show up before the commit, only once you hit commit. They have no services assigned.

This happens just changing a configuration option on a charm, with no new charms, as well as if I try to scale a charm and add a new unit but manually place it onto an existing container. Once I force destroy them all and everything is steady, if I make a change again it happens again.. many times.

I destroyed and re-installed juju-gui and the same occurs. I have an openstack-base deployment on 3 machines using both root and extra lxc containers.

What debug information can I generate?

juju: 1.25.3 (xenial) and 1.25.4 (git branch head for 1.25)
provider: maas
juju host: xenial
all other vms including state server: trusty

juju-gui charm cs:trusty/juju-gui-47

from pip list on the juju-gui machine:
juju-deployer (0.6.2)
jujubundlelib (0.1.9)
jujuclient (0.50.1)
jujugui (2.0.2)

I also get the following issue, trying to scale a charm with '1' unit always creates 2 extra units. Maybe unrelated but I wonder if its somehow related, is some kind generating a duplicate view of units or something?

Hi Trent, it sounds like you might be running into this:

issue: https://github.com/juju/juju-gui/issues/1318
fix: https://github.com/juju/juju-gui/pull/1319

We will be cutting the next GUI release soon but no ETA yet. If I remember correctly the workaround was to scale using the machine view. Sorry about the inconvenience.

We have cut a hotfix release of the gui (2.0.3) which contains the aforementioned fix. Could you please give it a try and see if this resolves the issue you were running into.

juju deploy cs:~juju-gui-charmers/trusty/juju-gui-48

Thanks.

Awesome! Will do!

On Tue, Feb 16, 2016 at 12:24 PM, Jeff Pihach <email address hidden>
wrote:

> We have cut a hotfix release of the gui (2.0.3) which contains the
> aforementioned fix. Could you please give it a try and see if this
> resolves the issue you were running into.
>
> juju deploy cs:~juju-gui-charmers/trusty/juju-gui-48
>
> Thanks.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1543778
>
> Title:
> Commit changes is horribly broken
>
> Status in juju-gui:
> Fix Committed
>
> Bug description:
> Trying to commit changes to destroy a service in my environment ... it
> seems the gui has tried to add an increment of machines every time I
> try to remove a service .... my env got messy real quick ... see
> attached photos
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-gui/+bug/1543778/+subscriptions
>

Tested the above fix. I am unsure if this is solving the "root" issue of creating these broken db entries, but with an already broken environment it is still behaving badly

 (1) It still shows 20 unplaced units, that do not exist (these were not somehow cleaned up)
 (2) Hitting commit on a configuration change still creates machines for these units by default (though you can change it to leave unplaced)

Additional to the above, after the action occurs I end up in the UI with both the full set of created machines, and a bunch of 'newXX' machines. The new machines go away with a full page refresh.

Trent,

Can you run me through the steps you took to get into this broken state? Unplaced units are purely a UI construct and should not have survived a charm upgrade (They are only in memory in the browser). So I would assume after upgrading that you would have started over from scratch in your juju model.

Thanks

I did not start from scratch, I think from my quick reading of the bug the issue is that the same service exists twice duplicate in the Mongo DB, and causes weirdness because the service effectively exists with the same name/details but twice? So since my DB is already broken (from before this fix) the upgrade hasn't fixed that root brokenness. And each time it wants to create machines for the unplaced services, but then doesn't find any to place due to the duplication. However I am totally naive on juju internals so I may be totally wrong.

All I did to get into this state was deploy the openstack-base bundle from the GUI. I did this 3 times and had the same issue each time, with a fresh bootstrap.

I destroyed and re-created my environment and the issue with the new GUI and the issue has not re-occurred. So it seems fixed from a new environment standpoint but given this release was out in the wild, some kind of upgrade logic to fix the root brokenness may be prudent.

Before re-creating my environment I dumped the Mongo DB, I am happy to upload it if you think that will help.

OK I lied.. while the charms were still deploying there were no un-placed units.. but not that they have finished deploying if I make a configuration change I am getting unplaced units again. 8 currently. Nothing showing in view machines, as before.

I have also had the issue return where once I hit "Commit Changes" that dialog disappears after a couple of seconds. That was also happening on my other installs, but not until the unplaced units re-appeared just now.

With Trents help I was able to trace down the root cause of this issue. A new tracking issue has been created on GH. You can find it here: https://github.com/juju/juju-gui/issues/1428