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

From: "Michael Pasternak" <mpastern@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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?

...

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?

...

And so on...

You should treat the name as a tag/alias that if you bothered to update, probably means something to you, if not then you don't care anyhow and will not search by it anyhow. So it's up to the user what to assign.

simon, we do not have any /name today in disk, you see it in api for backward compatibility, actually it's emulated over /alias,

Correct, we don't have name but alias especially because we wanted to emphasize it's not unique. But I've thought that aliases are treated like name, thus you have all the issues and suggesting to make them unique, and I'm trying to explain what we should try to avoid from having them unique. I agree, it's not fun when a you have 5 floating disk sharing the exact same alias - but maybe it should be the user responsibility to decide whether he is going to allow for it or not?

and the problem is when want to search by-name, it's not included in backend search.

...

--

Michael Pasternak RedHat, ENG-Virtualization R&D

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

From: "Michael Pasternak" <mpastern@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "engine-devel" <engine-devel@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 ) 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. All that I'm saying that we can't force it's not that uniqueness in never desired.

...

...

...

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) For floating/shared on the same SD/DC/VM I would suggest a warning if there is a duplicate in the system - not enforcement. There is a difference between best practice and being enforcing up to the level that it annoys some of the users.

--

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

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

From: "Michael Pasternak" <mpastern@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> >> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

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

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. As someone who has used the API for a multi tenancy situation I *know*

On Tue, Oct 23, 2012 at 04:36:53AM -0400, Simon Grinberg wrote: that the unique VM name contraint is very limiting. We ended up restorting to giving all VMs a vmSOMEHASH name and storing the actual names our customers wanted in the description field. This meant trading in the ability to search for VM names but gave us the freedom we needed. Now I haven't used the API with disks but I know our users generally don't care about the names their drives have. However, I realise that when you have detached disks they should be recognizable but can't you enforce that when they're being detached? And with shared disks it might be sufficient to show 'shared with VM X, Y and Z'.

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

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> >> To: "Simon Grinberg" <simon@redhat.com> >> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>> To: "engine-devel" <engine-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

--

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

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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.

--Charlie

On Tue, Oct 23, 2012 at 1:10 PM, Simon Grinberg <simon@redhat.com> wrote:

...

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

...

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> >> To: "Simon Grinberg" <simon@redhat.com> >> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>> To: "Simon Grinberg" <simon@redhat.com> >>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>> To: "engine-devel" <engine-devel@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@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >>

--

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

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

On 10/23/2012 08:07 PM, Simon Grinberg wrote:

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

...

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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 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@redhat.com> wrote:

...

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

...

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@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@redhat.com> To: "Michael Pasternak" <mpastern@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> > To: "Simon Grinberg" <simon@redhat.com> > Cc: "engine-devel" <engine-devel@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@redhat.com> >>> To: "Simon Grinberg" <simon@redhat.com> >>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>> To: "Simon Grinberg" <simon@redhat.com> >>>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>>> To: "engine-devel" <engine-devel@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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> > > > -- > > Michael Pasternak > RedHat, ENG-Virtualization R&D > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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@redhat.com> wrote:

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

...

From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>, "engine-devel" <engine-devel@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@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> wrote:

...

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

...

From: "Charlie" <medievalist@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@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@redhat.com> >> To: "Michael Pasternak" <mpastern@redhat.com> >> Cc: "engine-devel" <engine-devel@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@redhat.com> >>> To: "Simon Grinberg" <simon@redhat.com> >>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>> To: "Simon Grinberg" <simon@redhat.com> >>>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>> To: "Simon Grinberg" <simon@redhat.com> >>>>>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>>>>> To: "engine-devel" <engine-devel@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@ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> >>> >>> -- >>> >>> Michael Pasternak >>> RedHat, ENG-Virtualization R&D >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

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

From: "Itamar Heim" <iheim@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>, "engine-devel" <engine-devel@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@redhat.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "Ewoud Kohl van Wijngaarden" <ewoud@kohlvanwijngaarden.nl>, "engine-devel" <engine-devel@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@gmail.com> To: "Simon Grinberg" <simon@redhat.com> Cc: "engine-devel" <engine-devel@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@redhat.com> wrote:

...

----- Original Message ----- > From: "Charlie" <medievalist@gmail.com> > To: "Simon Grinberg" <simon@redhat.com> > Cc: "engine-devel" <engine-devel@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@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@redhat.com> >>> To: "Michael Pasternak" <mpastern@redhat.com> >>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>> To: "Simon Grinberg" <simon@redhat.com> >>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>> To: "Simon Grinberg" <simon@redhat.com> >>>>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>>> To: "Simon Grinberg" <simon@redhat.com> >>>>>>>> Cc: "engine-devel" <engine-devel@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@redhat.com> >>>>>>>>>>> To: "engine-devel" <engine-devel@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@ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>> >>>> >>>> >>>> -- >>>> >>>> Michael Pasternak >>>> RedHat, ENG-Virtualization R&D >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel

_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel