Bug 1142203

+++ This bug is a RHEV-M zstream clone. The original bug is: +++
+++   https://bugzilla.redhat.com/show_bug.cgi?id=1134009. +++
+++ Requested by "lvernia" +++
======================================================================



----------------------------------------------------------------------
Following comment by akotov on August 26 at 15:43:57, 2014

Version-Release number of selected component (if applicable):

rhevm-backend-3.4.1-0.31.el6ev.noarch

How reproducible:

Always

Steps to Reproduce:
1. Default cluster, 1 VM running, no labels attached to hosts NICs, default rhevm network
2.  Networks => Edit => Network label => type in test => press OK,OK

Actual results:

RHEV does not allow to add/edit label as network is in use by VMs
"Several virtual machines (1) are using this logical network"

Expected results:

RHEV should allow add/edit label with VMs running, as no network configuration is updated on the hosts. Behavior should be similar to editing description/comment for the network.


Additional info:

It should work at least if label is not currently in use by any hosts, not sure about possible implications if label is already used for some hosts.

----------------------------------------------------------------------
Following comment by nyechiel on August 27 at 12:07:17, 2014

This issue was already raised in the past. Moti, do we have any safe way to allow this?

Thanks,
Nir

----------------------------------------------------------------------
Following comment by akotov on August 27 at 12:58:58, 2014

I was able to workaround it BTW by hot-unplugging NIC from VM, doing what needs to be done with label, and plugging back NIC again.

----------------------------------------------------------------------
Following comment by masayag on August 31 at 07:21:53, 2014

(In reply to Nir Yechiel from comment #1)
> This issue was already raised in the past. Moti, do we have any safe way to
> allow this?
> 
> Thanks,
> Nir

Yes, currently the rename action is not supported.
Renaming a label of a network should behave as:
1. When network isn't used - allow it.
2. When network is provisioned on hosts via label - renaming the label will remove the network from the hosts. (If the user wish to preserve that label on the hosts, the user should label the hosts' interfaces with the new label)
2.1. If the network is being used by running vms, and renaming it will trigger its removal from hosts - it should be blocked.
2.1. The network should be configured on any host that is labeled with the new label, where the network hasn't been configured on that host.

Adding a label is simpler, since this action is currently supported
1. If the network is being used by vms, allow it: It implies the network is already configured on a host and adding a label will only provision it on hosts where that network hasn't been configured.

----------------------------------------------------------------------
Following comment by lvernia on September 02 at 12:50:44, 2014

Since Bug 1068626 already exists for renaming network labels, I'm limiting this to just the case of adding a new label for networks being used by VMs - should be easier to fix and solve a lot of issues for users/customers with existing deployments who are looking to adopt the feature.

----------------------------------------------------------------------
Following comment by lsurette on September 10 at 14:37:06, 2014

The logic that Moti explains above for adding new labels makes sense. We will add UX comments around editing network labels to Bug 1068626.