Bug 835035
| Summary: | webadmin - network: renaming of a logical network is problematic | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Yaniv Kaul <ykaul> |
| Component: | ovirt-engine-webadmin-portal | Assignee: | lpeer <lpeer> |
| Status: | CLOSED WONTFIX | QA Contact: | yeylon <yeylon> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.1.0 | CC: | acathrow, dyasny, ecohen, iheim, jkt, lpeer, Rhev-m-bugs, srevivo, ykaul |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | network ux | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-18 07:11:39 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Shown to and discussed with Alona. (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. (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. > 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.
It's obviously a bug. If R&D does not plan to fix it - fine. Moving to CLOSED-WONTFIX. |
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: