[Engine-devel] alias in disk instead of name

Simon Grinberg simon at redhat.com
Tue Oct 23 17:10:46 UTC 2012 


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

More information about the Engine-devel mailing list