Bug 1569240 - [RFE] Replace UUID with human readable unique IDs to simplify supportability [NEEDINFO]
Summary: [RFE] Replace UUID with human readable unique IDs to simplify supportability
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Pavel Stehlik
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-18 20:55 UTC by Marina Kalinin
Modified: 2019-05-16 13:05 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2018-04-22 07:56:04 UTC
oVirt Team: Infra
Target Upstream Version:
rmcswain: needinfo?

Attachments (Terms of Use)

Description Marina Kalinin 2018-04-18 20:55:18 UTC
This is a request to consider replacing UUIDs in RHV product with human readable unique IDs.

Example of those IDs:

The reason for this request is to ease the troubleshooting process of RHV, that widely uses UUIDs across all of its components. Having human readable words would ease the log processing significantly and ideally reduce the cost to support as well.

Comment 1 Marina Kalinin 2018-04-18 20:56:50 UTC
Here is an example code of such IDs generator:

And here is an example from gfycat:

Comment 2 Yaniv Kaul 2018-04-18 21:15:09 UTC
That's unlikely to happen. Some of those UUIDs are in our DB.

Comment 3 Martin Perina 2018-04-19 08:03:11 UTC
UUIDs are standard way to generate unique identifiers for databases and UUIDs are widely supported. Also UUIDs are not meant to be used by users, that's why we have name property for all entities and that's what users are using. If there's need for support team to go deeper into the database then they need to use UUIDs same as developers.

But I'd really like to get some examples where you need to use UUIDs instead of names. Of course when you go deeper into the stack you need to switch to UUIDs or other low level identifiers, but do you really need to use UUIDs when investigating issues on engine or VDMS layer? Or is this only due to not providing names within logs?

Comment 4 Marina Kalinin 2018-04-20 13:23:01 UTC

Re: not providing names in logs - I actually really love this idea. It makes it much easier to share the logs in bugzilla or KCS without worrying to leak customer's info.

Re: the main use case: for any storage issue, we go from the database to the storage, need to work with the uuids of each entity (from DataCenter, through VM name and up to the volumes in the image chain for each disk). The idea of this request is that words (unique word combinataions) can help processing this information easier.

Robert, would you like to provide more examples here to support this request?

Comment 5 Yaniv Kaul 2018-04-22 07:56:04 UTC
Marina, realistically, it's not going to happen. We use UUIDs everywhere, from DB to metadata in our domains.

Comment 6 Robert McSwain 2018-04-23 20:40:16 UTC
When you say that UUIDs are not meant to be used by users, that negates the human element required in so much of the debugging that Support deals with or the readability for when we give customers sql commands to fix issues such as snapshots deletion/live merge issues in RHV. 

UUIDs currently use one method for providing a unique identifier, however Containers use a two word "adjective_noun" styled method for container names so similar things are being implemented elsewhere in Red Hat as a precedent.

I strongly request that you reconsider this for a future version of RHV, as looking at a /rhev/datacenter/ tree output while working on a snapshot/live storage migration issue is enough to drive most engineers insane and having words rather than nondescript character strings to read through would be greatly appreciated.  The code for generating them is already freely available. Let's use it and make this an easier product to work on from a Support perspective.

Comment 7 Franta Kust 2019-05-16 13:05:11 UTC
BZ<2>Jira Resync

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