----- Original Message ----- > From: "Itamar Heim" <[email protected]> > To: "Simon Grinberg" <[email protected]> > Cc: "Ewoud Kohl van Wijngaarden" <[email protected]>, > "engine-devel" <[email protected]> > 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" <[email protected]> > >> To: "Simon Grinberg" <[email protected]> > >> Cc: "Ewoud Kohl van Wijngaarden" <[email protected]>, > >> "engine-devel" <[email protected]> > >> Sent: Wednesday, October 24, 2012 6:01:53 AM > >> Subject: Re: [Engine-devel] alias in disk instead of name > >> > >> On 10/23/2012 08:07 PM, Simon Grinberg wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Charlie" <[email protected]> > >>>> To: "Simon Grinberg" <[email protected]> > >>>> Cc: "engine-devel" <[email protected]> > >>>> Sent: Tuesday, October 23, 2012 7:53:10 PM > >>>> Subject: Re: [Engine-devel] alias in disk instead of name > >>>> > >>>> Why not something like this? > >>>> > >>>> (pseudocode, using dot for string concatenation): > >>>> > >>>> $name_prefix = "vmdrive" > >>>> $name = get_last_used($name_prefix) > >>>> $already_in_use = $TRUE > >>>> > >>>> while $already_in_use { > >>>> prompt "Name of thing? [$name] ", $name > >>>> if name_used($name) { > >>>> while name_used($name) { > >>>> increment_number($name) > >>>> } > >>>> } else { > >>>> $already_in_use = FALSE > >>>> } > >>>> } > >>>> > >>>> do_whatever_you_do_with($name) > >>>> > >>>> store_last_used($name) > >>>> > >>>> end > >>>> > >>>> > >>>> The increment_number() routine checks to see if the last > >>>> character > >>>> is > >>>> numeric, and if it is, increments the leftmost contiguous > >>>> numeric > >>>> portion of the string. Otherwise it appends the number zero. > >>>> > >>>> This does not allow everyone to get any name they want, but you > >>>> can't > >>>> ever satisfy that demand. It supplies reasonable defaults very > >>>> quickly and it allows people who want really descriptive names > >>>> to > >>>> try > >>>> as many as they like. > >>>> > >>>> The code's built the funny way it is so that you can corrupt the > >>>> db > >>>> that holds the last_used numbers or interrupt the process > >>>> halfway > >>>> through and it still works, only slower, and it should tend to > >>>> fix > >>>> its > >>>> own db on the fly when possible. > >>>> > >>>> There's no provision for simultaneous creation, but that > >>>> wouldn't > >>>> be > >>>> horribly hard to add, just put a lock on the resource holding > >>>> last_used numbers. > >>>> > >>>> You'd want to reimplement in the most efficient and readable way > >>>> for > >>>> your programming language of choice. > >>>> > >>>> Did that make any sense? I did it off the top of my head, so it > >>>> could > >>>> be terribly lame when I look at it tomorrow ;). > >>> > >>> Please don't look at it as pure programming item, nor as a single > >>> user in a small data center - in this respect you are right. > >>> Let's got to a huge organization or to the cloud. > >>> > >>> In multi tenant environment this lock means that every time a > >>> user > >>> tries to change a disk name - all the others are stack > >>> Don't forget we are discussing thousands of VMs - I'll hate to > >>> have > >>> this kind of lock just to allow for unique disk names. This is > >>> one > >>> of the reasons you use UUID to really identify the object in the > >>> DB, since it's suppose to guarantee uniqueness without the need > >>> to > >>> lock everything. > >>> > >>> And again - please look at this as an end user, why do I care > >>> that > >>> other users had decided they are going to use the same name as > >>> me? > >>> This is my human readable name and I want to choose what ever I > >>> like without considering other users. What is this self service > >>> portal worth if I can't name my VMs and Disks as I'd like to, > >>> oblivious to others? > >>> > >>> At the end of day, you want oVirt to be useful and scalable - and > >>> not just code wise correct. > >> > >> > >> how about KISS? > >> vm name is unique. > >> disk name is unique in vm. > >> treat disk name for search as vm.name + "-" + disk.name > > > > Now we are getting somewhere since this is similar to my original > > proposal of adding vm/domain/other to the disk search criteria > > > > But let me take your proposal a bit farther. > > I think it's safe to assume / force that tenants don't share > > quotas, meaning a tenant may have multiple quotas but a quota may > > belong to a single tenant (and I know the term tenant is not well > > defined, but let's assume the under any definition for this > > discussion it may be collapsed to a collection of users and > > groups) > > > > The problem is now reduced to keeping to scope boundaries. > > > > Quota name is unique in the scope of a data center > > VM name is unique in the scope of a quota (note that I > > intentionally don't say cluster) > > Disk name is unique in the scope of a VM or the floating scope > > > > Now to search is easy > > For VMs -> dc.quota.vm > > For disks -> dc.quota.vm.disk > > Or For floating -> dc.quota.floating.disk > > Shared disk may be accessed from any of the attached VMs > > > > when Quota is off -> you get the simple equivalent > > For VMs -> dc.vm > > For disks -> dc.vm.disk > > Or For floating -> dc.floating.disk > > Shared disk may be accessed from any of the attached VMs > > most users will probably be part of a single tenant. > I suggest a simpler solution: > for now: > for VMs -> vm > for disks -> vm.disk > > with tenatns > for vMs -> [tenant] vm > for disks -> [tenant] vm.disk > > why? > i think a user with multiple tenants is a unique case, so while i > don't > want to prevent it in the system, i don't think we should make the > system more complex for it. > > so i think entities should be unique at tenant level[see template > below], not dc level (a tenant may not know tomorrow what a DC is if > we > abstract it for them under quota via some magic). > and i think to make it simple, a user with a single tenant will just > not > need to specify it, and a user with multiple tenants may have to > specify > it at login time (well, its a post login prompt for UI, and a > header/field in REST API). > > if we see users with multiple tenants are very common, we can remove > this requirement, and even then i would claim the tenant is required > only if the query returns more than a single entry, so you would fail > it > on "ambiguous result", please provide 'fqdn' (tenant.vm). > > [template] there is one entity that defies this rule which is the > template. since you want to be able to make your template public, or > give permissions on your templates to some other tenants. > so i think 'public' is a predefined tenant. > > thinking about this some more, i don't have an issue with tenants > (like > users), sharing resources via the permissions model. > > and for uniqueness, same rules apply - if user gets more than a > single > entity, its ambiguous, and they need to prefix it with the tenant > (they > can choose to always do so). > > another approach: > - we could say only users with more than a single tenant must always > specify the tenant > - to use an entity from another tenant (public, or other), they must > specify the entity prefix as well. > > thinking about it some more, maybe i like this even better.
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 > >>>> <[email protected]> > >>>> wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Charlie" <[email protected]> > >>>>>> To: "Simon Grinberg" <[email protected]> > >>>>>> Cc: "engine-devel" <[email protected]> > >>>>>> Sent: Tuesday, October 23, 2012 6:51:35 PM > >>>>>> Subject: Re: [Engine-devel] alias in disk instead of name > >>>>>> > >>>>>> OK, only because you asked... > >>>>>> > >>>>>> Provide default unique names, so that users can just press > >>>>>> enter > >>>>>> if > >>>>>> names don't matter to them. That way you obviate the entire > >>>>>> argument; > >>>>>> people who need special naming can have it, and everybody else > >>>>>> has > >>>>>> a > >>>>>> single extra keypress or mouseclick at naming time, and > >>>>>> searching > >>>>>> works well enough. > >>>>>> > >>>>>> You can name the first one vmdrive0 and increment the numeric > >>>>>> part > >>>>>> each time a new drive is created. Iterating until an unused > >>>>>> name > >>>>>> is > >>>>>> found isn't so computationally expensive that anyone should > >>>>>> weep, > >>>>>> especially if you store the last used number and do an > >>>>>> incrementing > >>>>>> sanity check against it at naming time. > >>>>> > >>>>> Let's say the above solved all conflicts when coming to create > >>>>> a > >>>>> new disk, it does seems so. > >>>>> > >>>>> Let's say that import/export if names conflict can be solved in > >>>>> a > >>>>> reasonable way - for example forcing (somehow and without > >>>>> bothering the user too much) a rename of the disk (How would > >>>>> you > >>>>> know if the conflicting name id auto-generated so can be > >>>>> replaced > >>>>> or user provided?, you'll have to resort to > >>>>> non-that-human-look-alike-name) > >>>>> > >>>>> How does it solve the multi-tenancy use case? > >>>>> I'm tenant A, setting up a quorum disk for my two VMs - so I > >>>>> call > >>>>> this disk simply quorum. > >>>>> Now comes tenant B, he is also setting up a quorum disk, so he > >>>>> tries to call his disk quorum > >>>>> > >>>>> But no, > >>>>> He'll get a popup that this name is already taken - bad luck > >>>>> buddy. > >>>>> Now he needs to guess the next available name? Would you build > >>>>> in > >>>>> algorithm to suggest alternatives? > >>>>> Why should tenant B care in the first place that tenant A also > >>>>> wanted to call his disk 'quorum'? > >>>>> > >>>>> Same with the VM name - but that is given for now, though I > >>>>> hope > >>>>> to > >>>>> convince it should change in the future. > >>>>> > >>>>> What I'm trying to say here - infrastructure is for the admin - > >>>>> so > >>>>> you can force uniqueness > >>>>> Resources like, disks and Virtual Machine belong to the end > >>>>> user > >>>>> thus you should let them determine their own names without > >>>>> being > >>>>> restricted by users of the system. > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> People expect names to have significance, and we like it when > >>>>>> they > >>>>>> have both unique and non-unique parts. It's part of our human > >>>>>> heritage. Maybe whales and dolphins don't care. > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> --Charlie > >>>>>> > >>>>>> On Tue, Oct 23, 2012 at 4:36 AM, Simon Grinberg > >>>>>> <[email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>> We need more thoughts here from others, there are two > >>>>>>> different > >>>>>>> approaches on the table and more opinions are welcomed. > >>>>>>> If there are API consumers on this list then your view is > >>>>>>> more > >>>>>>> then > >>>>>>> welcomed. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Simon. > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Simon Grinberg" <[email protected]> > >>>>>>>> To: "Michael Pasternak" <[email protected]> > >>>>>>>> Cc: "engine-devel" <[email protected]> > >>>>>>>> Sent: Monday, October 22, 2012 10:50:02 AM > >>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Michael Pasternak" <[email protected]> > >>>>>>>>> To: "Simon Grinberg" <[email protected]> > >>>>>>>>> Cc: "engine-devel" <[email protected]> > >>>>>>>>> Sent: Monday, October 22, 2012 8:58:25 AM > >>>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name > >>>>>>>>> > >>>>>>>>> On 10/21/2012 06:13 PM, Simon Grinberg wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>> From: "Michael Pasternak" <[email protected]> > >>>>>>>>>>> To: "Simon Grinberg" <[email protected]> > >>>>>>>>>>> Cc: "engine-devel" <[email protected]> > >>>>>>>>>>> Sent: Sunday, October 21, 2012 4:56:33 PM > >>>>>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of name > >>>>>>>>>>> > >>>>>>>>>>> On 10/21/2012 04:15 PM, Simon Grinberg wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>>> From: "Michael Pasternak" <[email protected]> > >>>>>>>>>>>>> To: "Simon Grinberg" <[email protected]> > >>>>>>>>>>>>> Cc: "engine-devel" <[email protected]> > >>>>>>>>>>>>> Sent: Sunday, October 21, 2012 3:48:46 PM > >>>>>>>>>>>>> Subject: Re: [Engine-devel] alias in disk instead of > >>>>>>>>>>>>> name > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 10/21/2012 03:36 PM, Simon Grinberg wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>>>>>> From: "Michael Pasternak" <[email protected]> > >>>>>>>>>>>>>>>> To: "engine-devel" <[email protected]> > >>>>>>>>>>>>>>>> Sent: Sunday, October 21, 2012 12:26:46 PM > >>>>>>>>>>>>>>>> Subject: [Engine-devel] alias in disk instead of > >>>>>>>>>>>>>>>> name > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The problem we caused by using alias in disk instead > >>>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>> name > >>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>> break > >>>>>>>>>>>>>>>> of search-by-name paradigm > >>>>>>>>>>>>>>>> in engine.search dialect, not sure why we do not > >>>>>>>>>>>>>>>> want > >>>>>>>>>>>>>>>> forcing > >>>>>>>>>>>>>>>> disk > >>>>>>>>>>>>>>>> name to be unique [1], > >>>>>>>>>>>>>>>> but lack of "name" in disk search is does not look > >>>>>>>>>>>>>>>> good > >>>>>>>>>>>>>>>> in > >>>>>>>>>>>>>>>> my > >>>>>>>>>>>>>>>> view. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> thoughts? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> [1] can be easily achieved via appropriate > >>>>>>>>>>>>>>>> can-do-action > >>>>>>>>>>>>>>>> verification. > >>>>>>>>>>>>>> Names by definition are not unique IDs, > >>>>>>>>>>>>> > >>>>>>>>>>>>> they do, otherwise /search wasn't effective, remember > >>>>>>>>>>>>> users > >>>>>>>>>>>>> not > >>>>>>>>>>>>> exposed to entity id, all entities fetched by-name, so > >>>>>>>>>>>>> names > >>>>>>>>>>>>> has > >>>>>>>>>>>>> to > >>>>>>>>>>>>> be unique. > >>>>>>>>>>>> > >>>>>>>>>>>> Yap that is what we do with many entities, and it causes > >>>>>>>>>>>> problems. > >>>>>>>>>>>> But with disks it is multiplied > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> thus it should not be enforced. > >>>>>>>>>>>>>> What would be the auto naming conversion to ensure > >>>>>>>>>>>>>> uniqueness > >>>>>>>>>>>>>> with > >>>>>>>>>>>>>> plain text? > >>>>>>>>>>>>> > >>>>>>>>>>>>> not sure i follow, i'll assume you refer here to empty > >>>>>>>>>>>>> name, - > >>>>>>>>>>>>> you > >>>>>>>>>>>>> cannot have an > >>>>>>>>>>>>> entity with no name. > >>>>>>>>>>>> > >>>>>>>>>>>> Well you create a new disk - do we want to enforce the > >>>>>>>>>>>> user > >>>>>>>>>>>> to > >>>>>>>>>>>> provide a unique disk name/alias for every disk he > >>>>>>>>>>>> creates? > >>>>>>>>>>>> This will drive the user crazy. This is important even > >>>>>>>>>>>> for > >>>>>>>>>>>> user > >>>>>>>>>>>> only for floating/shared disks. For any other disks user > >>>>>>>>>>>> does > >>>>>>>>>>>> not > >>>>>>>>>>>> care if it's disk1, hd1, whatever. For these kind of > >>>>>>>>>>>> disk, > >>>>>>>>>>>> it's > >>>>>>>>>>>> just a VM disk and the user does not care if in all VMs > >>>>>>>>>>>> this > >>>>>>>>>>>> is > >>>>>>>>>>>> called disk 1 - so why bother him? > >>>>>>>>>>> > >>>>>>>>>>> from the same reason we have unique > >>>>>>>>>>> clusters/datacenters/networks/templates/etc... > >>>>>>>>>> > >>>>>>>>>> Networks, DataCenter, Clusters, templates - are in order > >>>>>>>>>> of > >>>>>>>>>> magnitude less then the number of disks. > >>>>>>>>>> And you name once and use many. > >>>>>>>>>> > >>>>>>>>>> As for VMs - well it's may take that we should not force > >>>>>>>>>> uniqueness > >>>>>>>>>> either ( you can warn though ) > >>>>>>>>> > >>>>>>>>> you cannot have two vms with same name in same domain ... > >>>>>>>> > >>>>>>>> I didn't say that in a domain you are allowed to have two > >>>>>>>> guests > >>>>>>>> with > >>>>>>>> the same hostname, I've said engine should allow for having > >>>>>>>> duplicate VM names. > >>>>>>>> You are assuming that the VM name is identical to the guest > >>>>>>>> host > >>>>>>>> name. > >>>>>>>> > >>>>>>>> For many this is the case, for other it's just an alias/name > >>>>>>>> given > >>>>>>>> in > >>>>>>>> oVirt. > >>>>>>>> Actually for the cloud, this is mostly going to be the case > >>>>>>>> and > >>>>>>>> worse, you are blocking different tenants from having the > >>>>>>>> same > >>>>>>>> VM > >>>>>>>> name just because you are assuming that VM name = guest > >>>>>>>> hostname. > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> For disks, well number is >= VMs to >>>= VMs > >>>>>>>>>> Name by definition is mostly interesting in many cases > >>>>>>>>>> only > >>>>>>>>>> within > >>>>>>>>>> the VM, and we don't even have a way to correlate disk > >>>>>>>>>> alias > >>>>>>>>>> to > >>>>>>>>>> the internal name in the VM. In many cases as said before, > >>>>>>>>>> a > >>>>>>>>>> user > >>>>>>>>>> won't care about the name/alias if it is always attached > >>>>>>>>>> to > >>>>>>>>>> the > >>>>>>>>>> same VM. A user will rather look the VM and then list it's > >>>>>>>>>> disk. > >>>>>>>>>> So actually I'll be better off with vm1.disk1 vm2.disk2 > >>>>>>>>>> then > >>>>>>>>>> unique name per disk (PS AFAIK) this should be the default > >>>>>>>>>> suggested name by the UI, but then changing the VM name > >>>>>>>>>> will > >>>>>>>>>> break > >>>>>>>>>> this (yes, I know it's not possible ATM, but many people I > >>>>>>>>>> know > >>>>>>>>>> requested for that). > >>>>>>>>>> > >>>>>>>>>> So I as user will prefer that all the disks that created > >>>>>>>>>> from > >>>>>>>>>> a > >>>>>>>>>> template will have the same name as the original template, > >>>>>>>>>> and > >>>>>>>>>> then to be able to search by (vm=name, disk=name) thus I > >>>>>>>>>> can > >>>>>>>>>> access easily the same disk for the VMs. > >>>>>>>>>> > >>>>>>>>>> On the other hand for others, as you've mentioned > >>>>>>>>>> (especially > >>>>>>>>>> for > >>>>>>>>>> floating and shared disk) the name/alias may be of > >>>>>>>>>> importance, > >>>>>>>>>> uniqueness may be very important. > >>>>>>>>> > >>>>>>>>> any disk can become shared. > >>>>>>>> > >>>>>>>> Then when you make it shared then bother to give it a > >>>>>>>> meaningful > >>>>>>>> alias > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> All that I'm saying that we can't force it's not that > >>>>>>>>>> uniqueness > >>>>>>>>>> in > >>>>>>>>>> never desired. > >>>>>>>>> > >>>>>>>>> simon, you missing the point, i was talking about /search, > >>>>>>>>> search is available only at /api/disks (i.e shared disks, > >>>>>>>>> vm/template.disks is > >>>>>>>>> irrelevant to this discussion) > >>>>>>>> > >>>>>>>> Nope I do not, but I think that our perspectives differ. > >>>>>>>> You are looking at it as strictly design issue. You have a > >>>>>>>> collection > >>>>>>>> of entities and you want a human readable search, thus you > >>>>>>>> are > >>>>>>>> trying to force (rightfully) from your point of view a > >>>>>>>> unique > >>>>>>>> alias/name for those. > >>>>>>>> > >>>>>>>> I taking the end user perspective, and user experience > >>>>>>>> 1. Majority of the disks have no meaning outside of a VM > >>>>>>>> scope. > >>>>>>>> 2. There are fractions of the disks that are usually shared > >>>>>>>> (this > >>>>>>>> is > >>>>>>>> the nature of shared disks) > >>>>>>>> 3. There are fractions of floating, most of the floating > >>>>>>>> will > >>>>>>>> be a > >>>>>>>> transient state, while you are moving disks around. > >>>>>>>> > >>>>>>>> What I'm trying to say that forcing a user to provide a > >>>>>>>> unique > >>>>>>>> name > >>>>>>>> per disk is a huge bother. > >>>>>>>> And again in the multi tenancy case, you can't enforce a > >>>>>>>> unique > >>>>>>>> alias > >>>>>>>> in the system. > >>>>>>>> > >>>>>>>> What will you say to the user in the error message? > >>>>>>>> Sorry you can't use this alias since another user that is > >>>>>>>> sharing > >>>>>>>> the > >>>>>>>> system with you already provided that name? And yes we know > >>>>>>>> you > >>>>>>>> can't see that other disk, and it you don't care about the > >>>>>>>> other > >>>>>>>> user, but still you can't use your alias since this is how > >>>>>>>> our > >>>>>>>> platform designed. > >>>>>>>> > >>>>>>>> The meaning is that you must allow a for a more > >>>>>>>> sophisticated > >>>>>>>> search. > >>>>>>>> Yes even in the context of the disks tab. Disks are not > >>>>>>>> really > >>>>>>>> stand > >>>>>>>> alone entities, and if we keep to strict conventions like - > >>>>>>>> in > >>>>>>>> any > >>>>>>>> collection an entity name must be unique, then you are > >>>>>>>> making > >>>>>>>> the > >>>>>>>> system hardly usable for many users. > >>>>>>>> > >>>>>>>> So a search in disks should include other 'properties' (and > >>>>>>>> yes > >>>>>>>> I > >>>>>>>> know those are not disk properties, but this is how a user > >>>>>>>> will > >>>>>>>> look > >>>>>>>> at it) like owner,quota,vm,storage domain, etc. > >>>>>>>> > >>>>>>>> To some up - what should be unique are UUIDs of an entities, > >>>>>>>> and > >>>>>>>> infrastructure entities names (within the same scope) - all > >>>>>>>> the > >>>>>>>> rest > >>>>>>>> must not. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Would you change these on import/export? > >>>>>>>>>>>>> > >>>>>>>>>>>>> would you mind elaborating on this? > >>>>>>>>>>>> > >>>>>>>>>>>> Yes, > >>>>>>>>>>>> > >>>>>>>>>>>> You are already facing a problem when importing VMs that > >>>>>>>>>>>> already > >>>>>>>>>>>> have the same name, now you increasing the problem for > >>>>>>>>>>>> disks > >>>>>>>>>>>> that > >>>>>>>>>>>> have the same alias. for same name we force clone if you > >>>>>>>>>>>> want > >>>>>>>>>>>> to > >>>>>>>>>>>> import. Why for clone just because of a disk alias (this > >>>>>>>>>>>> implies > >>>>>>>>>>>> collapse snapshots ATM) or even bother the user with > >>>>>>>>>>>> renaming > >>>>>>>>>>>> disks that he does not care about the name so he just > >>>>>>>>>>>> gave > >>>>>>>>>>>> disk > >>>>>>>>>>>> 1, > >>>>>>>>>>>> 2, 3 and so on? > >>>>>>>>>>> > >>>>>>>>>>> i see your point, but then we leave no option for the > >>>>>>>>>>> user > >>>>>>>>>>> to > >>>>>>>>>>> locate > >>>>>>>>>>> the disk, > >>>>>>>>>>> simply because he doesn't have unique identifier, > >>>>>>>>>>> > >>>>>>>>>>> just imagine user A creating disk and calling it X, > >>>>>>>>>>> then user B creating disk and calling it X, they on > >>>>>>>>>>> different > >>>>>>>>>>> domains etc., and now both want to use disk X, > >>>>>>>>>>> > >>>>>>>>>>> how they can figure out which one to pick?, by SD, by > >>>>>>>>>>> size? > >>>>>>>>>>> agree > >>>>>>>>>>> this is doesn't look well..., even more than that - > >>>>>>>>>>> someone > >>>>>>>>>>> may > >>>>>>>>>>> call > >>>>>>>>>>> this "bad design"... > >>>>>>>>>> > >>>>>>>>>> This is why the search should accept more then the name. > >>>>>>>>>> Example (vm=name, disk=name/alias) > >>>>>>>>>> Example (dc=name, disk=name/alias) > >>>>>>>>>> Example (sd=name, disk=name/alias) > >>>>>>>>> > >>>>>>>>> it's not about accepting both name/alias, it's about > >>>>>>>>> missing > >>>>>>>>> ability > >>>>>>>>> to identify your resource in collection. > >>>>>>>>> > >>>>>>>>>> For floating/shared on the same SD/DC/VM I would suggest a > >>>>>>>>>> warning > >>>>>>>>>> if there is a duplicate in the system - not enforcement. > >>>>>>>>> > >>>>>>>>> ok, lets assume we WARN user that his disk's name is not > >>>>>>>>> unique, > >>>>>>>>> how > >>>>>>>>> user will pick the unique name? > >>>>>>>>> implementing own code checking if new name (he wants to > >>>>>>>>> use) > >>>>>>>>> is > >>>>>>>>> unique or not? > >>>>>>>>> > >>>>>>>>> - this is business logic, not user's prerogative. > >>>>>>>>> > >>>>>>>>>> There is a difference between best practice and being > >>>>>>>>>> enforcing > >>>>>>>>>> up > >>>>>>>>>> to the level that it annoys some of the users. > >>>>>>>>> > >>>>>>>>> simon, when you register to email, you have to try N times > >>>>>>>>> till > >>>>>>>>> you > >>>>>>>>> find unique username, > >>>>>>>>> is it convenient? absolutely NO, is it annoying? YES, but > >>>>>>>>> you > >>>>>>>>> forced > >>>>>>>>> doing that so > >>>>>>>>> system will be able to identify you, > >>>>>>>>> > >>>>>>>>> it's no different in any way, good software protects > >>>>>>>>> user/itself > >>>>>>>>> even > >>>>>>>>> in cost of convenience, > >>>>>>>>> > >>>>>>>>> bottom line > >>>>>>>>> =========== > >>>>>>>>> > >>>>>>>>> - i think as long as disk not shared/floating it can have > >>>>>>>>> any > >>>>>>>>> name > >>>>>>>>> - in a minute disk designation changed to shared, name > >>>>>>>>> uniqueness > >>>>>>>>> should be forced (by the engine) > >>>>>>>>> - when importing vm with shared disks, name uniqueness > >>>>>>>>> should > >>>>>>>>> be > >>>>>>>>> forced > >>>>>>>>> - when creating vm from template with shared disk, name > >>>>>>>>> uniqueness > >>>>>>>>> should be forced > >>>>>>>>> - alias should be changed back to name (in sake of > >>>>>>>>> consistency) > >>>>>>>>> - /api/disks collection should support searching disks by > >>>>>>>>> name > >>>>>>>>> (in > >>>>>>>>> sake of consistency) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> thoughts? > >>>>>>>> > >>>>>>>> Please look at the previous comment, that just can't work in > >>>>>>>> the > >>>>>>>> multi-tenancy case. > >>>>>>>> Name should not be unique, the warning is for the admin > >>>>>>>> only, > >>>>>>>> from > >>>>>>>> the user portal a warning should be issues only if the user > >>>>>>>> provides > >>>>>>>> same name twice. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> Michael Pasternak > >>>>>>>>>>> RedHat, ENG-Virtualization R&D > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> Engine-devel mailing list > >>>>>>>>>>> [email protected] > >>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> Michael Pasternak > >>>>>>>>> RedHat, ENG-Virtualization R&D > >>>>>>>>> _______________________________________________ > >>>>>>>>> Engine-devel mailing list > >>>>>>>>> [email protected] > >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>>>>> > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Engine-devel mailing list > >>>>>>> [email protected] > >>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>>>>> > >>>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> [email protected] > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> [email protected] > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
