Re: [Engine-devel] alias in disk instead of name

Wed, 24 Oct 2012 21:01:48 -0700 

On 10/24/2012 10:24 AM, Simon Grinberg wrote:



----- Original Message -----

From: "Itamar Heim" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "Ewoud Kohl van Wijngaarden" <[email protected]>, "engine-devel" 
<[email protected]>
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" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "engine-devel" <[email protected]>
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.



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 <[email protected]>
wrote:



----- Original Message -----

From: "Charlie" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "engine-devel" <[email protected]>
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
<[email protected]>
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" <[email protected]>
To: "Michael Pasternak" <[email protected]>
Cc: "engine-devel" <[email protected]>
Sent: Monday, October 22, 2012 10:50:02 AM
Subject: Re: [Engine-devel] alias in disk instead of name



----- Original Message -----

From: "Michael Pasternak" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "engine-devel" <[email protected]>
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" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "engine-devel" <[email protected]>
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" <[email protected]>
To: "Simon Grinberg" <[email protected]>
Cc: "engine-devel" <[email protected]>
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" <[email protected]>
To: "engine-devel" <[email protected]>
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
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel




--

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




_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel





_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel




_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel




_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel





























					Reply via email to