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

----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Simon Grinberg" <simon(a)redhat.com&gt; > Cc: "Ewoud Kohl van Wijngaarden" <ewoud(a)kohlvanwijngaarden.nl&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; > 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(a)gmail.com&gt; >>> To: "Simon Grinberg" <simon(a)redhat.com&gt; >>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>> 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(a)redhat.com&gt; >>> wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Charlie" <medievalist(a)gmail.com&gt; >>>>> To: "Simon Grinberg" <simon(a)redhat.com&gt; >>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>> 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(a)redhat.com&gt; >>>>> 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(a)redhat.com&gt; >>>>>>> To: "Michael Pasternak" <mpastern(a)redhat.com&gt; >>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>> 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(a)redhat.com&gt; >>>>>>>> To: "Simon Grinberg" <simon(a)redhat.com&gt; >>>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>> 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(a)redhat.com&gt; >>>>>>>>>> To: "Simon Grinberg" <simon(a)redhat.com&gt; >>>>>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>>>> 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(a)redhat.com&gt; >>>>>>>>>>>> To: "Simon Grinberg" <simon(a)redhat.com&gt; >>>>>>>>>>>> Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>>>>>> 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(a)redhat.com&gt; >>>>>>>>>>>>>>> To: "engine-devel" <engine-devel(a)ovirt.org&gt; >>>>>>>>>>>>>>> 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(a)ovirt.org >>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Michael Pasternak >>>>>>>> RedHat, ENG-Virtualization R&D >>>>>>>> _______________________________________________ >>>>>>>> Engine-devel mailing list >>>>>>>> Engine-devel(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >