[Engine-devel] alias in disk instead of name
Simon Grinberg
simon at redhat.com
Thu Oct 25 10:34:30 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: Thursday, October 25, 2012 6:01:33 AM
> Subject: Re: [Engine-devel] alias in disk instead of name
>
> On 10/24/2012 10:24 AM, Simon Grinberg 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
>
> most users will probably be part of a single tenant.
> I suggest a simpler solution:
> for now:
> for VMs -> vm
> for disks -> vm.disk
>
> with tenatns
> for vMs -> [tenant] vm
> for disks -> [tenant] vm.disk
>
> why?
> i think a user with multiple tenants is a unique case, so while i
> don't
> want to prevent it in the system, i don't think we should make the
> system more complex for it.
>
> so i think entities should be unique at tenant level[see template
> below], not dc level (a tenant may not know tomorrow what a DC is if
> we
> abstract it for them under quota via some magic).
> and i think to make it simple, a user with a single tenant will just
> not
> need to specify it, and a user with multiple tenants may have to
> specify
> it at login time (well, its a post login prompt for UI, and a
> header/field in REST API).
>
> if we see users with multiple tenants are very common, we can remove
> this requirement, and even then i would claim the tenant is required
> only if the query returns more than a single entry, so you would fail
> it
> on "ambiguous result", please provide 'fqdn' (tenant.vm).
>
> [template] there is one entity that defies this rule which is the
> template. since you want to be able to make your template public, or
> give permissions on your templates to some other tenants.
> so i think 'public' is a predefined tenant.
>
> thinking about this some more, i don't have an issue with tenants
> (like
> users), sharing resources via the permissions model.
>
> and for uniqueness, same rules apply - if user gets more than a
> single
> entity, its ambiguous, and they need to prefix it with the tenant
> (they
> can choose to always do so).
>
> another approach:
> - we could say only users with more than a single tenant must always
> specify the tenant
> - to use an entity from another tenant (public, or other), they must
> specify the entity prefix as well.
>
> thinking about it some more, maybe i like this even better.
As long as it's clear that VMs names unique in tenant scope and Disks names are unique in the VM scope then I see nothing wrong with using tenants, I just tried to stick to entities that are currently available like DC and Quotas, and since Quota is a DC scope entity I've suggest those. I'm perfectly fine with tenant. Your proposal is exactly what I've meant id you s/dc.quota/tenant
The last approach that you like so much is a must for admin roles queries, and yes covers users that belong to multiple tenants (in private clouds, there is a good probability this will happen)
Just a minor addition - for floating disk you still need the floating scope (notice I don't say floating VM, I would prefer to avoid another 'blank template' case)
So +1
>
> >
> > 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.
>
> isn't this why we called the field 'alias'? since the 'name' of the
> VM
> is always unique in the system (a uuid)?
>
> >
> > 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 Devel
mailing list