when I move servers between tags, list in nodes view is out of sync

Larry,

What tag names where being used? Want to make sure this is not a duplicate of bug 1441864.

Blake, was moving servers in broken state between hw-ok (remove) and hw-issue (add) tags.

I think the issue might be with chromium. It's currently in that state that it's not taking any filter I try. No matter what filter I click on, it's just not updating the view. I switch to firefox and repeat the steps and it works.

Larry,

Check the chromium console to see if an error is being thrown. If an error
is raised it can cause the filter to stop working. I have tested this with
Chrome and it works as expected.
On May 16, 2015 10:45 PM, "Larry Michel" <email address hidden> wrote:

> I think the issue might be with chromium. It's currently in that state
> that it's not taking any filter I try. No matter what filter I click on,
> it's just not updating the view. I switch to firefox and repeat the
> steps and it works.
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1455560
>
> Title:
> when I move servers between tags, list in nodes view is out of sync
>
> Status in MAAS:
> Triaged
>
> Bug description:
> If I am looking at a node details and I update the tags then I can see
> the tags change automatically. But on the all nodes view, those
> results are not automatically available when I am filtering. I still
> see the old state when I am filtering until I initiate a force
> reload..
>
> So user A moves a server T from tag x to tag y, and if user B has view
> already opened and looks at x list then server T is still there.
>
> With tag updates having to be done from CLI, this could be rather
> confusing if user A and user B are not the same person. Seems to me
> like the action of applying a filter should give a current view rather
> than one from cache.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1455560/+subscriptions
>

Blake,
Yes, there are errors. This is from the javascript console:
====================================================================
 Consider using 'dppx' units, as in CSS 'dpi' means dots-per-CSS-inch, not dots-per-physical-inch, so does not correspond to the actual 'dpi' of a screen. In media query expression: (-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi)
10.245.0.10/:7 Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: node in tabs.nodes.filtered_items = (nodes | nodesFilter:tabs.nodes.search | orderBy:tabs.nodes.predicate:tabs.nodes.reverse) track by node.system_id, Duplicate key: node-9f0983ac-c4cd-11e3-8102-00163efc5068
http://errors.angularjs.org/1.2.11/ngRepeat/dupes?p0=node%20in%20tabs.nodes…20track%20by%20node.system_id&p1=node-9f0983ac-c4cd-11e3-8102-00163efc5068
    at 10.245.0.10/:6
    at 10.245.0.10/:9
    at Object.h [as fn] (10.245.0.10/:7)
    at u.$digest (10.245.0.10/:7)
    at u.$apply (10.245.0.10/:7)
    at RegionConnection.onResponse (10.245.0.10/:304)
    at RegionConnection.onMessage (10.245.0.10/:288)
    at WebSocket.websocket.onmessage (10.245.0.10/:199)
10.245.0.10/:7 Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: node in tabs.nodes.filtered_items = (nodes | nodesFilter:tabs.nodes.search | orderBy:tabs.nodes.predicate:tabs.nodes.reverse) track by node.system_id, Duplicate key: node-9f0983ac-c4cd-11e3-8102-00163efc5068
http://errors.angularjs.org/1.2.11/ngRepeat/dupes?p0=node%20in%20tabs.nodes…20track%20by%20node.system_id&p1=node-9f0983ac-c4cd-11e3-8102-00163efc5068
    at 10.245.0.10/:6
    at 10.245.0.10/:9
    at Object.h [as fn] (10.245.0.10/:7)
    at u.$digest (10.245.0.10/:7)
    at u.$apply (10.245.0.10/:7)
    at HTMLAnchorElement.<anonymous> (10.245.0.10/:8)
    at HTMLAnchorElement.jQuery.event.dispatch (10.245.0.10/:3333)
    at HTMLAnchorElement.elemData.handle.eventHandle (10.245.0.10/:2942)
10.245.0.10/:7 Error: [ngRepeat:dupes] Duplicates in a repeater are not allowed. Use 'track by' expression to specify unique keys. Repeater: node in tabs.nodes.filtered_items = (nodes | nodesFilter:tabs.nodes.search | orderBy:tabs.nodes.predicate:tabs.nodes.reverse) track by node.system_id, Duplicate key: node-9f0983ac-c4cd-11e3-8102-00163efc5068
http://errors.angularjs.org/1.2.11/ngRepeat/dupes?p0=node%20in%20tabs.nodes…20track%20by%20node.system_id&p1=node-9f0983ac-c4cd-11e3-8102-00163efc5068
    at http://10.245.0.10/MAAS/combo/angularjs/?angular.min.js&angular-route.min.js&angular-cookies.min.js:6:688
    at http://10.245.0.10/MAAS/combo/angularjs/?angular.min.js&angular-route.min.js&angular-cookies.min.js:9:381
    at Object.h [as fn] (http://10.245.0.10/MAAS/combo/angularjs/?angular.min.js&angular-route.min.js&angular-cookies.min.js:7:20047)
    at u.$digest (http://10.245.0.10/MAAS/combo/angularjs/?angular.min.js&angular-route.min.js&angular-cookies.min.js:7:20541)
    at u.$apply (http://10.245.0.10/MAAS/combo/angularjs/?angular.min.js&angular-route.min.js&angular-cookies.min.js:7:21941)
    at Manager.onNotify (http://10.245.0.10/MA...

Just in case this happens to be useful info: prior to running into this, I had to manually remove a tag filter for a tag (tags: bla) that's no longer showing on the left side since I recently removed that tag from all the servers while transferring them to a different queue.

However, this would be similar to having filtering on deploying but once all the nodes gets deployed, there's no x to click on on the left side since deploying is gone from states... and I don't recall seeing this in these instances.

This might be relevant: https://docs.angularjs.org/error/ngRepeat/dupes. Don't know if changing to "track by $index" will cause new / undesired UI effects tho. Larry, your comment about manually removing the tag is helpful in finding a minimum scenario to reproduce this. Could you provide some more details on the set of node / tag associations that you have and the steps you did to reproduce? Something like "nodes x,y,z with tags tagA, tagB", "node w nodes with tagA", "node v with tagB". "Filtered by tags:(!tagA,tagB)", then "removed tagB from nodes v,y,z" "manually removed tagB to filter on: tags:(tagA)", then get the error. It seems like this should be reproducible on both Firefox and Chrome. Exact tag names may be helpful in light of 1441864.

Larry,

What version of MAAS do you have installed? There was a bug that was fix
early Friday morning that resolved an issue just like this. Want to check
your version as this could just be a duplicate of that bug.
On May 18, 2015 7:15 AM, "ubuntudotcom1" <email address hidden> wrote:

> This might be relevant: https://docs.angularjs.org/error/ngRepeat/dupes.
> Don't know if changing to "track by $index" will cause new / undesired
> UI effects tho. Larry, your comment about manually removing the tag is
> helpful in finding a minimum scenario to reproduce this. Could you
> provide some more details on the set of node / tag associations that you
> have and the steps you did to reproduce? Something like "nodes x,y,z
> with tags tagA, tagB", "node w nodes with tagA", "node v with tagB".
> "Filtered by tags:(!tagA,tagB)", then "removed tagB from nodes v,y,z"
> "manually removed tagB to filter on: tags:(tagA)", then get the error.
> It seems like this should be reproducible on both Firefox and Chrome.
> Exact tag names may be helpful in light of 1441864.
>
> --
> You received this bug notification because you are subscribed to MAAS.
> https://bugs.launchpad.net/bugs/1455560
>
> Title:
> when I move servers between tags, list in nodes view is out of sync
>
> Status in MAAS:
> Triaged
>
> Bug description:
> If I am looking at a node details and I update the tags then I can see
> the tags change automatically. But on the all nodes view, those
> results are not automatically available when I am filtering. I still
> see the old state when I am filtering until I initiate a force
> reload..
>
> So user A moves a server T from tag x to tag y, and if user B has view
> already opened and looks at x list then server T is still there.
>
> With tag updates having to be done from CLI, this could be rather
> confusing if user A and user B are not the same person. Seems to me
> like the action of applying a filter should give a current view rather
> than one from cache.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/maas/+bug/1455560/+subscriptions
>

The scenario Friday was to move all servers from vm-staging into hw-staging. The filter was tags:(vm-staging) in one of the views. But I only had it open at the time. I accessed it a couple of days later and that's when I realized the tag was no longer showing on the left, so I deleted the filter with backspace. I then tried to update filter by clicking on hw-staging tag on the left: --> tags: (hw-staging)..

Maas version is:
ii maas 1.8.0~beta6+bzr3899-0ubuntu1~trusty1 all MAAS server all-in-one metapackage

This has been fixed in trunk and is caused by bug 1455151. Marking this bug as a duplicate.