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 <[email protected]> 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 > > 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 <[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 _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
