[Engine-devel] alias in disk instead of name

Charlie medievalist at gmail.com
Wed Oct 24 21:36:40 UTC 2012 

Makes sense to me, in the context of the concerns you raised earlier.
I did not suggest prepending vm name because I was not absolutely sure
it was guaranteed unique (I'm lurking here to learn these things).

--C

On Wed, Oct 24, 2012 at 4:24 AM, Simon Grinberg <simon at redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Simon Grinberg" <simon at redhat.com>
>> Cc: "Ewoud Kohl van Wijngaarden" <ewoud at kohlvanwijngaarden.nl>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, October 24, 2012 6:01:53 AM
>> Subject: Re: [Engine-devel] alias in disk instead of name
>>
>> On 10/23/2012 08:07 PM, Simon Grinberg wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Charlie" <medievalist at gmail.com>
>> >> To: "Simon Grinberg" <simon at redhat.com>
>> >> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >> Sent: Tuesday, October 23, 2012 7:53:10 PM
>> >> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>
>> >> Why not something like this?
>> >>
>> >> (pseudocode, using dot for string concatenation):
>> >>
>> >> $name_prefix = "vmdrive"
>> >> $name = get_last_used($name_prefix)
>> >> $already_in_use = $TRUE
>> >>
>> >> while $already_in_use {
>> >>       prompt "Name of thing? [$name] ", $name
>> >>       if name_used($name) {
>> >>           while name_used($name) {
>> >>              increment_number($name)
>> >>           }
>> >>       } else {
>> >>           $already_in_use = FALSE
>> >>       }
>> >> }
>> >>
>> >> do_whatever_you_do_with($name)
>> >>
>> >> store_last_used($name)
>> >>
>> >> end
>> >>
>> >>
>> >> The increment_number() routine checks to see if the last character
>> >> is
>> >> numeric, and if it is, increments the leftmost contiguous numeric
>> >> portion of the string.  Otherwise it appends the number zero.
>> >>
>> >> This does not allow everyone to get any name they want, but you
>> >> can't
>> >> ever satisfy that demand.  It supplies reasonable defaults very
>> >> quickly and it allows people who want really descriptive names to
>> >> try
>> >> as many as they like.
>> >>
>> >> The code's built the funny way it is so that you can corrupt the
>> >> db
>> >> that holds the last_used numbers or interrupt the process halfway
>> >> through and it still works, only slower, and it should tend to fix
>> >> its
>> >> own db on the fly when possible.
>> >>
>> >> There's no provision for simultaneous creation, but that wouldn't
>> >> be
>> >> horribly hard to add, just put a lock on the resource holding
>> >> last_used numbers.
>> >>
>> >> You'd want to reimplement in the most efficient and readable way
>> >> for
>> >> your programming language of choice.
>> >>
>> >> Did that make any sense?  I did it off the top of my head, so it
>> >> could
>> >> be terribly lame when I look at it tomorrow ;).
>> >
>> > Please don't look at it as pure programming item, nor as a single
>> > user in a small data center - in this respect you are right.
>> > Let's got to a huge organization or to the cloud.
>> >
>> > In multi tenant environment this lock means that every time a user
>> > tries to change a disk name - all the others are stack
>> > Don't forget we are discussing thousands of VMs - I'll hate to have
>> > this kind of lock just to allow for unique disk names. This is one
>> > of the reasons you use UUID to really identify the object in the
>> > DB, since it's suppose to guarantee uniqueness without the need to
>> > lock everything.
>> >
>> > And again - please look at this as an end user, why do I care that
>> > other users had decided they are going to use the same name as me?
>> > This is my human readable name and I want to choose what ever I
>> > like without considering other users. What is this self service
>> > portal worth if I can't name my VMs and Disks as I'd like to,
>> > oblivious to others?
>> >
>> > At the end of day, you want oVirt to be useful and scalable - and
>> > not just code wise correct.
>>
>>
>> how about KISS?
>> vm name is unique.
>> disk name is unique in vm.
>> treat disk name for search as vm.name + "-" + disk.name
>
> Now we are getting somewhere since this is similar to my original proposal of adding vm/domain/other to the disk search criteria
>
> But let me take your proposal a bit farther.
> I think it's safe to assume / force that tenants don't share quotas, meaning a tenant may have multiple quotas but a quota may belong to a single tenant (and I know the term tenant is not well defined, but let's assume the under any definition for this discussion it may be collapsed to a collection of users and groups)
>
> The problem is now reduced to keeping to scope boundaries.
>
> Quota name is unique in the scope of a data center
> VM name is unique in the scope of a quota (note that I intentionally don't say cluster)
> Disk name is unique in the scope of a VM or the floating scope
>
> Now to search is easy
> For VMs -> dc.quota.vm
> For disks -> dc.quota.vm.disk
> Or For floating -> dc.quota.floating.disk
> Shared disk may be accessed from any of the attached VMs
>
> when Quota is off -> you get the simple equivalent
> For VMs -> dc.vm
> For disks -> dc.vm.disk
> Or For floating -> dc.floating.disk
> Shared disk may be accessed from any of the attached VMs
>
> This is KISS, scalable, and I believe easy to understand by any user of oVirt.
>
> And in order not to bother users with providing a unique name in the scope we should always offer a name for the user to just click OK or modify, similar (may be even simpler) algorithm to what Charlie suggested.
> The above is for:
> 1. New disk
> 2. Detach disk from the last VM, meaning it becomes floating, if the name is not unique, then suggest a free name based on the current name.
>
> A nice benefit of the above is that the user may use wild cards, and get a list of matches filtered by his permissions.
> Example:
> admin searching for dc-X.quota-Y.* gets a list of all the floating disks in the quota
> user searching for the same  will get a list of all the floating disks he has permissions on.
>
> Thoughts?
>
>
>>
>> as for name uniqueness for multi tenants, yes, something we need to
>> fix.
>> would love for more inputs on how people see tenants and users
>> interact
>> in ovirt (can a user be part of more than a single tenant for
>> example,
>> but force user to choose tenant when they login if they have more
>> than one)?
>>
>> >
>> >
>> >>
>> >> --Charlie
>> >>
>> >> On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon at redhat.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> ----- Original Message -----
>> >>>> From: "Charlie" <medievalist at gmail.com>
>> >>>> To: "Simon Grinberg" <simon at redhat.com>
>> >>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>> Sent: Tuesday, October 23, 2012 6:51:35 PM
>> >>>> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>>>
>> >>>> OK, only because you asked...
>> >>>>
>> >>>> Provide default unique names, so that users can just press enter
>> >>>> if
>> >>>> names don't matter to them.  That way you obviate the entire
>> >>>> argument;
>> >>>> people who need special naming can have it, and everybody else
>> >>>> has
>> >>>> a
>> >>>> single extra keypress or mouseclick at naming time, and
>> >>>> searching
>> >>>> works well enough.
>> >>>>
>> >>>> You can name the first one vmdrive0 and increment the numeric
>> >>>> part
>> >>>> each time a new drive is created.  Iterating until an unused
>> >>>> name
>> >>>> is
>> >>>> found isn't so computationally expensive that anyone should
>> >>>> weep,
>> >>>> especially if you store the last used number and do an
>> >>>> incrementing
>> >>>> sanity check against it at naming time.
>> >>>
>> >>> Let's say the above solved all conflicts when coming to create a
>> >>> new disk, it does seems so.
>> >>>
>> >>> Let's say that import/export if names conflict can be solved in a
>> >>> reasonable way - for example forcing (somehow and without
>> >>> bothering the user too much) a rename of the disk (How would you
>> >>> know if the conflicting name id auto-generated so can be replaced
>> >>> or user provided?, you'll have to resort to
>> >>> non-that-human-look-alike-name)
>> >>>
>> >>> How does it solve the multi-tenancy use case?
>> >>> I'm tenant A, setting up a quorum disk for my two VMs - so I call
>> >>> this disk simply quorum.
>> >>> Now comes tenant B, he is also setting up a quorum disk, so he
>> >>> tries to call his disk quorum
>> >>>
>> >>> But no,
>> >>> He'll get a popup that this name is already taken - bad luck
>> >>> buddy.
>> >>> Now he needs to guess the next available name? Would you build in
>> >>> algorithm to suggest alternatives?
>> >>> Why should tenant B care in the first place that tenant A also
>> >>> wanted to call his disk 'quorum'?
>> >>>
>> >>> Same with the VM name - but that is given for now, though I hope
>> >>> to
>> >>> convince it should change in the future.
>> >>>
>> >>> What I'm trying to say here - infrastructure is for the admin -
>> >>> so
>> >>> you can force uniqueness
>> >>> Resources like, disks and Virtual Machine belong to the end user
>> >>> thus you should let them determine their own names without being
>> >>> restricted by users of the system.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> People expect names to have significance, and we like it when
>> >>>> they
>> >>>> have both unique and non-unique parts.  It's part of our human
>> >>>> heritage.  Maybe whales and dolphins don't care.
>> >>>
>> >>>
>> >>>
>> >>>>
>> >>>> --Charlie
>> >>>>
>> >>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg
>> >>>> <simon at redhat.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> We need more thoughts here from others, there are two different
>> >>>>> approaches on the table and more opinions are welcomed.
>> >>>>> If there are API consumers on this list then your view is more
>> >>>>> then
>> >>>>> welcomed.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Simon.
>> >>>>>
>> >>>>> ----- Original Message -----
>> >>>>>> From: "Simon Grinberg" <simon at redhat.com>
>> >>>>>> To: "Michael Pasternak" <mpastern at redhat.com>
>> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>> >>>>>> Sent: Monday, October 22, 2012 10:50:02 AM
>> >>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> ----- 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: Monday, October 22, 2012 8:58:25 AM
>> >>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name
>> >>>>>>>
>> >>>>>>> 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 ...
>> >>>>>>
>> >>>>>> I didn't say that in a domain you are allowed to have two
>> >>>>>> guests
>> >>>>>> with
>> >>>>>> the same hostname, I've said engine should allow for having
>> >>>>>> duplicate VM names.
>> >>>>>> You are assuming that the VM name is identical to the guest
>> >>>>>> host
>> >>>>>> name.
>> >>>>>>
>> >>>>>> For many this is the case, for other it's just an alias/name
>> >>>>>> given
>> >>>>>> in
>> >>>>>> oVirt.
>> >>>>>> Actually for the cloud, this is mostly going to be the case
>> >>>>>> and
>> >>>>>> worse, you are blocking different tenants from having the same
>> >>>>>> VM
>> >>>>>> name just because you are assuming that VM name = guest
>> >>>>>> hostname.
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> 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.
>> >>>>>>
>> >>>>>> Then when you make it shared then bother to give it a
>> >>>>>> meaningful
>> >>>>>> alias
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>> 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)
>> >>>>>>
>> >>>>>> Nope I do not, but I think that our perspectives differ.
>> >>>>>> You are looking at it as strictly design issue. You have a
>> >>>>>> collection
>> >>>>>> of entities and you want a human readable search, thus you are
>> >>>>>> trying to force (rightfully) from your point of view a unique
>> >>>>>> alias/name for those.
>> >>>>>>
>> >>>>>> I taking the end user perspective, and user experience
>> >>>>>> 1. Majority of the disks have no meaning outside of a VM
>> >>>>>> scope.
>> >>>>>> 2. There are fractions of the disks that are usually shared
>> >>>>>> (this
>> >>>>>> is
>> >>>>>> the nature of shared disks)
>> >>>>>> 3. There are fractions of floating, most of the floating will
>> >>>>>> be a
>> >>>>>> transient state, while you are moving disks around.
>> >>>>>>
>> >>>>>> What I'm trying to say that forcing a user to provide a unique
>> >>>>>> name
>> >>>>>> per disk is a huge bother.
>> >>>>>> And again in the multi tenancy case, you can't enforce a
>> >>>>>> unique
>> >>>>>> alias
>> >>>>>> in the system.
>> >>>>>>
>> >>>>>> What will you say to the user in the error message?
>> >>>>>> Sorry you can't use this alias since another user that is
>> >>>>>> sharing
>> >>>>>> the
>> >>>>>> system with you already provided that name? And yes we know
>> >>>>>> you
>> >>>>>> can't see that other disk, and it you don't care about the
>> >>>>>> other
>> >>>>>> user, but still you can't use your alias since this is how our
>> >>>>>> platform designed.
>> >>>>>>
>> >>>>>> The meaning is that you must allow a for a more sophisticated
>> >>>>>> search.
>> >>>>>> Yes even in the context of the disks tab. Disks are not really
>> >>>>>> stand
>> >>>>>> alone entities, and if we keep to strict conventions like - in
>> >>>>>> any
>> >>>>>> collection an entity name must be unique, then you are making
>> >>>>>> the
>> >>>>>> system hardly usable for many users.
>> >>>>>>
>> >>>>>> So a search in disks should include other 'properties' (and
>> >>>>>> yes
>> >>>>>> I
>> >>>>>> know those are not disk properties, but this is how a user
>> >>>>>> will
>> >>>>>> look
>> >>>>>> at it) like owner,quota,vm,storage domain, etc.
>> >>>>>>
>> >>>>>> To some up - what should be unique are UUIDs of an entities,
>> >>>>>> and
>> >>>>>> infrastructure entities names (within the same scope) - all
>> >>>>>> the
>> >>>>>> rest
>> >>>>>> must not.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>> 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?
>> >>>>>>
>> >>>>>> Please look at the previous comment, that just can't work in
>> >>>>>> the
>> >>>>>> multi-tenancy case.
>> >>>>>> Name should not be unique, the warning is for the admin only,
>> >>>>>> from
>> >>>>>> the user portal a warning should be issues only if the user
>> >>>>>> provides
>> >>>>>> same name twice.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> --
>> >>>>>>>>>
>> >>>>>>>>> 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
>> >>>>>>> _______________________________________________
>> >>>>>>> Engine-devel mailing list
>> >>>>>>> Engine-devel at ovirt.org
>> >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>>>>>>
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> Engine-devel mailing list
>> >>>>> Engine-devel at ovirt.org
>> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >>>>
>> >>
>> > _______________________________________________
>> > Engine-devel mailing list
>> > Engine-devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>> >
>>
>>
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

More information about the Engine-devel mailing list