Re: [Engine-devel] Floating Disk feature description
On 02/01/2012 07:04 PM, Daniel Erez wrote: Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk Best Regards, Daniel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) 1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. 2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Y. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] oVirt upstream meeting - setup networks MOM
Setup networks feature have been introduced and few question rose: mgoldboi asked to give attention to error handling or reporting AI - need to make sure I have proper error codes from VDSM on validation,failure in committing the new topology etc... acathrew raised an issue of known configuration that won't work e.g specific bonding over bridge that should fail AI - gather those improper configuratations ( Andy pls reply with the exact details if you have them) lpeer asked to set a UI sync meeting lead by them - done Thanks, Roy ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Simplifying our POJOs
- Original Message - From: Livnat Peer lp...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, February 1, 2012 8:16:34 AM Subject: Re: [Engine-devel] Simplifying our POJOs On 01/02/12 09:13, Yair Zaslavsky wrote: On 02/01/2012 08:59 AM, Livnat Peer wrote: On 01/02/12 08:03, Mike Kolesnik wrote: - Original Message - On 01/31/2012 12:45 PM, Doron Fediuck wrote: On 31/01/12 12:39, Livnat Peer wrote: On 31/01/12 12:02, Mike Kolesnik wrote: Hi, Today many POJO http://en.wikipedia.org/wiki/Plain_Old_Java_Objects are used throughout the system to convey data: * Parameters - To send data to commands. * Business Entities - To transfer data in the parameters to/from the DB. These POJOs are (usually) very verbose and full of boilerplate code http://en.wikipedia.org/wiki/Boilerplate_code. This, in turn, reduces their readability and maintainability for a couple of reasons (that I can think of): * It's hard to know what does what: o Who participates in equals/hashCode? o What fields are printed in toString? * Consistency is problematic: o A field may be part of equals but not hashCode, or vice versa. o This breaks the Object.hashCode() http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode%28%29 contract! * Adding/Removing fields take more time since you need to synchronize the change to all boilerplate methods. o Again, we're facing the consistency problem. * These simple classes tend to be very long and not very readable. * Boilerplate code makes it harder to find out which methods *don't* behave the default way. * Javadoc, if existent, is usually meaningless (but you might see some banal documentation that doesn't add any real value). * Our existing classes are not up to standard! So what can be done to remedy the situation? We could, of course, try to simplify the classes as much as we can and maybe address some of the issues. This won't alleviate the boilerplate code problem altogether, though. We could write annotations to do some of the things for us automatically. The easiest approach would be runtime-based, and would hinder performance. This also means we need to maintain this infrastructure and all the implications of such a decision. Luckily, there is a much easier solution: Someone else already did it! Check out Project Lombok: http://projectlombok.org What Lombok gives us, among some other things, is a way to greatly simplify our POJOs by using annotations to get the boilerplate code automatically generated. This means we get the benefit of annotations which would simplify the code a whole lot, while not imposing a performance cost (since the boilerplate code is generated during compilation). However, it's also possible to create the methods yourself if you want them to behave differently. Outside the POJO itself, you would see it as you would always see it. So what are the downsides to this approach? * First of all, Lombok provides also some other capabilities which I'm not sure are required/wanted at this time. o That's why I propose we use it for commons project, and make use of it's POJO-related annotations ONLY. * There might be a problem debugging the code since it's auto-generated. o I think this is rather negligible, since usually you don't debug POJOs anyway. * There might be a problem if the auto-generated code throws an Exception. o As before, I'm rather sure this is an edge-case which we usually won't hit (if at all). Even given these possible downsides, I think that we would benefit greatly if we would introduce this library. If you have any questions, you're welcome to study out the project site which has very thorough documentation: http://projectlombok.org Your thoughts on the matter? - I think an example of before/after pojo would help demonstrating how good the framework is. - Would it work when adding JPA annotations? I suspect that yes (needs to be checked) Will it work with GWT (if we create new business entity that needs to be exposed to GWT guys) ? As it is stated on the site, it supports GWT. Since this package is required only during compile time it is relatively easy to push it in. Need to make sure it is working nice with debugging and give it a try. I like this package, +1 from me. Another issue to check - (I'm sure it does, but still) - Are empty CTORs generated as well? (There is a long debate for POJOs that contain X fields whether they should have an empty
Re: [Engine-devel] oVirt upstream meeting : VM Version
On 02/02/2012 08:46 AM, Itamar Heim wrote: On 02/02/2012 02:56 AM, Eli Mesika wrote: Hi We had discussed today the Stable Device Addresses feature One of the questions arose from the meeting (and actually defined as an open issue in the feature wiki) is: What happens to a 3.1 VM running on 3.1 Cluster when it is moved to a 3.0 cluster. We encountered that VM may lose some configuration data but also may be corrupted. From that point we got to the conclusion that we have somehow to maintain a VM Version that will allow us to What do you mean by VM version? Is that the guest hardware abstraction version (which is the kvm hypervisor release + the '-M' flag for compatibility)? I think its the above + the meta data /devices you keep for it. block moving VM if it's version is not fully supported compatible with the target Cluster. One idea for getting the VM version is the OVF which actually holds inside its header OvfVersion. The question is , is the OVF good enough for all our needs or should we persist that else (for example in DB) Also, any other issues/difficulties we may encounter implementing and storing VM version. Keep in mind that this is a new feature that impacts the Stable Device Addresses feature but may be useful/relevant for other features as well. Can you give some examples which will cause an issue moving a VM from a 3.1 cluster to a 3.0 one? ___ 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
Re: [Engine-devel] oVirt upstream meeting : VM Version
- Original Message - On 02/02/2012 08:46 AM, Itamar Heim wrote: On 02/02/2012 02:56 AM, Eli Mesika wrote: Hi We had discussed today the Stable Device Addresses feature One of the questions arose from the meeting (and actually defined as an open issue in the feature wiki) is: What happens to a 3.1 VM running on 3.1 Cluster when it is moved to a 3.0 cluster. We encountered that VM may lose some configuration data but also may be corrupted. From that point we got to the conclusion that we have somehow to maintain a VM Version that will allow us to What do you mean by VM version? Is that the guest hardware abstraction version (which is the kvm hypervisor release + the '-M' flag for compatibility)? I think its the above + the meta data /devices you keep for it. Correct. There are several issues here: 1. you loose the stable device addresses (no point in keeping the data in the db as the next time the VM is run the devices can get different addresses) 2. If you move the VM to an older cluster where the hosts don't support the VM's compatibility mode (-M) then the VM would be started with different virtual hardware which might cause problems 3. Once we support s4 then running the VM again with different hardware might be even more problematic than just running it from shutdown (e.g. once we have a balloon device with memory assigned to it which suddenly disappears, what would happen to the VM?) 4. Same applies for migrate to file, but this can be dealt with by not allowing to move a VM between incompatible clusters in case it has a migrate to file state (or delete the file). A side note - I'm not sure if exporting a VM also exports the state file after migrate to file? if not then probably it should... I'm sure there are additional scenarios we're not thinking of. block moving VM if it's version is not fully supported compatible with the target Cluster. One idea for getting the VM version is the OVF which actually holds inside its header OvfVersion. The question is , is the OVF good enough for all our needs or should we persist that else (for example in DB) Also, any other issues/difficulties we may encounter implementing and storing VM version. Keep in mind that this is a new feature that impacts the Stable Device Addresses feature but may be useful/relevant for other features as well. Can you give some examples which will cause an issue moving a VM from a 3.1 cluster to a 3.0 one? ___ 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
Re: [Engine-devel] Floating Disk feature description
On 02/02/2012 12:25 PM, Daniel Erez wrote: - Original Message - From: Itamar Heimih...@redhat.com To: Daniel Erezde...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 9:08:56 AM Subject: Re: [Engine-devel] Floating Disk feature description On 02/01/2012 07:04 PM, Daniel Erez wrote: Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk some questions/notes: 1. why do you need a floating/not floating state? isn't a disk floating if it was detached from all VMs? or is that only a helper property to optimize lookups? Yes, the floating state is an indication whether the disk is attached to any VM. It's not a persistent property on the disk, but rather a DB view calculated value. 2. you mention fields of disks (Floating/Shared/Managed) 2.1 do we have a definition of Managed disk somewhere? I assume unmanaged would be a direct LUN, but i think we need a better terminology here. Indeed, we're looking for a better teminology. Suggestions are welcomed... 2.2 same goes for floating actually... do we really want to tell the user the disk is floating? I guess suggestion welcome for a better name. unattached has been mentioned once as an alternative. Google says the world prefers 'detached': ~196M entries vs. ~5.7M entries for 'unattached'. Y. 2.3 finally, for shared, maybe more interesting is number of VMs the disk is connected to, rather than just a boolean (though i assume this increases complexity for calculation, or redundancy of data, and not a big issue) Actually, as part of the Shared raw disk feature, we do want to display the number of VMs (and probably a list too) the disk is connected to - in the 'Disks' sub-tab (under VMs main tab). Hence, it might be rather simple to show that number also in the Disks main tab (the list of VMs will be displayed under VMs sub-tab). 3. List of Storage Domains in which the selected Disk resides. this is only relevant for template disks? Yes, it's only for cloned templates. maybe consider splitting the main grid if looking at tempalte disks or vm disks, and show for vm disks the storage domain in main grid? maybe start with vm disks only and not consider template disks so much? Miki? 4. Templates (visible for disks that reside in templates) List of Templates to which the selected Disk is attached. same comment as above of maybe consider only vm disks for now. and also a question - how can a template disk belong to more than a single template? Yes, for now, a template disk cannot belong to more than a single template. However, won't we like to have a shared disk for a template in the future? which again hints for a template disk you would want another view, with the template name in the main grid 5. Tree: 'Resources' vs. 'free disks' while i understand why separating them - naming is very confusing. maybe a single node in tree and a way to filter the search from the right side grid in some manner for known lookups (relevant to other main tabs as well?) For now, we've agreed that sorting abilities in columns is needed for easing the orientation. 6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me. or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase. I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM) Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user. 7. related features - data ware house may be affected by disks being unattached, or shared between multiple disks. ___ 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
Re: [Engine-devel] Floating Disk feature description
- Original Message - From: Yaniv Kaul yk...@redhat.com To: Daniel Erez de...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description On 02/01/2012 07:04 PM, Daniel Erez wrote: Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk Best Regards, Daniel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) Disk and Image are the same (Disk is the RHEV-M term for VDSM's Image). Both of them means: the collection of volumes (or, DiskImages, in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same] 1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk. Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...) Maybe we can use some other attribute for identification? 2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc. Y. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] in the UI - missing list of storage domains in detach modal
In the Data Center tab, if you select a storage domain to detach, a modal dialog box pops up saying Are you sure you want to Detach the following storage(s)?. Below this there are no storage domains listed. I would suggest either listing them or changing the word 'following' to 'selected' ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Floating Disk feature description
On 02/02/2012 12:25 PM, Daniel Erez wrote: ... 6. permissions not available for disks? at all? what do you mean power user would be able to attach them by their type? does it mean they can associate any shared disk in the system? I hope i'm misunderstanding, as doesn't make sense to me. or is this caveat specific to the user portal and not the admin? not allowing creating a floating disk from user portal is not a problem in my view for this phase. I assume anyone can add a disk on a storage domain they have quota to. who can edit a disk? remove a disk? attach disk to VM (which gives them ability to edit the disk) (attach disk to VM obviously requires permission on both disk and VM) Since we won't support permissions on disks entities (at first stage), as a compromise for the power user portal, we've agreed to simply hide floating non shared disks from the user. I still think we won't find a decent way to model this without permissions, regardless of the power user portal. we'll hit too many problems. I'll look into this a bit more. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Floating Disk feature description
- Original Message - From: Yaniv Kaul yk...@redhat.com Sent: Thursday, February 2, 2012 1:43:58 PM On 02/02/2012 01:35 PM, Daniel Erez wrote: - Original Message - From: Yaniv Kaulyk...@redhat.com To: Daniel Erezde...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, February 2, 2012 10:27:06 AM Subject: Re: [Engine-devel] Floating Disk feature description On 02/01/2012 07:04 PM, Daniel Erez wrote: Hi, Floating Disk feature description Wiki page: http://www.ovirt.org/wiki/Features/DetailedFloatingDisk Best Regards, Daniel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel 0. Is it a floating disk or a floating image? would be nice to use the same terminology for all projects, where possible (http://www.ovirt.org/wiki/Vdsm_Storage_Terminology#Image) Disk and Image are the same (Disk is the RHEV-M term for VDSM's Image). Both of them means: the collection of volumes (or, DiskImages, in RHEV-M terminology) that comprise the full disk. We have no problem using either terminology, however might be confusing either way. [BTW, a floating disk can't conatin snapshots - so it doesn't really matter if you are talking about disk, image, diskImage or volume - they are all the same] If they are the same, then please use the term 'image'. As I said - no technical problem doing that, however in the engine we use the term Disk and the current name of the relevant VMs sub-tab is Disks and the name of the new main tab would be Disks (or Virtual Disks), etc. - so it will be strange to call the feature floating image when floating is going to be column in a GUI grid titled Disks. I assume that you can also find explanations of why using the term Disk is confusing and Image is better; I am just genuinely not sure what is less confusing. And it looks like the feature is 'floating single-volume image' . I wonder if the limitation is really an issue or not. Can't think of a real use case it would be, but here's an imaginary one: before attaching it to a VM (or after and before running), I'd take a snapshot, then run the VM, do whatever, and revert before/after detaching, so the floating would go back to its original state. 1. I don't see why a disk name should be unique. I don't think it's enforceable under any normal circumstances: If user A decided to call his disk 'system', user B who is completely unaware of A cannot call his disk 'system' ? It should be unique at some level, but not system-wide. The enforcement for uniqueness has been suggested for avoiding a list of duplicate named disks in the Disks main tab and for identifying a specific disk. Understood, but it's not good enough. Need to solve this, as it's not practical to ask me not to share a property with you - which both us do not really share. Probelm is that any disk theoretically can be floating, so you cannot differentiate between the disks using the VM name to which it is attached, for example (moreover, some of the disks in the system are shared, so which VM name will you use?...) The fact VM names are unique is also an annoying, problematic issue, but I imagine there are less VMs than disks, and most are going to be FQDN based anyway. 'system' and 'data' are quite common names for disks, whereas VM names might be more original. Anyway, both don't scale. Maybe we can use some other attribute for identification? The real identification can be done via the serial number, no harm in displaying that cryptic ID in the UI. Makes us look professional. Of course, it makes more sense to use the volume UUID. May come handy in locating it physically on disk, if it exists. 2. I'm not sure I understand why exporting a floating disk is 'not supported'. In the current design? implementation? ever? Currently, Export is done in a VM/Template level. Support in export/import (floating) disks is a new functionality which requires additional thinking/design/etc. Right, so lets add 'currently not supported'. Y. Y. ___ 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] multiple destinations for disks in create/import template?
Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template? Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them. If so, what would the UI look for this? It would require the backend to receive something that looks like MapDiskImage, ListStorageDomain. thoughts? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] multiple destinations for disks in create/import template?
On 02/02/2012 11:19 AM, Maor wrote: On 02/02/2012 06:01 PM, Jon Choate wrote: Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template? Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them. If so, what would the UI look for this? It would require the backend to receive something that looks like MapDiskImage, ListStorageDomain. thoughts? I think something that should be taken in consider if doing that, is that the VM which the template is created from will stay in image lock much longer. Not necessarily. Once we get one copy of each disk down, we can release the vm and use these copies as the source of the other copies. Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all. Yes, the failure cases need to be considered. I would think that as long as one copy of each disk can be created then the template should persist. If we can't create a copy of each disk then we need to roll back and not create the template. But in this approach how do we convey the list of failures back to the user? ___ 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
Re: [Engine-devel] multiple destinations for disks in create/import template?
On 02/02/2012 07:16 PM, Jon Choate wrote: On 02/02/2012 11:19 AM, Maor wrote: On 02/02/2012 06:01 PM, Jon Choate wrote: Given the changes for multiple storage domains, do we want to allow a user to specify multiple storage domains per disk when creating or importing a template? Otherwise the user will need to use the copy(clone) template disk afterwards to create the copies of the storage domain disks where they want them. If so, what would the UI look for this? It would require the backend to receive something that looks like MapDiskImage, ListStorageDomain. thoughts? I think something that should be taken in consider if doing that, is that the VM which the template is created from will stay in image lock much longer. Not necessarily. Once we get one copy of each disk down, we can release the vm and use these copies as the source of the other copies. Also what would be the desired behaviour if few of storage domains would not be available, and will fail. (right now, if counting on the AsyncTaskManager mechanism, the all operation of create template will be rolled back, and the template would not be created at all. Yes, the failure cases need to be considered. I would think that as long as one copy of each disk can be created then the template should persist. If we can't create a copy of each disk then we need to roll back and not create the template. But in this approach how do we convey the list of failures back to the user? how about we start with KISS to see everything works post all changes going around, and later can add support for multiple clones (parallel or serial)? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
