----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Simon Grinberg" <si...@redhat.com> > Cc: "Ewoud Kohl van Wijngaarden" <ew...@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" <medieval...@gmail.com> > >> To: "Simon Grinberg" <si...@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 <si...@redhat.com> > >> wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Charlie" <medieval...@gmail.com> > >>>> To: "Simon Grinberg" <si...@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 > >>>> <si...@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" <si...@redhat.com> > >>>>>> To: "Michael Pasternak" <mpast...@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" <mpast...@redhat.com> > >>>>>>> To: "Simon Grinberg" <si...@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" <mpast...@redhat.com> > >>>>>>>>> To: "Simon Grinberg" <si...@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" <mpast...@redhat.com> > >>>>>>>>>>> To: "Simon Grinberg" <si...@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" <mpast...@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