Bug 835035 - webadmin - network: renaming of a logical network is problematic
webadmin - network: renaming of a logical network is problematic
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.0
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: lpeer
yeylon@redhat.com
network ux
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-25 06:24 EDT by Yaniv Kaul
Modified: 2016-04-18 02:44 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-18 03:11:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Yaniv Kaul 2012-06-25 06:24:00 EDT
Description of problem:
1. Iv'e created a logical network named 'eth1'
2. Attached to an interface named 'eth1'.
3. As I've discovered it's not the greatest name to a network, I went ahead and renamed it - via the DC logical networks - I detached it, edited it, reattached ('apply all')

Result:
1. The network name that is attached to the host is still 'eth1'.
2. In Setup networks, I suddenly have a 'new' network that I can attach to a NIC - the one with the new name.

I understand the design, but the bottom line isn't good, if all I wanted to do was change the logical name of the network (didn't test change description only).

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

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Yaniv Kaul 2012-06-25 06:25:18 EDT
Shown to and discussed with Alona.
Comment 2 lpeer 2012-07-17 02:56:15 EDT
(In reply to comment #1)
> Shown to and discussed with Alona.

I think that as long as you don't delete the network from the host, RHEVM can't identify the user intended to use the same network - it can even not be true for some use cases.

After handling unmanaged network, the network eth0 will appear to the user as unmanaged network and this reflects to the user the network configuration very clearly.
Comment 3 Yaniv Kaul 2012-07-17 06:31:58 EDT
(In reply to comment #2)
> (In reply to comment #1)
> > Shown to and discussed with Alona.
> 
> I think that as long as you don't delete the network from the host, RHEVM
> can't identify the user intended to use the same network - it can even not
> be true for some use cases.
> 
> After handling unmanaged network, the network eth0 will appear to the user
> as unmanaged network and this reflects to the user the network configuration
> very clearly.

I suspect the core issue is that we use names as unique identifiers on the host as well. If we use something (say, UUID), and we don't abuse the name of the network as an identifier on the host, there wouldn't have been any problem with this change.
Comment 4 lpeer 2012-07-18 03:11:39 EDT
> I suspect the core issue is that we use names as unique identifiers on the
> host as well. If we use something (say, UUID), and we don't abuse the name
> of the network as an identifier on the host, there wouldn't have been any
> problem with this change.

Using UUID on the host has it's advantages but also some disadvantages:

For example today you can create a network on the host with any tweaks you need and the engine will still be able to use it as part of an existing network.
When using UUID's on the host, configuring the network manually becomes more complicated. 

Anyway If you see a use case for using UUIDs on the host level you should open RFE for that - where we can discuss the benefits of using UUID vs using names.

The described issue in this BZ is not something I am considering a bug, it's a system behaviour and I can argue that there are pro's for taking this approach VS. deciding the network defined on the host is the same network (regardless if using IDs or names).

I am closing this as not a bug but please feel free to re-open if you think I am terribly wrong and this should be discussed further.
Comment 5 Yaniv Kaul 2012-07-18 03:19:21 EDT
It's obviously a bug. If R&D does not plan to fix it - fine. 
Moving to CLOSED-WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.