Red Hat Bugzilla – Bug 848354
[webadmin][setupNetworks] Unsynced networks boot parameters can be changed
Last modified: 2016-02-10 14:53:58 EST
Description of problem:
If an unsynched network exists on a Host's NIC, in setup networks the 'edit network' dialog will all be greyed out until the "sync network" checkbox is checked.
When checked, all fields become editable, but if unchecked after that then they become greyed out and still contain the modified values.
Attached is a screenshot where the original state was 'boot protocol = none'.
I believe that in this state, if the user will click OK in the setup networks dialog he will get a can do action failure from the engine side which claims that unsynced networks cannot be edited unless synced.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Have an unsynced network on a host's nic:
1.1. Attach network to a NIC.
1.2. Change the network MTU to something different.
2. In setup networks dialog for the host's NICs, click the pencil on the unsynched network.
3. Check the 'sync network' checkbox.
4. Change the boot protocol to something different.
5. Uncheck the 'sync network' checkbox.
The modified boot protocol values will remain in the edit dialog.
When unchecked, the values before checking the box should return.
This should also be the case if the checkbox is unchecked after the dialog was closed and open again.
Created attachment 604578 [details]
(In reply to comment #0)
> I believe that in this state, if the user will click OK in the setup
> networks dialog he will get a can do action failure from the engine side
> which claims that unsynced networks cannot be edited unless synced.
If that happens this is indeed wrong - but this is the only real problem which you are unsure yet. This needs to be verified
> Expected results:
> When unchecked, the values before checking the box should return.
This is not a must as long as the changes are ignored, though I admit it looks better.
There are many applications that will not restore old value but just ignore changes. So if it keeps to that, this is not urgent to fix (if at all)
upstream commit 144c89384f8bc44c0d7cf41d60f008f7699b5367
the first commit caused a bug- fixed in upstream commit c286544f8167a7e1d5dfcb8ee8c38adc065514c6
phase 3- upstream coomit 91e8ed3a0dae71dd364c6aeeacee907d5f46b3cf
Verified on rhevm-3.1.0-15.el6ev.noarch