Do the description fields we've got in 3.3 help?
the problem is that if we go this way, we'd have to use an entirely different ID for the bridge name. I think having UUID's as bridge names won't be favored more... any chance rhel will support this in bridge names?
I've updated the upstream feature page for this. Do the remedies suggested under http://www.ovirt.org/Features/Unrestricted_Network_Names#Debuggability_Drawback make sense to GSS/PM? Current suggestions are 1. An ovirt-engine-shell script to map a brXXXXXXXXXXXXX name into the visible name of its owning network. 2. Make it possible to look a network up based on its vdsm_name (brXXXXXXXXXXXXX) in the network tab and in via the search box 3. Expose visible_name to the host when setting or changing a network via setupNetwork. visible_name would be persisted on the local host, and would be available for inspection by debuggers.
It should be verified for external networks as well. So if I import network with special characters from Neutron Provider to RHEV, the import should succeed
Vdsm allows any character in bridge names except for space, colon, and tab. However, other platform scripts may assign special meaning for special characters. For example, vdsm uses a specially-crafted bridge name ";vdsmdummy;" (notice the semicolons) internally. This was done to avoid collision with Engine-created names. But more painfully, it caused puppet to scream, as it did not handle the semicolon properly. Similarly, I suspect that many scripts in the sysadmin world would explode if we allowed a quotation mark or "@" or non-printable characters. Specifically, the dash symbol seems fine to me, and can be declared as valid in GUI (actually, we use a network name with a dash in vdsm unit test). But I don't think we should spend our time validating each and every character to be added to the valid set.
Per Dan's comment #26, is there any change needed? because the limitation here is very specific and fits with the platform support.
(In reply to Yaniv Dary from comment #27) > Per Dan's comment #26, is there any change needed? because the limitation > here is very specific and fits with the platform support. Well, at least the Dashes "-" should be supported as stated in C #19. Ideally everything that can be set with NetworkManager / RHEL networking for interface names as well, so that the naming is consistent in RHEV-M and on the Hypervisor to easily identify the corresponding network in RHEV. Cheers, Martin
Is the engine blocking the vdsm and RHEL supported names? can you create a network with a dash?
The engine allows a-z, A-Z, 0-9 and '_'. So dash is considered invalid. This can be fixed trivially, if this is okay on the host side.
ovirt-3.6.0-3 release
Verified on - 3.6.0-0.0.master.20150627185750.git6f063c1.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html