[Engine-devel] alias in disk instead of name

Simon Grinberg simon at redhat.com
Wed Oct 24 08:24:20 UTC 2012 


----- 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
>

More information about the Engine-devel mailing list