Re: [Engine-devel] Polling vs Pushing engine events
Hi, the following seems to be killing our plans to use a pythonscript to fetch the list of vms: This comes from the users list: Am 17.12.2013 15:04, schrieb Sander Grendelman: Fetching the list of vms through the API with the python SDK takes several seconds[1] with 100% cpu usage in the python script. When I look at the engine log there is only one (fast) fetch from the API. The rest of the time is spent in the SDK processing a relatively small bit of XML data (only 26 VMs in my environment). This seems an excessive amount of CPU for processing ~6KB of XML. I've included some sample code [2] and output [3]. Attached is the cProfile output for this call and a visualization. [1] ~6,5 seconds on an oVirt VM with 1 vcpu on older hardware, ~3,5 seconds on a fast physical machine with an i5 cpu. Am 17.12.2013 15:31, schrieb Michael Pasternak: Hi Sander, This is a known issue caused by generateDS python bindings we use, it's extremely slow in python-xml marshalling, and unable to recognize cyclic referencing in the objects, i'm planning to upgrade in 3.4 from 2.9a to 2.12, if it won't help, we may consider other options. This is no option for us at all: We can't wait for a possible fix in 3.4 (which maybe even does not fix it). Additionally we will have much higher amounts of vms to query. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] [ATN] [devenv] packaging: setup: refactoring
Hello All, a patch refactoring the packaging of ovirt-engine-setup[1] will be merged soon. The change requires latest version of the otopi package to be installed. Please update it in your development environment. [1] http://gerrit.ovirt.org/20293 Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Juan Hernandez as maintainer to api/sdk/cli
On 12/16/2013 09:04 PM, Michael Pasternak wrote: Juan has worked on oVirt for a long period of time, developing several features in the different areas (including api and cli), and obviously gained a lot of experience and knowledge, I'd like to propose Juan as a maintainer of the api/sdk/cli projects. +1 +1 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Juan Hernandez as maintainer to api/sdk/cli
+1, well deserved. - Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Monday, December 16, 2013 10:34:36 AM Subject: [Engine-devel] Proposal to add Juan Hernandez as maintainer to api/sdk/cli Juan has worked on oVirt for a long period of time, developing several features in the different areas (including api and cli), and obviously gained a lot of experience and knowledge, I'd like to propose Juan as a maintainer of the api/sdk/cli projects. -- Michael Pasternak RedHat, ENG-Virtualization RD ___ 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] [jenkins] Request to be able to create jobs for jsonrpc project
- Original Message - From: Piotr Kliczewski piotr.kliczew...@gmail.com To: in...@ovirt.org, engine-devel engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 9:21:21 AM Subject: [jenkins] Request to be able to create jobs for jsonrpc project I am working on new project vdsm-jsonrpc-java which is async client library using json which will be used for communication between engine and vdsm. I would like to create jenkins jobs for this project but have no account nor authority to do so. Can you please +1 my request? +1 Thanks, Piotr ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] No-arg constructor required by default in backend common module's classes
Hi guys, in order to avoid potential errors related to GWT RPC serialization, a recent patch [1] introduced the requirement for no-arg constructor in backend common module's classes. [1] http://gerrit.ovirt.org/#/c/21733/ (Even though we're planning to move away from GWT RPC to using REST API, for the time being, this should prevent RPC related errors caused by missing no-arg constructor, which are sometimes hard to trace.) For a select few classes *not* involved in RPC communication, you can add these in checkstyle-suppressions.xml file. Vojtech ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] UX: Display VM Downtime in the UI
On 18/12/13 16:04 -0500, Malini Rao wrote: - Original Message - From: Adam Litke ali...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 9:42:59 AM Subject: [Engine-devel] UX: Display VM Downtime in the UI Hi UX developers, My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for tracking the time a VM was last stopped and presenting it in the REST API. I would also like to expose this information in the admin portal. This feature has been requested by end users and is useful for managing lots of VMs which may not be used frequently. My idea is to change the 'Uptime' column in the VMs tab to 'Uptime / Downtime' or some equivalent and more compact phrasing. If the VM is Up, then last_start_time would be used to calculate uptime. If the VM is Down, then last_stop_time would be used to calculate downtime. This helps to make efficient use of the column space. Thanks for your comments! MR: I like the idea in general but can we extend to other states as well? Then we could have the col be called something like 'Time in I would argue that 'Up' and 'Down' are the only persistent states where a VM can linger for a user-controlled amount of time. The others (WaitForLaunch, PoweringDown, etc) are just transitions with their own system defined timeouts. Because of this, it really only makes sense to denote uptime and downtime. When the VM is in another state, this column would be empty. current state'. Also, I think since this col is so far from the first column that has the status icon, we should have a tooltip on the value that says ' Uptime' , 'down time' or 'Status time'. Agree on the tooltip. I am not sure how column sorting is being implemented, but if we combine uptime and downtime into a single column we have an opportunity to provide a really intuitive sort where the longest uptime machines are at the top and the longest downtime machines are at the bottom. This could be accomplished by treating uptime as a positive interval and downtime as a negative interval. MR: That's an interesting idea. Not sure how that would translate if we did all states and times. Then I would think you would do descending order within each state but then we would have to fix a sequence for the display of the various statuses based on the statuses that matter most. This is much simpler if you just work with Up and Down. Questions for you all: - Do you support the idea of changing the Uptime column to include Downtime as well or would you prefer a new column instead? MR: I do not like the idea of introducing new columns for this purpose since at any given time, only one of the columns will be populated. Another idea is to remove this column all together and include the time for the current status as a tooltip on the status icon preceding the name. What about adding the uptime/downtime to the status column itself? I don't necessarily think this will muddy the status much since there is still an icon on the left. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] UX: Display VM Downtime in the UI
- Original Message - From: Adam Litke ali...@redhat.com To: Malini Rao m...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 4:19:17 PM Subject: Re: [Engine-devel] UX: Display VM Downtime in the UI On 18/12/13 16:04 -0500, Malini Rao wrote: - Original Message - From: Adam Litke ali...@redhat.com To: engine-devel@ovirt.org Sent: Wednesday, December 18, 2013 9:42:59 AM Subject: [Engine-devel] UX: Display VM Downtime in the UI Hi UX developers, My recent change: http://gerrit.ovirt.org/#/c/22429/ adds support for tracking the time a VM was last stopped and presenting it in the REST API. I would also like to expose this information in the admin portal. This feature has been requested by end users and is useful for managing lots of VMs which may not be used frequently. My idea is to change the 'Uptime' column in the VMs tab to 'Uptime / Downtime' or some equivalent and more compact phrasing. If the VM is Up, then last_start_time would be used to calculate uptime. If the VM is Down, then last_stop_time would be used to calculate downtime. This helps to make efficient use of the column space. Thanks for your comments! MR: I like the idea in general but can we extend to other states as well? Then we could have the col be called something like 'Time in I would argue that 'Up' and 'Down' are the only persistent states where a VM can linger for a user-controlled amount of time. The others (WaitForLaunch, PoweringDown, etc) are just transitions with their own system defined timeouts. Because of this, it really only makes sense to denote uptime and downtime. When the VM is in another state, this column would be empty. ok current state'. Also, I think since this col is so far from the first column that has the status icon, we should have a tooltip on the value that says ' Uptime' , 'down time' or 'Status time'. Agree on the tooltip. I think we should do this in addition to whatever way we decide to display this info elsewhere in the table. I am not sure how column sorting is being implemented, but if we combine uptime and downtime into a single column we have an opportunity to provide a really intuitive sort where the longest uptime machines are at the top and the longest downtime machines are at the bottom. This could be accomplished by treating uptime as a positive interval and downtime as a negative interval. MR: That's an interesting idea. Not sure how that would translate if we did all states and times. Then I would think you would do descending order within each state but then we would have to fix a sequence for the display of the various statuses based on the statuses that matter most. This is much simpler if you just work with Up and Down. Questions for you all: - Do you support the idea of changing the Uptime column to include Downtime as well or would you prefer a new column instead? MR: I do not like the idea of introducing new columns for this purpose since at any given time, only one of the columns will be populated. Another idea is to remove this column all together and include the time for the current status as a tooltip on the status icon preceding the name. What about adding the uptime/downtime to the status column itself? I don't necessarily think this will muddy the status much since there is still an icon on the left. I like that idea. This way, a column is not dedicated to a piece of info that is relevant only sometimes. Depending on how critical/ important this info is, this could just be a tooltip on the icon and the up and Down status values. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
