if delta comes back before add unit rpc, it overwrites the user's request
Bug #1052676 reported by
Gary Poster
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-gui |
Triaged
|
High
|
Unassigned |
Bug Description
We need to make sure that the view code honors the user's request even across deltas.
summary: |
- if delta comes back before add unit rpc, it overwrites the db entry + if delta comes back before add unit rpc, it overwrites the user's + request |
description: | updated |
information type: | Proprietary → Public |
To post a comment you must log in.
Related:
I discussed with Roger about the possibility to add a SetServiceUnit call to juju-core. This functionality will solve our inconsistency issues between the unit count form and the real units in the database. This feature involves juju-core internals and requires design decisions.
Also note that in juju-core the first delta generated after units are added/removed already includes all the corresponding changes, and this, in some ways, reduces the gravity of this bug.
A possible solution for the time being (waiting for bug 1171899 to be fixed) could be the following one:
When the user changes the total number using the input:
- the unit count input is disabled;
- the unit count input is no longer updated on delta;
- on response, re-enable the input;
- after response, wait 6 seconds (mongodb heartbeat + network lag)
and then reconnect the input to the delta/database
(and update the count accordingly).
Make sure that the number of units to add or remove is calculated
with respect to the currently displayed value, not the value from the deltas.
Note that after the AddServiceUnits /RemoveServiceU nits call,
the first generated delta will always contain all the units added/removed.
This delta can be delayed (5 seconds, see above) or,
if the user refreshes, it will be immediately sent after the API handshake.