Re: [Engine-devel] Disk BE very small refactoring
- Original Message - From: Vered Volansky ve...@redhat.com To: Maor Lipchuk mlipc...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Omer Frenkel ofren...@redhat.com, Mike Kolesnik mkole...@redhat.com, Allon Mureinik amure...@redhat.com, Daniel Erez de...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 8:40:38 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I had a problem, didn't see all the replies till now. I'll add some more info as to why we want to do this like we do. It all started from adding the readOnly property to disks. It should have been handled like plugged is handled, yet plugged is a hack, and if we don't change that now, we'll only keep on adding unreasonable hacks. please explain why you think plugged is a hack? what is wrong with it? So from the start - Disk currently: - Sometimes represents a disk in a vm context and sometimes not. - Holds plugged property, which is only relevant when a disk is in a vm context, which already suggests this is not the natural place for it. - Also holds bootable and interface, which cause limitations of use, but are not so obviously related to the relationship between Disk and Vm as plugged. - Can be shared between several vm's, to some plugged and to some not plugged. - Will soon be optionally RO in one VM and RW in another, which is exactly the same as plugged, and therefore plugged issue should be fixed first. Every column in that shows a disk in the UI receives a Disk entity, and show its contents, while plugged/unplugged is ignored when not in a VM context. The way things are now, using a VmDevice in the where we need it to show plug status, we'll also have to use it in all other columns, which is irrelevant and just totally not related. So using VmDevice in UI is a no go. The UI is the main limitation forcing us to use something that extends Disk, and what I described below is the easiest thing to implement in the time restrictions we have without changing the entire system. I think this answers all the questions not already answered by others. Regarding Maor suggestion - might be a good idea, but not in this scope or time-frame. If there is any other/unanswered issue or objection to the design change please share. I appreciate your inputs, Vered sorry i didnt understand why the current disk object isnt good enough, you get a disk, some of its properties are valid only in some situations. i think its easier to use instead of couple of different objects representing the same entity in different situations. - Original Message - From: Maor Lipchuk mlipc...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 1:49:46 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I think the main problem is that we abuse the business entity to act as an O/R mapping class to the DB and also to be used as a business entity for presentation purposes. I understand how Yair thought isPlugged could be fetched from vmDevice, this is a confusing design, and it is just one example and more to come. I suggest that if we already thinking of changing the class hierarchy, we can start by implementing a package for presentation classes for transient classes such as this instead enforcing complex hierarchy. The query class will fetch all the data from the DB and initialized the transient class and send it to the client. I think it could be a good start and will solve many issues we might encounter in the future. Regards, Maor On 05/28/2013 11:24 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, May 27, 2013 6:22:58 PM Subject: Re: [Engine-devel] Disk BE very small refactoring Vered, VmDevice has isPlugged field, Why not have somehow in your inheritence (either Disk or a subclass) a field : VmDevice device disk id is the device id, no need for field to represent the relation. the combination of disk-id and a specific entity (vm/template) will get you the other info and have isPlugged method called device.isPlugged() ? Then you can also add the readOnly property which is not represented at VmDevice. Does this sound logical to you? - Original Message - From: Vered Volansky ve...@redhat.com To: engine-devel@ovirt.org Sent: Monday, May 27, 2013 6:18:58 PM Subject: [Engine-devel] Disk BE very small refactoring Hi All, Please express your opinion if you have any - Currently Disk BE has a plugged property, which should be a property of the relationship between vm(or template) and a disk. I plan to remove this property from the Disk entity, and add new entity, called DeviceDisk. This should
Re: [Engine-devel] oVirt Scheduler API Design
- Original Message - From: Gilad Chaplik gchap...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 5:34:11 PM Subject: [Engine-devel] oVirt Scheduler API Design Hi all, Attached links for oVirt Scheduler API design wiki page. High level overview: http://www.ovirt.org/Features/oVirtScheduler Detailed design: http://www.ovirt.org/Features/oVirtSchedulerAPI You are more than welcome to share you thoughts. Thanks, Gilad. Adding to users' list for all those asking about the new oVirt scheduling features. Feel free to review and feedback. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] setup ovirt-engine on graphic or web mode
Hi,All so far as I know, we use engine-setup command to setup ovirt engine. engine-setup coded in python which run in linux shell.it is not convenience to some people that not be familiar with Linux OS. Currently,Does oVirt project has some tools or method that support to setup engine on graphic or web mode? If no, Is there any plan or schedule to support this feature? Thanks and Best Regards. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Disk BE very small refactoring
- Original Message - From: Omer Frenkel ofren...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, May 30, 2013 11:29:40 AM Subject: Re: [Engine-devel] Disk BE very small refactoring - Original Message - From: Vered Volansky ve...@redhat.com To: Maor Lipchuk mlipc...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Omer Frenkel ofren...@redhat.com, Mike Kolesnik mkole...@redhat.com, Allon Mureinik amure...@redhat.com, Daniel Erez de...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 8:40:38 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I had a problem, didn't see all the replies till now. I'll add some more info as to why we want to do this like we do. It all started from adding the readOnly property to disks. It should have been handled like plugged is handled, yet plugged is a hack, and if we don't change that now, we'll only keep on adding unreasonable hacks. please explain why you think plugged is a hack? what is wrong with it? You have is_readonly and is_plugged in the device level , this is far from being a hack and managed in the correct place since both may apply to multiple device types (disk, nics ) So from the start - Disk currently: - Sometimes represents a disk in a vm context and sometimes not. - Holds plugged property, which is only relevant when a disk is in a vm context, which already suggests this is not the natural place for it. - Also holds bootable and interface, which cause limitations of use, but are not so obviously related to the relationship between Disk and Vm as plugged. - Can be shared between several vm's, to some plugged and to some not plugged. - Will soon be optionally RO in one VM and RW in another, which is exactly the same as plugged, and therefore plugged issue should be fixed first. Every column in that shows a disk in the UI receives a Disk entity, and show its contents, while plugged/unplugged is ignored when not in a VM context. The way things are now, using a VmDevice in the where we need it to show plug status, we'll also have to use it in all other columns, which is irrelevant and just totally not related. So using VmDevice in UI is a no go. The UI is the main limitation forcing us to use something that extends Disk, and what I described below is the easiest thing to implement in the time restrictions we have without changing the entire system. I think this answers all the questions not already answered by others. Regarding Maor suggestion - might be a good idea, but not in this scope or time-frame. If there is any other/unanswered issue or objection to the design change please share. I appreciate your inputs, Vered sorry i didnt understand why the current disk object isnt good enough, you get a disk, some of its properties are valid only in some situations. i think its easier to use instead of couple of different objects representing the same entity in different situations. I totally agree with Omer, please specify what is impossible or hard to achieve with the current schema - Original Message - From: Maor Lipchuk mlipc...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Tuesday, May 28, 2013 1:49:46 PM Subject: Re: [Engine-devel] Disk BE very small refactoring I think the main problem is that we abuse the business entity to act as an O/R mapping class to the DB and also to be used as a business entity for presentation purposes. I understand how Yair thought isPlugged could be fetched from vmDevice, this is a confusing design, and it is just one example and more to come. I suggest that if we already thinking of changing the class hierarchy, we can start by implementing a package for presentation classes for transient classes such as this instead enforcing complex hierarchy. The query class will fetch all the data from the DB and initialized the transient class and send it to the client. I think it could be a good start and will solve many issues we might encounter in the future. Regards, Maor On 05/28/2013 11:24 AM, Omer Frenkel wrote: - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Vered Volansky ve...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, May 27, 2013 6:22:58 PM Subject: Re: [Engine-devel] Disk BE very small refactoring Vered, VmDevice has isPlugged field, Why not have somehow in your inheritence (either Disk or a subclass) a field : VmDevice device disk id is the device id, no need for field to represent the relation. the combination of disk-id and a specific entity (vm/template) will get you the other info and have isPlugged method called device.isPlugged() ?
Re: [Engine-devel] [vdsm] Proposal VDSM = Engine Data Statistics Retrieval Optimization
Hi, I finally have an update for the proposal ready, after some thinking and throwing some ideas around with colleagues we came to the conclusion that the best approach might be as followed (without having dynamic return values) I have set up some test engine with 'FakeVDSM' and I am tracking the data sent. The system has 250 hosts and about 1 VMs running. I have captured 1.3 GiB TCP data within about 20 minutes only from the communication between the engine and the fake VDSM host. In a frame of 23 minutes I have captured 13.560 getAllVMStats and getAllVdsStats calls, and 67827 calls to list. getAllVmStats replies have produced in that time about 510MiB of data transmitted to the engine. This proposal below would reduce the overall amount of data significantly and we're preparing to work on a prototype for the engine backend as well so we can backup this statement with hard numbers. Here's the proposal. VDSM = Engine data retrieval optimization Motivation: Currently the oVirt Engine is polling a lot of data from VDSM every 15 seconds. This should be optimized and the amount of data requested should be more specific. For each VM the data currently contains much more information than actually needed which blows up the size of the XML content quite big. We could optimize this by splitting the reply on the getVmStats based on the needs of the engine into different requests. For this reason Omer Frenkel and me have split up the data into parts based on their usage. Changes New Verbs getAllRuntimeStats Get runtime information of all VMs Returns for each VM a map with UUID and a value of: * *@cpuSys* Ratio of CPU time spent by qemu on other than guest time * *@cpuUser* Ratio of CPU time spent by the guest VM * *@memUsage* The percent of memory in use by the guest * *@elapsedTime* The number of seconds that the VM has been running * *@status* The current status of the given VM * *@statsAge* The age of these statistics in seconds * *@hashes* Hashes of several statistics and information around VMs Hashes consists of: * *@info* Hash for VmConfInfo data * *@config* Hash of the VM configuration XML * *@status* Hash of the VmStatusInfo data * *@guestDetails* Hash of the VmGuestDetails data getStatus Get status information about a list of VMs Parameters: * *@vmIDs* a list of UUIDs for VMs to query Returns for each VM in vmIDs a map with UUID and a value of: * *timeOffset* The time difference from host to the VM in seconds * *monitorResponse* Indicates if the qemu monitor is responsive * *clientIp* The IP address of the client connected to the display * *username* the username associated with the current session * *session* The current state of user interaction with the VM * *guestIPs* A space separated string of assigned IPv4 addresses * *pauseCode* Indicates the reason a VM has been paused getConfInfo Get configuration information about a list of VMs Parameters: * *@vmIDs* a list of UUIDs for VMs to query Returns for each VM in vmIDs a map with UUID and a value of: * *acpiEnable* Indicates if ACPI is enabled inside the VM * *displayPort* The port in use for unencrypted display data * *displaySecurePort* The port in use for encrypted display data * *displayType* The type of display in use * *displayIp* The IP address to use for accessing the VM display * *pid* The process ID of the underlying qemu process * *vmType* The type of VM * *kvmEnable* Indicates if KVM hardware acceleration is enabled * *cdrom* /*optional*/ The path to an ISO image used in the VM's CD-ROM device * *boot* /*optional*/ An alias for the type of device used to boot the VM getAllDeviceStats VM device statistics containing information for getting statistics and SLA information Returns for each VM a map with UUID and a value of: * *memoryStats* Memory statistics as reported by the guest agent * *balloonInfo* Guest memory balloon information * *disksUsage* Info about mounted filesystems as reported by the agent * *network* Network bandwidth/utilization statistics * *disks* Disk bandwidth/utilization statistics getGuestDetails Get details from the guest OS from a list of VMs Parameters: * *@vmIDs* a list of UUIDs for VMs to query Returns for each VM in vmIDs a map with UUID and a value of: * *appsList* A list of installed applications with their versions * *netIfaces* Network device address info as reported by the agent Usage Currently the engine is requesting currently every 3 seconds the vm list from each vdsm host and every 15 seconds all the data mentioned above for all VMs. The change would be as follows: The engine requests every 3 seconds getAllRuntimeStats from vdsm which will give the engine the most used data. If the engine has a mismatch of the hashes returned by getAllRuntimeStats it should request the data changed. if hashes.info changed =
[Engine-devel] cannot execute command in the class of InitVdsOnUpCommand
Hi, We suppose when one VDS is added into cluster, executeCommand method in InitVdsOnUpCommand.java will be invoked, so, some logic will be checked there. But per our experiment, this is depended on what we actually did. Here are some cases: 1. when reboot VDS, the logic in executeCommand will be invoked. 2. when re-deploy engine, the logic in executeCommand will be invoked. 3. when we add a new VDS (vdsm is running) into cluster, the logic in executeCommand will not be invoked. What we expect is the logic will also be invoked in the third case, but why it's not invoked? What's behind all of these? Best Regards, Dave Chen ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] static header only in VM dialog?
Sorry to join the thread late. The long weekend was followed by a conference for the UX team and hence the delay. See comments below inline - - Original Message - From: Einav Cohen eco...@redhat.com To: Daniel Erez de...@redhat.com Cc: Eldan Hildesheim i...@eldanet.com, engine-devel engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Malini Rao m...@redhat.com, Tomas Jelinek tjeli...@redhat.com Sent: Wednesday, May 29, 2013 8:21:30 AM Subject: Re: [Engine-devel] static header only in VM dialog? - Original Message - From: Daniel Erez de...@redhat.com Sent: Wednesday, May 29, 2013 1:36:03 AM - Original Message - From: Einav Cohen eco...@redhat.com To: Daniel Erez de...@redhat.com, Malini Rao m...@redhat.com, Eldan Hildesheim i...@eldanet.com, Eldan Hildesheim ehild...@redhat.com, Tomas Jelinek tjeli...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, May 29, 2013 2:30:09 AM Subject: Re: static header only in VM dialog? - Original Message - From: Daniel Erez de...@redhat.com Sent: Tuesday, May 28, 2013 6:18:20 PM - Original Message - From: Einav Cohen eco...@redhat.com To: Malini Rao m...@redhat.com, Eldan Hildesheim i...@eldanet.com, Eldan Hildesheim ehild...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, de...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, May 29, 2013 12:53:47 AM Subject: static header only in VM dialog? when reviewing the code for the redesign of vm related dialogs, Daniel has raised an interesting question: Why do we want the static header only in VM dialog? (I assume that he refers to the top section of the New VM dialog as seen in [1], which contains the DC/Cluster, Quota, etc information, and is static, i.e., it is always displayed, regardless of the selected side-tab within the dialog) I agree with what Daniel is implying here: for consistency, we would probably want to introduce this static header to other dialogs, at least to the ones that also contain side-tabs in which it makes sense to turn the header to static [e.g. New Host (which contains a DC + Cluster header) - see http://oi39.tinypic.com/2z84xnp.jpg, New Cluster (which contains a DC header) - see http://oi40.tinypic.com/2vmyj2x.jpg] MR: Consistency is important but we need to make only UIs with similar purposes consistent and not aim for consistency where it will not serve a real Usability goal or worse get in the way. See next comment for more on UX motivation for this static panel for new VM creation where it was originally proposed. [I assume, of course, that all the VM-like dialogs (e.g. New/Edit VM-Pool) will also have static headers - I don't know if the patch already takes care of that or not] Thoughts? [@Daniel - if you had something else in mind, and/or other dialogs in mind - please feel free to add/amend/etc] MR: Before we proliferate this UI paradigm into other areas, let us look at the list of dialogs where we are considering this against the primary UX motivations with which this static panel was originally suggested. UX can help with this exercise on where it makes sense to have the static panel. Besides consistency matters, I wanted to understand what's the motivation of keeping these widgets static. I.e. is it an essential preparation for the new instance type dialog or a new concept for tab based dialogs (as DC/Cluster values aren't necessarily relevant for each tab in the dialog) [maybe Tomas/Eldan/Malini can help here as well] MR: Here are the original motivations for this static panel. 1. Context for dependencies - In the create VM dialog and the introduction of instance types and images, we came up with two core needs for the UI - There were some fields that were context-setting for other fields with dependencies. So, changing these context setting field values would alter the choices in other fields on one of the sub-tabs or eliminate or populate fields in these tabs. We wanted to ground the user with the context so that they can observe any changes that happen on a tab and determine what caused that change in the static panel. 2. Basic and mandatory - In the create VM dialog and the introduction of instance types and images, we also had to represent different levels of definition needed. For e.g, there were some basic and mandatory fields that were minimally needed for the definition of a VM irrespective of whether the user was basic or advanced. These fields were included in the static panel or at the most in the very first sub tab if they were not a context
