[Engine-devel] alias in disk instead of name

Michael Pasternak mpastern at redhat.com
Mon Oct 22 06:58:25 UTC 2012


On 10/21/2012 06:13 PM, Simon Grinberg wrote:
> 
> 
> ----- Original Message -----
>> From: "Michael Pasternak" <mpastern at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> Sent: Sunday, October 21, 2012 4:56:33 PM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> On 10/21/2012 04:15 PM, Simon Grinberg wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>> To: "Simon Grinberg" <simon at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Sunday, October 21, 2012 3:48:46 PM
>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>>>>
>>>> On 10/21/2012 03:36 PM, Simon Grinberg wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>>> From: "Michael Pasternak" <mpastern at redhat.com>
>>>>>>> To: "engine-devel" <engine-devel at ovirt.org>
>>>>>>> Sent: Sunday, October 21, 2012 12:26:46 PM
>>>>>>> Subject: [Engine-devel] alias in disk instead of name
>>>>>>>
>>>>>>>
>>>>>>> The problem we caused by using alias in disk instead of name is
>>>>>>> break
>>>>>>> of search-by-name paradigm
>>>>>>> in engine.search dialect, not sure why we do not want forcing
>>>>>>> disk
>>>>>>> name to be unique [1],
>>>>>>> but lack of "name" in disk search is does not look good in my
>>>>>>> view.
>>>>>>>
>>>>>>> thoughts?
>>>>>>>
>>>>>>> [1] can be easily achieved via appropriate can-do-action
>>>>>>> verification.
>>>>> Names by definition are not unique IDs,
>>>>
>>>> they do, otherwise /search wasn't effective, remember users not
>>>> exposed to entity id, all entities fetched by-name, so names has
>>>> to
>>>> be unique.
>>>
>>> Yap that is what we do with many entities, and it causes problems.
>>> But with disks it is multiplied
>>>
>>>>
>>>>> thus it should not be enforced.
>>>>> What would be the auto naming conversion to ensure uniqueness
>>>>> with
>>>>> plain text?
>>>>
>>>> not sure i follow, i'll assume you refer here to empty name, - you
>>>> cannot have an
>>>> entity with no name.
>>>
>>> Well you create a new disk - do we want to enforce the user to
>>> provide a unique disk name/alias for every disk he creates?
>>> This will drive the user crazy. This is important even for user
>>> only for floating/shared disks. For any other disks user does not
>>> care if it's disk1, hd1, whatever. For these kind of disk, it's
>>> just a VM disk and the user does not care if in all VMs this is
>>> called disk 1 - so why bother him?
>>
>> from the same reason we have unique
>> clusters/datacenters/networks/templates/etc...
> 
> Networks, DataCenter, Clusters, templates - are in order of magnitude less then the number of disks. 
> And you name once and use many.
> 
> As for VMs - well it's may take that we should not force uniqueness either ( you can warn though )

you cannot have two vms with same name in same domain ...

> 
> For disks, well number is >= VMs to >>>= VMs 
> Name by definition is mostly interesting in many cases only within the VM, and we don't even have a way to correlate disk alias to the internal name in the VM. In many cases as said before, a user won't care about the name/alias if it is always attached to the same VM. A user will rather look the VM and then list it's disk. So actually I'll be better off with vm1.disk1 vm2.disk2 then unique name per disk (PS AFAIK) this should be the default suggested name by the UI, but then changing the VM name will break this (yes, I know it's not possible ATM, but many people I know requested for that).
> 
> So I as user will prefer that all the disks that created from a template will have the same name as the original template, and then to be able to search by (vm=name, disk=name) thus I can access easily the same disk for the VMs.
> 
> On the other hand for others, as you've mentioned (especially for floating and shared disk) the name/alias may be of importance, uniqueness may be very important. 

any disk can become shared.

> 
> All that I'm saying that we can't force it's not that uniqueness in never desired. 

simon, you missing the point, i was talking about /search,
search is available only at /api/disks (i.e shared disks, vm/template.disks is
irrelevant to this discussion)

> 
>>
>>>    
>>>>
>>>>> Would you change these on import/export?
>>>>
>>>> would you mind elaborating on this?
>>>
>>> Yes,
>>>
>>> You are already facing a problem when importing VMs that already
>>> have the same name, now you increasing the problem for disks that
>>> have the same alias. for same name we force clone if you want to
>>> import. Why for clone just because of a disk alias (this implies
>>> collapse snapshots ATM) or even bother the user with renaming
>>> disks that he does not care about the name so he just gave disk 1,
>>> 2, 3 and so on?
>>
>> i see your point, but then we leave no option for the user to locate
>> the disk,
>> simply because he doesn't have unique identifier,
>>
>> just imagine user A creating disk and calling it X,
>> then user B creating disk and calling it X, they on different
>> domains etc., and now both want to use disk X,
>>
>> how they can figure out which one to pick?, by SD, by size? agree
>> this is doesn't look well..., even more than that - someone may call
>> this "bad design"...
> 
> This is why the search should accept more then the name. 
> Example (vm=name, disk=name/alias)
> Example (dc=name, disk=name/alias)
> Example (sd=name, disk=name/alias)

it's not about accepting both name/alias, it's about missing ability
to identify your resource in collection.

> For floating/shared on the same SD/DC/VM I would suggest a warning if there is a duplicate in the system - not enforcement. 

ok, lets assume we WARN user that his disk's name is not unique, how user will pick the unique name?
implementing own code checking if new name (he wants to use) is unique or not?

- this is business logic, not user's prerogative.

> There is a difference between best practice and being enforcing up to the level that it annoys some of the users.

simon, when you register to email, you have to try N times till you find unique username,
is it convenient? absolutely NO, is it annoying? YES, but you forced doing that so
system will be able to identify you,

it's no different in any way, good software protects user/itself even in cost of convenience,

bottom line
===========

- i think as long as disk not shared/floating it can have any name
- in a minute disk designation changed to shared, name uniqueness should be forced (by the engine)
- when importing vm with shared disks, name uniqueness should be forced
- when creating vm from template with shared disk, name uniqueness should be forced
- alias should be changed back to name (in sake of consistency)
- /api/disks collection should support searching disks by name (in sake of consistency)


thoughts?

> 
>>
>>
>> --
>>
>> Michael Pasternak
>> RedHat, ENG-Virtualization R&D
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>


-- 

Michael Pasternak
RedHat, ENG-Virtualization R&D



More information about the Engine-devel mailing list