[Engine-devel] proposing Arik Hadas as a maintainer of engine core
Dear engine-core maintainers, I'd like to propose Arik Hadas as a maintainer of oVirt engine backend Since he started with oVirt project in October 2012 he was working in various areas in engine core, demonstrated his abilities with more than 200 patches merged to engine master alone. Tons of migration related fixes, refactoring of legacy code, but also new complex features including complementary patches in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements for VMTemplate operations) Thanks in advance for your response. Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] AppErrors properties
Hi, while trying to add a new message I couldn't help notice some ugliness in the code regarding our error messages in UI - why do we have @DefaultStringValue in frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java ? All strings are defined in individual properties anyway. - so we have individual properties files….3 of them REST - backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties UP - frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java WA - frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties funnily enough it's not that there are more messages in WA than UP, no, it's just full of random omissions, typos and discrepancies which do not make any logical sense Can't we get rid of the defaults in the interface (useless) and have just one property containing all the messages and use the sam file in all 3 places. And only if there is intentionally a different message in e.g. UP than in WA we can have an override/additional property file there (just by briefly going through most of the differences there's not a single case) Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] AppErrors properties
On Jan 30, 2014, at 14:52 , Einav Cohen eco...@redhat.com wrote: - we used to have a lot of differences between the admin messages and the user portal messages; unfortunately we lost them somehow, I can't remember how or when, it was quite a long time ago. so the fact that the admin and user messages are identical is actually a bug/regression. yeah, it would make sense if e.g. UP messages were simpler/reduced…but it doesn't look like anymore. E.g. there are some gluster-related mesages present in UP but missing from WA which makes no sense at all. - once the GUI will move to REST-API, we won't need any of the frontend files since we will get the translated message directly from the backend. no point in doing any changes before that - it is too much effort for too little gain. right, so doesn't it make sense to keep just the backend ones? (and remove defaults which are useless and just requires you to update 2 places instead of one) and only if REST GUI is still far away by then….copying the same file to UP/WA is a matter of a single makefile line… Thanks, michal Einav - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, January 30, 2014 8:35:22 AM Subject: [Engine-devel] AppErrors properties Hi, while trying to add a new message I couldn't help notice some ugliness in the code regarding our error messages in UI - why do we have @DefaultStringValue in frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java ? All strings are defined in individual properties anyway. - so we have individual properties files….3 of them REST - backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties UP - frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java WA - frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties funnily enough it's not that there are more messages in WA than UP, no, it's just full of random omissions, typos and discrepancies which do not make any logical sense Can't we get rid of the defaults in the interface (useless) and have just one property containing all the messages and use the sam file in all 3 places. And only if there is intentionally a different message in e.g. UP than in WA we can have an override/additional property file there (just by briefly going through most of the differences there's not a single case) Thanks, michal ___ 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] Predictable_vNIC_Order
On Jan 29, 2014, at 08:05 , Meni Yakove myak...@redhat.com wrote: Hi, On oVirt 3.4 there is new feature: http://liver.englab.brq.redhat.com/redirect/?url=http://wiki.ovirt.org/Feature/Predictable_vNIC_Order Right now the feature make sure that the VNIC ordering for VM is the same after create VM from template/snapshot/import. For example: On original VM VNIC1 attached to network blue and VNIC2 attached to network red and on the VM we have two interfaces ETH0 and ETH1, after creating template from this VM and create VM from the template the order of the VNICs are the same for the new VM. On the VM from template the first VNIC is attached to blue network and the second VNIC is attached to red network but on the VM we have ETH2 and ETH3 I think that the feature should also include Sealing_Linux_VM: http://www.ovirt.org/Sealing_Linux_VM we do have a tentative feature to seal/reset Linux VM via virt-sysprep. Not targeted to a release yet... Whit this on the VM from template the interface naming will be the same as the original VM. (ETH0 and ETH1) Where do you see the connection? (I'm not opposing/arguing, just curious what you have in mind how it should work) Thanks, michal Please share your opinion. Thanks Meni ___ 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] [QE] oVirt 3.4.0 alpha / beta status
On Jan 17, 2014, at 13:23 , Sven Kieske s.kie...@mittwald.de wrote: Hi, as I'm interested in the feature and don't want to spam BZ, I ask here: Will reboot of a vm make it into 3.4? https://bugzilla.redhat.com/show_bug.cgi?id=1051451 in the planning document it is marked as done, missed 3.4 branching. Will it get included/backported to the branch or will you wait for 3.4.1? expectation is it will get into 3.4.0 in next few days -- 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 mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [QE] oVirt 3.4.0 alpha / beta status
On Jan 17, 2014, at 12:08 , Sven Kieske s.kie...@mittwald.de wrote: Hi, just a short question: How am I supposed to test 3.4.0. Alpha on EL6 if there is no build available? Isn't this a reason to delay the beta build? If no one can test the alpha on a supported platform? since it's end of week already there's no point in trying to arrange and build everything for alpha, instead focus on building/delivering beta on Monday the problem was not code related hence no reason to delay beta Thanks, michal Am 17.01.2014 10:16, schrieb Sandro Bonazzola: We had an issue with nightly build for EL6 packages yesterday so EL6 repository is not yet updated. We'll try to sync it today, I'm sorry for the inconvenient. We'll start composing oVirt 3.4.0 beta on 2014-01-20 14:00 UTC from 3.4 branches. -- 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 mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] About VM tools(drivers) on oVirt's VM? move mouse have long latency.
On 17 Jan 2014, at 22:52, Itamar Heim ih...@redhat.com wrote: On 01/17/2014 02:53 PM, Michal Skrivanek wrote: On Jan 17, 2014, at 04:14 , JustMan wang.tia...@qq.com wrote: Hi, All: I install both oVirt engine and nodes, it's can work with SPICE client, but the VM lack of drivers (like vmware station's tools ), so when you connected VM it's operation very slow-- I mean operation in VM not smoothness, like move mouse have long latency. And the VirtIO Console Device Enabled VirtIO-SCSI Enabled option it seems not work. How can solve this problem ? I want to use oVirt as a cloud desktop give user for replace desktop PC and notebook, If the latency so long, I think User will not Accept. There are any add-on drivers or tools need install into VM ? Where can download it? Hi, for Windows guests you should install stuff from http://www.spice-space.org/download.html - Guest - Windows binaries also, as this seems to be a recurring issue - please open a bugzilla RFE on having a .iso with the windows drivers. I believe we just need to polish the console resources wiki page. It's just that till now all the relevant pkgs and info are too scattered thanks, Itamar Thanks, michal Many thanks! regards ike 2014-01-17 ___ 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] Setting cluster CPU
On Dec 11, 2013, at 08:18 , Oved Ourfalli ov...@redhat.com wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Oved Ourfalli ov...@redhat.com, Sandro Bonazzola sbona...@redhat.com Cc: Roy Golan rgo...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Tuesday, December 10, 2013 8:01:08 PM Subject: Re: [Engine-devel] Setting cluster CPU On Dec 10, 2013, at 09:14 , Oved Ourfalli ov...@redhat.com wrote: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Michal Skrivanek michal.skriva...@redhat.com, Oved Ourfalli ov...@redhat.com, Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Tuesday, December 10, 2013 9:12:14 AM Subject: Re: [Engine-devel] Setting cluster CPU Il 09/12/2013 19:37, Michal Skrivanek ha scritto: On 09 Dec 2013, at 18:58, Oved Ourfalli ov...@redhat.com wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Sandro Bonazzola sbona...@redhat.com, Roy Golan rgo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Monday, December 9, 2013 5:50:49 PM Subject: Re: [Engine-devel] Setting cluster CPU On Dec 9, 2013, at 16:01 , Sandro Bonazzola sbona...@redhat.com wrote: Hi, I'm trying to set the cluster CPU type while adding the first host to the Default cluster. I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin. But I'm not sure to understand how to set the CPU on an existing cluster. Should it be enough to specify cpu arg while adding the host to the cluster? (before adding an host, cpu is None on the cluster) Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu). The CPU should be set from the first host if None. That is needed for the PPC support. Roy, we talked about it recently, where are we with this patch. We already support modifying the CPU level of an existing cluster. If changing it to a higher level then we just change it. If changing it to a lower level, and there are running VMs on the cluster, then we warn the user that some VMs might not be migrate-able, as we added a scheduling filter to filter out hosts with improper CPU level. Unless I'm missing something, that covers the use-case, isn't it? Not sure. I thought this is None to something, where it should work automatically without specifying anything. Just add an operational host Well, here the issue is that while deploying hosted-engine VM, I'm on a SandyBridge host, with 1 VM running on it (the hosted engine VM). That VM has been created with CPU model Westmere to be able to migrate it to other hosts Westmere compatible. But the Default cluster is automatically set to SandyBridge when I add the because it's created with None in the first place, and then set by the first host. If you'd create it with Westmere initially the joining host would not change it IMHO the setting should be done during the installation not via calling SDK on already created empty cluster but directly in the db when the db is deployed. Unless I'm missing the sequence of deployment. The hosted engine setup doesn't access the DB, so no reason to access it if it is possible to do that via the SDK. Didn't test that, but see no reason for it not to work. host also if I specify Westmere as CPU family in Host parameter. We may be able to set manually the CPU level later somehow, but since we've already asked the user about the CPU level I think we should avoid to ask the user to change it again later. See Bug 1034821 - Hosted-setup asks for CPU type but it doesn't set cluster to that CPU Level You can set the CPU level through the SDK, after you add the host (didn't check that, but see no reason it won't work). why so late in the process? why does it matter? The setup is still running, so, imo, the order is less relevant, as long as the result is okay. depends. if hosted engine is part of the installation, it should do the modifications during installation the same way as anything else, forcefully, and not depend on working sdk or any other precondition if it is something you are/should be able to deploy over an existing setup it's better via sdk... Thanks, michal Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise? -- 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See
Re: [Engine-devel] Setting cluster CPU
On Dec 9, 2013, at 16:01 , Sandro Bonazzola sbona...@redhat.com wrote: Hi, I'm trying to set the cluster CPU type while adding the first host to the Default cluster. I know how to set the CPU type on a new cluster, since I'll do that in AIO plugin. But I'm not sure to understand how to set the CPU on an existing cluster. Should it be enough to specify cpu arg while adding the host to the cluster? (before adding an host, cpu is None on the cluster) Because I'm trying to do that without success (obtaining a sandybridge cluster while specifying westmere cpu). The CPU should be set from the first host if None. That is needed for the PPC support. Roy, we talked about it recently, where are we with this patch. Thanks, michal Michael, can you take a look at http://gerrit.ovirt.org/22129 and advise? -- 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] Multiple graphics framebuffers - VDSM support
On Nov 26, 2013, at 15:57 , Frantisek Kobzik fkob...@redhat.com wrote:
Hi guys,
I created a wiki page with the feature:
http://www.ovirt.org/Features/Multiple_Consoles
It contains information about possible redesign of Engine-VDSM
communication.
I'd appreciate if you take a look at it since it's not trivial change.
I welcome opinions from both engine and vdsm devels.
I think we indeed have to split video device from graphics device and treat it
separately…
Thanks,
michal
Cheers,
F.
- Original Message -
From: Frantisek Kobzik fkob...@redhat.com
To: vdsm-de...@lists.fedorahosted.org
Sent: Monday, November 25, 2013 2:23:59 PM
Subject: Re: [vdsm] Multiple graphics framebuffers - VDSM support
Hi,
it's been some time since the original mail, so I'm sending updated
information.
- Original Message -
From: Frantisek Kobzik fkob...@redhat.com
To: vdsm-de...@lists.fedorahosted.org
Sent: Thursday, November 7, 2013 11:47:46 AM
Subject: [vdsm] Multiple graphics framebuffers - VDSM support
Dear VDSM developers,
I'm working on a patch that allows running a VM with multiple graphics
framebuffers. This is handy when you want to run a VM with both SPICE and
VNC. It's a 3.4 feature and it will certainly need a change in vdsm.
Here is a list of changes in VDSM that are needed for this funcionality:
a, Sending graphics/video (engine-vdsm)
- currently we send two things:
1, display value (qxl/vnc [wat])
- vdsm uses this for determining if the graphics server is SPICE or VNC
- this attribute is not really correct - it mixes up semantics of graphic
framebuffer and videocard together. I believe this attribute should only
contain information about the graphics ('spice', 'vnc' or 'spice,vnc' if
you want both). if this the case, do you think we should rename the
attribute
to, let's say, 'graphics'? Is it even possible with regard to backward
compatibility? or should I reuse 'display' attribute?
2, video device (json representation of the video card) - this is correct
b, Reporting graphics ports (vdsm-engine)
- currently we report 2 graphic ports ('displayPort' and 'secureDisplayPort')
- if we want multiple framebuffers, we must report more ports (for VNC and
SPICE together that would mean 3 ports (2 for spice, one for vnc).
- there are two possible solutions for this:
1, ditch 'displayPort' and 'secureDisplayPort' and add new 'spicePort',
'spiceSecurePort', 'vncPort' fields or some kind of two level dict:
{ protocol - secured/unsecured - portNumber }
2, keep 'displayPort' and 'secureDisplayPort' and introduce new
'additionalDisplayPort'
This would be friendlier to backward compatibility, but it's extremely
ugly because of unclear semantics of the fields (in case of SPICE+VNC
'displayPort' and 'secureDisplayPort' would be related to SPICE,
'additionalDisplayPort' would be the VNC port. In case of VNC only, the
'displayPort' would be suddendly VNC port... ewww).
I'd be very happy if you share your opinion about these changes.
Cheers,
Franta.
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
vdsm-devel mailing list
vdsm-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] [QE] oVirt 3.3.2 beta status
On Nov 27, 2013, at 11:29 , Sandro Bonazzola sbona...@redhat.com wrote: Hi, we're going to branch and build oVirt 3.3.2 beta TODAY. A bug tracker is available at [1] and it shows only 3 bugs still blocking the release: WhiteboardBug ID Summary storage 1022961 Running a VM from a gluster domain uses mount instead of gluster URI virt 1025829 sysprep floppy is not attached to Windows 2008 R2 machine - even when specifically checked in Run Once hopefully end of week we will know more. Should not be hard though virt 1029885 cloud-init testcase does not work in engine 3.3.1 this is about current CentOS containing a quite dated version of cloud-init. There's little we can do except encourage people to build/use 0.7.2+ Awaiting reporter's feedback Thanks, michal Please provide an ETA for the above bugs. The following is a list of the non-blocking bugs still open with target 3.3.2: WhiteboardBug ID Summary infra 1017267 Plaintext user passwords in async_tasks database infra 987982 When adding a host through the REST API, the error message says that rootPassword is required,... infra 1020344 Power Managent with cisco_ucs problem integration 1022440 AIO - configure the AIO host to be a gluster cluster/host integration 902979 ovirt-live - firefox doesn't trust the installed engine integration 1021805 oVirt Live - use motd to show the admin password integration 1026930 Package virtio-win and put it in ovirt repositories integration 1026933 pre-populate ISO domain with virtio-win ISO network 1019818 Support OpenStack Havana layer 2 agent integration network 987999 [oVirt] [provider] Add button shouldn't appear on specific provider network 987916 [oVirt] [provider] Dialog doesn't update unless focus lost network 906313 [oVirt-webadmin] [setupNetworks] No valid Operation for network_name and Unassigned Logical Networks panel network 1023722 [oVirt-webadmin][network] Network roles in cluster management should be radio buttons network 997197 Some AppErrors messages are grammatically incorrect (singular vs plural) storage 1029069 Live storage migration snapshot removal fails, probably due to unexpected qemu-img output storage 987917 [oVirt] [glance] API version not specified in provider dialog storage 1016118 async between masterVersion : can't connect to StoragePool ux906394 [oVirt-webadmin] [network] Loading animation in network main tab 'hosts' and 'vms' subtab is stuck on first view... virt 1007940 Cannot clone from snapshot while using GlusterFS as POSIX Storage Domain Please add the bugs to the tracker if you think that 3.3.2 should not be released without them fixed. For those who want to help testing the bugs, I suggest to add yourself as QA contact for the bug and add yourself to the testing page [2]. Maintainers are welcomed to start filling release notes, the page has been created here [3] [1] https://bugzilla.redhat.com/1027349 [2] http://www.ovirt.org/Testing/Ovirt_3.3.2_testing [3] http://www.ovirt.org/OVirt_3.3.2_release_notes Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] failed to add host into cluster
On Nov 21, 2013, at 12:13 , ouyang guohua gouy...@redhat.com wrote:
On 11/21/2013 07:02 PM, Itamar Heim wrote:
On 11/21/2013 12:59 PM, ouyang guohua wrote:
On 11/21/2013 06:35 PM, Itamar Heim wrote:
On 11/21/2013 11:07 AM, ouyang guohua wrote:
Hi,
I encounter the same problem today.
Both the engine and the node are fedora 19.
1. on engine host:
engine=# select * from vdc_options where option_name ilike '%emu%';
option_id | option_name | option_value | version
---+-+--+-
38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0
39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1
40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2
41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3
(4 rows)
engine=# select name,emulated_machine from vds_groups;
name | emulated_machine
-+--
Default |
fedora19-cluster| pc-1.0
fedora19-node-Local | pc-1.0
(3 rows)
2. on node:
# vdsClient -s 0 getVdsCaps
HBAInventory = {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []}
ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e
bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500',
'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0':
{'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [],
'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {},
'mtu':
'1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'},
'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '',
'slaves':
[], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {},
'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr':
'72:c4:9e:9d:25:c1'}}
bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg':
{'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge',
'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS':
'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED':
'no',
'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL':
'no',
'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF':
'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500',
'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}}
clusterLevels = ['3.0', '3.1', '3.2']
cpuCores = 4
cpuFlags =
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270
cpuModel = Intel(R) Core(TM)2 Quad CPUQ9400 @ 2.66GHz
cpuSockets = 1
cpuSpeed = 2660.126
cpuThreads = 4
emulatedMachines = ['clipper', 'none']
guestOverhead = 65
hooks = {}
kvmEnabled = true
lastClient = 10.66.105.101
lastClientIface = ovirtmgmt
management_ip =
memSize = 3888
netConfigDirty = False
networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr':
'10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes',
'TYPE':
'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes',
'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0',
'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt',
'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE':
'yes', 'IPV6_AUTOCONF': 'yes', 'UUID':
'447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask':
'255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway':
'10.66.11.254', 'ports': ['em1']}}
nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes',
'BRIDGE':
'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS':
'yes',
'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes',
'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE':
'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no',
'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID':
'447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '',
'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}}
operatingSystem = {'release': '4', 'version': '19', 'name':
'Fedora'}
packages2 = {'kernel': {'release': '200.fc19.x86_64',
'buildtime':
1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release':
'3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm':
{'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'},
'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version':
'1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188,
'version': '1.0.5.7'}, 'qemu-img': {'release': '13.fc19', 'buildtime':
1383700301, 'version': '1.4.2'}, 'mom': {'release':
Re: [Engine-devel] failed to add host into cluster
On Nov 21, 2013, at 12:45 , ouyang guohua gouy...@redhat.com wrote:
On 11/21/2013 07:23 PM, Michal Skrivanek wrote:
On Nov 21, 2013, at 12:13 , ouyang guohua gouy...@redhat.com wrote:
On 11/21/2013 07:02 PM, Itamar Heim wrote:
On 11/21/2013 12:59 PM, ouyang guohua wrote:
On 11/21/2013 06:35 PM, Itamar Heim wrote:
On 11/21/2013 11:07 AM, ouyang guohua wrote:
Hi,
I encounter the same problem today.
Both the engine and the node are fedora 19.
1. on engine host:
engine=# select * from vdc_options where option_name ilike '%emu%';
option_id | option_name | option_value | version
---+-+--+-
38 | ClusterEmulatedMachines | rhel6.2.0,pc-1.0 | 3.0
39 | ClusterEmulatedMachines | rhel6.3.0,pc-1.0 | 3.1
40 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.2
41 | ClusterEmulatedMachines | rhel6.4.0,pc-1.0 | 3.3
(4 rows)
engine=# select name,emulated_machine from vds_groups;
name | emulated_machine
-+--
Default |
fedora19-cluster| pc-1.0
fedora19-node-Local | pc-1.0
(3 rows)
2. on node:
# vdsClient -s 0 getVdsCaps
HBAInventory = {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:643bb46781e'}], 'FC': []}
ISCSIInitiatorName = iqn.1994-05.com.redhat:643bb46781e
bondings = {'bond4': {'addr': '', 'cfg': {}, 'mtu': '1500',
'netmask': '', 'slaves': [], 'hwaddr': '7e:00:7f:e7:90:4c'}, 'bond0':
{'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '', 'slaves': [],
'hwaddr': 'de:c5:12:4e:17:6f'}, 'bond1': {'addr': '', 'cfg': {},
'mtu':
'1500', 'netmask': '', 'slaves': [], 'hwaddr': '2e:ec:3b:01:ab:de'},
'bond2': {'addr': '', 'cfg': {}, 'mtu': '1500', 'netmask': '',
'slaves':
[], 'hwaddr': 'da:88:61:cb:0d:ed'}, 'bond3': {'addr': '', 'cfg': {},
'mtu': '1500', 'netmask': '', 'slaves': [], 'hwaddr':
'72:c4:9e:9d:25:c1'}}
bridges = {'ovirtmgmt': {'addr': '10.66.10.186', 'cfg':
{'PEERROUTES': 'yes', 'IPV6INIT': 'yes', 'TYPE': 'Bridge',
'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS':
'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0', 'NM_CONTROLLED':
'no',
'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt', 'IPV6_FAILURE_FATAL':
'no',
'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE': 'yes', 'IPV6_AUTOCONF':
'yes', 'UUID': '447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500',
'netmask': '255.255.252.0', 'stp': 'off', 'ports': ['em1']}}
clusterLevels = ['3.0', '3.1', '3.2']
cpuCores = 4
cpuFlags =
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,aperfmperf,pni,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,sse4_1,xsave,lahf_lm,dtherm,tpr_shadow,vnmi,flexpriority,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_n270
cpuModel = Intel(R) Core(TM)2 Quad CPUQ9400 @ 2.66GHz
cpuSockets = 1
cpuSpeed = 2660.126
cpuThreads = 4
emulatedMachines = ['clipper', 'none']
guestOverhead = 65
hooks = {}
kvmEnabled = true
lastClient = 10.66.105.101
lastClientIface = ovirtmgmt
management_ip =
memSize = 3888
netConfigDirty = False
networks = {'ovirtmgmt': {'iface': 'ovirtmgmt', 'addr':
'10.66.10.186', 'cfg': {'PEERROUTES': 'yes', 'IPV6INIT': 'yes',
'TYPE':
'Bridge', 'IPV6_PEERDNS': 'yes', 'DEFROUTE': 'yes', 'ONBOOT': 'yes',
'PEERDNS': 'yes', 'IPV4_FAILURE_FATAL': 'no', 'DELAY': '0',
'NM_CONTROLLED': 'no', 'BOOTPROTO': 'dhcp', 'DEVICE': 'ovirtmgmt',
'IPV6_FAILURE_FATAL': 'no', 'IPV6_PEERROUTES': 'yes', 'IPV6_DEFROUTE':
'yes', 'IPV6_AUTOCONF': 'yes', 'UUID':
'447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask':
'255.255.252.0', 'stp': 'off', 'bridged': True, 'gateway':
'10.66.11.254', 'ports': ['em1']}}
nics = {'em1': {'addr': '', 'cfg': {'PEERROUTES': 'yes',
'BRIDGE':
'ovirtmgmt', 'DEVICE': 'em1', 'IPV6INIT': 'yes', 'IPV6_PEERDNS':
'yes',
'DEFROUTE': 'yes', 'ONBOOT': 'yes', 'PEERDNS': 'yes',
'IPV4_FAILURE_FATAL': 'no', 'NM_CONTROLLED': 'no', 'IPV6_DEFROUTE':
'yes', 'IPV6_AUTOCONF': 'yes', 'IPV6_FAILURE_FATAL': 'no',
'IPV6_PEERROUTES': 'yes', 'HWADDR': '00:23:ae:9d:85:32', 'UUID':
'447b16c1-184a-4347-a801-ef8143c2d932'}, 'mtu': '1500', 'netmask': '',
'hwaddr': '00:23:ae:9d:85:32', 'speed': 1000}}
operatingSystem = {'release': '4', 'version': '19', 'name':
'Fedora'}
packages2 = {'kernel': {'release': '200.fc19.x86_64',
'buildtime':
1383545343.0, 'version': '3.11.7'}, 'spice-server': {'release':
'3.fc19', 'buildtime': 1383130020, 'version': '0.12.4'}, 'vdsm':
{'release': '18.fc19', 'buildtime': 1373484771, 'version': '4.10.3'},
'qemu-kvm': {'release': '13.fc19', 'buildtime': 1383700301, 'version':
'1.4.2'}, 'libvirt': {'release': '1.fc19', 'buildtime': 1383765188,
'version': '1.0.5.7'}, 'qemu-img
Re: [Engine-devel] Migrating an existing installation to hosted engine
On Nov 12, 2013, at 12:38 , Yedidyah Bar David d...@redhat.com wrote: Hi all, A message with the same subject was sent to arch around a month ago, see [1]. In short, it suggested two approaches: 1. Use p2v (or v2v) 2. Clean install of OS/engine software and use backup/restore. Following that, I pushed a few changes for engine-backup and engine-setup, with the intention of doing, briefly: 1. hosted-engine --deploy on new host 2. Install OS/software on new vm 3. backup on old engine machine 4. On new vm, do restore, which only restores the database and files, followed by engine-setup, which will fix whatever else needs to be fixed. Some of the changes are still pending, and are under some controversy. See [2], [3], [4]. A more detailed description of the suggested migration path is in [5]. What do you think? Should engine-setup do as little as possible to the system, or as much as needed to save the admin from any manual work? Should engine-setup doing an upgrade do the same as a new setup, or just whatever that's needed to adapt the config/database to the new code? A specific example: if admin chose during initial setup to automatically configure the firewall (iptables/firewalld), should upgrade update it again, or not touch it? Should engine-backup do all these things when doing a restore? I think using the same tool for both tasks(backup, migration to hosted engine) has an advantage that you only address issues (like missing item to backup/restore) once and both usecases benefit from a fix Should we have some other utility to do these things? Should we merely document them and let the admin do this manually? [1] http://lists.ovirt.org/pipermail/arch/2013-October/001677.html [2] https://bugzilla.redhat.com/1024707 [3] http://gerrit.ovirt.org/20736 [4] http://gerrit.ovirt.org/20737 [5] http://www.ovirt.org/Migrate_to_Hosted_Engine -- Didi ___ 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] [UX] how to design a bar/line chart?
On Nov 14, 2013, at 00:09 , Einav Cohen eco...@redhat.com wrote: ... but we may have to see how this looks when multiple sparklines reside in columns next to each other. ... ... Is this going to fit in a row of a table? Or are we talking of a more detailed view? ... a concern on which I happened to briefly discuss with Eldan / Malini and actually somewhat raised here earlier in the thread (see above): Since we are adding another information dimension (time), we are actually going to display a lot more information to the user within the CPU/MEM/NET columns, and there is a chance that the view will become too overloaded/confusing, and we will end up with a view that is less clear than the current one. Well, for that we IMHO have much bigger issue already with the fact we do not hide/show columns, and many of them do not really provide much value in all use cases. If you look at the mockup and the screenshots from users I've seen - e.g. the Display column(don't care), the Cluster (not wide enough, repetition of the same info on each line), Host(repetition of domain parts of FQDN) makes it overloaded already. Since statistics do provide some value and it keeps changing based on load it IMHO looks ok ...maybe just a global setting to disable this if it gets annoying? It's a small feature and it's trivial to add such a setting. Just so we will have a general idea of how it will look like eventually, so we will be able to do a slightly more educated decision, I am attaching a mock-up of how it looks now compared to how it may look once this feature is implemented. * In my mock-up, I followed Malini's guideline from earlier in the thread: One color with a dot to indicate the most recent or most relevant data and display its value next to the sparkline Thanks for the mock up, I think it looks great. Perhaps I'd consider lines instead of dots (to see the base 0, currently the line is somehow in the air and since the height is limited it may be difficult to distinguissh 20% from 0%), provided they are in some light color it may look ok * keep in mind that the view is dynamic and keeps updating once it receives new statistics from the backend. Thoughts? - Original Message - From: Malini Rao m...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: Einav Cohen eco...@redhat.com, engine-devel engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, info i...@eldanet.com, Martin Polednik mpole...@redhat.com Sent: Wednesday, November 6, 2013 10:24:56 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Hey all, Comments inline- - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: Einav Cohen eco...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, info i...@eldanet.com, Malini Rao m...@redhat.com, Martin Polednik mpole...@redhat.com Sent: Wednesday, November 6, 2013 9:58:03 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Hi Einav, - Original Message - From: Einav Cohen eco...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, info i...@eldanet.com, Malini Rao m...@redhat.com Sent: Wednesday, November 6, 2013 3:26:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Hi Tomas, Like Itamar, I think that a line chart is a better idea, and that a chart per monitored fact (rather than a combined chart) is better. OK Based on the original request in the bug, it seems like Itamar is looking for a trend rather than just one data point. I think we are thinking along the correct lines here with a line graph but I think more specifically, we should consider sparklines - http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR. Agree that we should have one sparkline per fact but we may have to see how this looks when multiple sparklines reside in columns next to each other. See example of a grid where there are 2 sparklines next to each other - http://www.panopticon.com/Tables-Grids the statistics readable enough. Maybe if you hover the chart it could pop up a bigger version of the chart? Or not needed? this is a nice-to-have, I think, definitely not needed. OK Agree. As shown in the glucose example in the Tufte link I posted above, maybe all we need is to indicate the acceptable range with a band and if the last point is in the range or outside, it will be clear to the user if they should pay attention to it. - Would it be enough to have it in one color? Or should it be something like the bigger the utilization the more red? question is what will happen when there are a lot of jumps: let's say that the graph changes from 0% to 100% to 0% to 100% and so on... what will be painted red? the entire line, but only in the periods that it jumps to
Re: [Engine-devel] [UX] how to design a bar/line chart?
On Nov 12, 2013, at 11:18 , Tomas Jelinek tjeli...@redhat.com wrote: So we have looked into the resource usage sampling with mbetak and also with Michal and it seems that for the CPU usage: - VDSM polls libvirt to get the runtime statistics of the VM regularly. The pooling interval is configured in vdsm.conf as vm_sample_cpu_interval and by default it is 15 seconds - libvirt returns something we than use to calculate the average CPU usage since the last poll - engine polls VDSM once in 15 seconds to get the current statistics (the same 15 seconds is just a coincidence and we can not count on this) - than the frontend polls the engine each 5-60 seconds (depends on the refresh rate) and gets the current value from the engine - the user can press the refresh button anytime to poll the engine again For network usage: - it should be pretty much the same as the CPU just the VDSM poll interval is configured as vm_sample_net_interval and by default it is 5 seconds Dan, since we poll only every 15s and cpu info is 15s wouldn't it make sense to change the default for network monitoring to 15s as well? it's 2 libvirt rounds trip for nothing really. Or does it serve some other purpose? For memory usage: - guest agent sends a message to VDSM with the memory usage regularly. The interval is set in ovirt-guest-agent.conf as heart_beat_rate and by default it is 5 seconds - the actual value sent by ovirt-guest-agent is the actual value at the time when the value is sent (e.g. for Linux taken from cat /proc/meminfo) - vdsm is doing no statistics on top of it, just remembers the last value taken from ovirt-guest-agent which is fine, it doesn't change so often and there are typically no spikes - the rest of the poling is the same So, visualizing this in some usable form will be quite challenging ;) I see the following problems: - if the VDSM gets the data faster than the engine polls it (and most often it does) than the info in between will be lost. The question is how big this problem is and if it is worth solving (I would say not for CPU which are averages but maybe yes for memory). Other question if there is a way how to solve it since the VDSM can be polled by anyone and it does not really care if someone polls it... (Michal?) I'd say not solve it and try to keep it in sync on vdsm side with engine poll, to save unnecessary libvirt calls - we can lost some data between frontend-engine if the polling interval of the FE is slower than the polling interval of the engine. This is something not really worth solving because the user can set this according to the level of detail he/she wants well, you should average the values in engine in case the FE refresh is 15s. Or add (refresh/15) of them - since we will get new info once in ~15 seconds, and the polling of the FE is by default 5 seconds, do we want to do some interpolation? Or just show the same value 3 times? Or be smart and show only changed values? (this is tricky since there is a chance that it did not change - e.g. constant 0 mem usage if you have no guest agent) - What if the user starts clicking to the refresh button? Do we want to keep appending the same value if the engine still has only the old ones? just add a new line/point every 15s should be ok Thanks, michal Tomas - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: Malini Rao m...@redhat.com Cc: Eldan Hildesheim ehild...@redhat.com, engine-devel@ovirt.org, info i...@eldanet.com Sent: Monday, November 11, 2013 4:23:09 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? - Original Message - From: Malini Rao m...@redhat.com To: Eldan Hildesheim ehild...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, info i...@eldanet.com, engine-devel@ovirt.org Sent: Monday, November 11, 2013 4:15:50 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Is this going to fit in a row of a table? Or are we talking of a more detailed view? it should fit into one cell of the table - Original Message - From: Eldan Hildesheim ehild...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: info i...@eldanet.com, engine-devel@ovirt.org Sent: Monday, November 11, 2013 8:01:07 AM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? Throw this gif into a browser. This is more or less what I thought. Eldan - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: Eldan Hildesheim ehild...@redhat.com Cc: Einav Cohen eco...@redhat.com, info i...@eldanet.com, engine-devel@ovirt.org Sent: Monday, November 11, 2013 12:03:15 PM Subject: Re: [Engine-devel] [UX] how to design a bar/line chart? - Original Message - From: Eldan Hildesheim ehild...@redhat.com To: Einav Cohen eco...@redhat.com Cc: info i...@eldanet.com, engine-devel@ovirt.org Sent: Sunday, November 10, 2013 3:56:57 PM
Re: [Engine-devel] RFE: SPICE and VNC graphics at the same time
On Nov 6, 2013, at 10:33 , Frantisek Kobzik fkob...@redhat.com wrote: Dear devels, I started working on a feature that allows user to run a VM with both SPICE and VNC graphics [1]. In the engine we derive the graphics server type (SPICE/VNC) from the video device (QXL/CIRRUS), which I think is wrong. These are two different things and should be treated separately. What I suggest is to split that configuration in vm_static into two fields: 1, (already existing) Display type with values QXL or CIRRUS 2, (new) Graphics types - enum or comma-separated string that indicates that the VM should be run with 'spice'/'vnc'/'spice,vnc'/'auto' (the last means that the type will be derived from the video device which is current behavior. pls take a look at http://gerrit.ovirt.org/#/c/18677/ The feature would consist of three patches: - vdsm - add new field in vm.conf with information about graphics types of a vm. - engine backend - add graphics types to VM and corresponding entities, adjust xml rpc communication. - engine frontend - only adjust the ui. The patches would be backwards compatible with older engine/vdsm versions. There are some things that must be taken into account, mostly it's about differences in SPICE/VNC supported features (like multimonitors, single qxl, smartcard, migration...). e.g. if you run a vm with both graphic types together the engine should probably disallow some spice features. But this is more of an implementation detail. Feel free to reply if you have anything to say about this feature. Cheers, Franta. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=976044 ___ 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] unit tests by default enabled
Hi, since there were quite a few recent breakages of master branch compilation the patch [1] has been proposed (and merged) to run the unit tests during default compilation Hope it will make oVirt a bit more stable... Thanks, michal [1] http://gerrit.ovirt.org/#/c/19513/ ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] 3.3.0.1 Release branch and tracker
Hi, bug 1011547 may deserve it… let me/Martin know what you think If not we'll just go with 3.3.1 Thanks, michal On Sep 25, 2013, at 09:40 , Ofer Schreiber oschr...@redhat.com wrote: Hey, As you may know, we're planning to release oVirt 3.3.0.1 soon. I've created a tracker bug (https://bugzilla.redhat.com/show_bug.cgi?id=1011800) and a git branch (ovirt-engine-3.3.0.1, based on 3.3.0) for this release. If you're working on a really urgent bug, please notify me or Mike, so it will be included in next version, otherwise, most issues will be included in 3.3.1 which will be based on the ovirt-engine-3.3 branch. Please don't merge anything into 3.3.0.1 without consulting. If all those branches and releases makes you dizzy, ping me on IRC and I'll try to clear it out. Thanks, Ofer Schreiber ___ 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] -1
Hey, Hungry Hungarian, I'm sorry to see you go, enjoy your new endeavors! good luck! michal On Sep 11, 2013, at 13:23 , Tomas Jelinek tjeli...@redhat.com wrote: Hi Laszlo, it is sad that you are leaving. But anyway, good luck in your new position! Hötyök Máró! Tomas - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Wednesday, September 11, 2013 1:15:49 PM Subject: [Engine-devel] -1 Hi, This was my last week with oVirt, I give back my maintainer permissions. Good luck guys! :) Best regards, Laszlo ___ 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] Mapping between supported display protocols and video devices
On Sep 1, 2013, at 12:28 , Roy Golan rgo...@redhat.com wrote: On 08/30/2013 07:33 PM, Vitor de Lima wrote: Hi everyone, Recently the changes #18150, #18677 and #17885 were submitted in order to avoid the selection of display protocols and virtual video cards that are incompatible with the PPC64 architecture and to map the VNC protocol with the standard VGA virtual device, since the Cirrus Logic device is not supported in the PPC64 architecture. I would like some feedback about that. So far, these changes use an existing parameter in the osinfo (called spiceSupport) to validate if the selected operating system supports SPICE and hide it in the frontend in case it doesn't. They also change the default virtual video card for each display protocol according to new properties in the osinfo, e.g.: os.other.spiceSupport.value = true os.other.devices.vnc.vmDeviceType.value = cirrus os.other.devices.qxl.vmDeviceType.value = qxl os.other_ppc64.spiceSupport.value = false os.other_ppc64.devices.vnc.vmDeviceType.value = vga (This maps the qxl protocol into the qxl device and the VNC protocol into the cirrus device in the x86_64 arch, and the VNC protocol into the VGA device in the PPC64) However, this still has some limitations, such as: * It doesn't allow the user to choose between the different virtual devices that exist and can be used in the VNC protocol (such as the QXL and VMware VGA) * The syntax is ugly. As suggested in the code reviews, it could be a list of supported protocols, e.g.: os.other.displayProtocols = vnc, spice +1 list style is cleaner, expressive and easy to use. spiceSupport was just the way to convert the old code to the osinfo style. protocol-device mapping can be achieved by pairing them literally - os.other.displayProtocols.value = vnc/cirrus, spice/qxl which reads VNC over cirrus device, SPICE over qxl device. and for ppc64: os.other_ppc64.displayProtocols.value = vnc/qxl, spice/qxl I like this approach better than naming the keys with terms ...devices.vnc.VMDviceType…. +1 if not too much complicated So, how should the engine be modified to allow multiple video cards for each display protocol? What do you think should be done? Thanks, Vitor de Lima ___ 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] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ 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] SSH Soft Fencing
On Jul 2, 2013, at 10:44 , Eli Mesika emes...@redhat.com wrote: - Original Message - From: Livnat Peer lp...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: engine-devel@ovirt.org Sent: Monday, July 1, 2013 12:57:34 PM Subject: Re: [Engine-devel] SSH Soft Fencing On 07/01/2013 11:27 AM, Yair Zaslavsky wrote: - Original Message - From: Martin Perina mper...@redhat.com To: engine-devel@ovirt.org Sent: Monday, July 1, 2013 11:23:12 AM Subject: Re: [Engine-devel] SSH Soft Fencing So let me summarize it: We have come to agreement in those questions: 1) SSH Soft Fencing logic should be extracted from VdsNotRespondingTreatment command to its own SshSoftFencingCommand 2) VdsNotRespondingCommand should be refactored so it's not inherited from VdsRestartCommand, but it should run SshSoftFencingCommand or VdsRestartCommand based on defined fencing flow These questions has not been resolved yet: 3) Should SSH Soft Fencing be executed also for hosts without PM configured? 4) Should SSH Soft Fencing execution for hosts without PM configured be enabled by default and admin can turn off these feature using configuration options SshSoftFencingWithoutPmEnabled (or something like that)? 5) Should SshSoftFencingWithoutPmEnabled be a global option or a cluster wide option (can be turned off for specific cluster version) or a VDS option (it can be turned off for each host)? Personally I would suggest: ad 3) Yes, SSH Soft Fencing should be executed also for hosts without PM configured +1 ad 4) Yes, SSH Soft Fencing for hosts without PM configured should be enabled by default +1 ad 5) I don't see any significant reason why someone would like to turn off SSH Soft Fencing for hosts without PM configured. But if someone would like to do that, I think he would like to turn it off only for specific hosts, so VDS level option makes sense for me After re-thinking 5 - I agree. +1 on the other suggestions, but of course we need to get more consensus here. I think it does not need to be configurable. I think a configuration option, as cumbersome and confusing as it can be, is still better than no choice. Especially if it means to restore the previous behavior. If it only can happen in a theoretical problem at customer where vdsm restart cause issues for whatever theoretical reason….it would be of great help then. And if you don't understand the parameter - just don't touch it, I hope that's a general rule:-) +1 on all above as well Martin ___ 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 ___ 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] [rhevm-staff] Fwd: BatchUpdates and VdsUpdateRuntimeInfo
- Forwarded Message - From: Liran Zelkha liran.zel...@gmail.com To: engine-devel engine-devel@ovirt.org Cc: Itamar Heim ih...@redhat.com, Barak Azulay bazu...@redhat.com, Allon Mureinik amure...@redhat.com Sent: Wednesday, July 3, 2013 1:08:08 PM Subject: BatchUpdates and VdsUpdateRuntimeInfo Hi all, Batch updates are now merged, so please start using it. As usage example, please check VdsUpdateRuntimeInfo code. Attached doc shows performance benefits from using batch over regular update. Batch Updates in VdsUpdateRuntimeInfo.pdf Is the percentage per each VM update? Or a loaded average system? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Console broken with current master vmSetTicket error
Hi, are you using display network? if so it's a libvirt issue. Try to downgrade your libvirt or wait for a fix. Don't have a bug # though….but I see some fix is posted so it should land there soon… Thanks, michal On Jun 25, 2013, at 01:46 , Dead Horse deadhorseconsult...@gmail.com wrote: libvirt-python-0.10.2-18.0.1.el6_4.8.x86_64 libvirt-client-0.10.2-18.0.1.el6_4.8.x86_64 libvirt-java-0.4.9-1.el6.noarch libvirt-0.10.2-18.0.1.el6_4.8.x86_64 libvirt-java-devel-0.4.9-1.el6.noarch libvirt-lock-sanlock-0.10.2-18.0.1.el6_4.8.x86_64 libvirt-devel-0.10.2-18.0.1.el6_4.8.x86_64 libvirtd log attached. - DHC On Sun, Jun 23, 2013 at 2:00 AM, Michal Skrivanek michal.skriva...@redhat.com wrote: Hi, libvirt version? perhaps libvirt log as well Thanks, michal On Jun 22, 2013, at 04:05 , Dead Horse deadhorseconsult...@gmail.com wrote: When the console button is clicked in the webadmin or userportal (engine and vdsm built from the latest master) the follow error message is returned: Error while executing action SetVmTicket: Unexpected exception This occurs with latest master engine and vdsm built as of today. engine and vdsm logs of failure attached. - DHC engine.logvdsm.log___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel libvirtd.log ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
On Jun 24, 2013, at 10:08 , Itamar Heim ih...@redhat.com wrote: On 06/24/2013 11:02 AM, Michal Skrivanek wrote: On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote: On 06/20/2013 03:13 PM, Tomas Jelinek wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Christophe Fergeau cferg...@redhat.com Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel engine-devel@ovirt.org, spice-de...@lists.freedesktop.org, Marc-André Lureau mlur...@redhat.com Sent: Thursday, June 20, 2013 1:09:21 PM Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST On 06/20/2013 02:07 PM, Christophe Fergeau wrote: Hey Itamar, On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote: On 06/19/2013 04:33 PM, Tomas Jelinek wrote: Hi all, for the non plugin invocation of the console (http://www.ovirt.org/Features/Non_plugin_console_invocation) the dynamicMenu property is not usable to enrich the SPICE client menu. This feature is about requesting this menu using oVirt's REST API and than calling it back once some item from this menu has been selected. The oVirt's feature page with specific details: http://www.ovirt.org/Features/Foreign_Menu_Using_REST Any comments are more than welcomed. Why are we putting the logic of the menu into the REST API? can't the menu be builded by client based on getting the list of ISO's and current CD? The client needs a way to get the list of available ISOs in order to build the menu, as well as a way to let the engine know when the user clicked on an ISO in the menu. One way of doing that is to have the menu stuff exposed in the REST API. Another way would be to expose the list of ISOs in the REST API (I'd have a slight preference for that I think). that's my preference as well, and the REST API should already do that today: - get list of ISOs of available in a DC (the one the VM is in) - ability to change the CD of the VM Well, and what about the stop/suspend VM for example, what we have in the menu today? supported as well. Also this should be something that the client decide to have or not have? I think the client should decide on the features relevant to the client. Or do you have anything in mind for the client to get the list of ISOs available to the engine? my preference is to provide the data, not the semantics of the menu. We should clarify something here. There are two possibilities who should be responsible for deciding what should the foreign menu contain and also what to do if it the item is selected: 1: the client - e.g. we will not provide any support for the menu in REST because the client reads what needs and knows how to call the oVirt back 2: the server side - e.g. we will provide in REST side the menu structure with the description what to do if something is selected Both have some advantages and disadvantages but we need to clarify which way to go. So, who is the one responsible to decide what is in the foreign menu (now or in the future) and how to react if something is selected? Client or engine? my preference is the client will decide this, as there are various clients to the REST API, and each should decide which features are important for them. I would agree as long as it is not hardcoded and can be change in some config file easily. We shouldn't wait for next RHEL release to do a little modification if possible. I think owning the menu in some form on RHEV-M side has an advantage of delivery synchronization. this forces you to maintain backward compatibility in the Menu API, the client to handle ignoring new features/items in the menu they don't support yet, etc. while the *data* which is the important part is already in the stable, backward compatible, API. i don't think it would be needed. We don't really need much features on spice client side except for displaying and invoking a generic REST call. Items support is based on Engine side if the menu is supplied by Engine side. iiuc, we are on the same page. Christophe ___ 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] Console broken with current master vmSetTicket error
Hi, libvirt version? perhaps libvirt log as well Thanks, michal On Jun 22, 2013, at 04:05 , Dead Horse deadhorseconsult...@gmail.com wrote: When the console button is clicked in the webadmin or userportal (engine and vdsm built from the latest master) the follow error message is returned: Error while executing action SetVmTicket: Unexpected exception This occurs with latest master engine and vdsm built as of today. engine and vdsm logs of failure attached. - DHC engine.logvdsm.log___ 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] Cloud-Init integration
On Jun 16, 2013, at 18:04 , Dan Kenigsberg dan...@redhat.com wrote: On Sun, Jun 16, 2013 at 05:50:38PM +0300, Greg Padgett wrote: On 06/16/2013 05:08 PM, Mike Kolesnik wrote: - Original Message - On Thu, Mar 28, 2013 at 07:35:23PM -0400, Greg Padgett wrote: Hi Everyone, I'd like to propose a feature we've been doing some investigation into, which is to integrate cloud-init support into oVirt. Cloud-init is used to help provision new Linux systems by setting the hostname, ip, ssh keys, timezone, injecting files, and more. It's used by OpenStack (amongst others) now, and has a lot of features that may be helpful to our users. Details are still evolving, but for more info please see the wiki page: http://www.ovirt.org/Features/Cloud-Init_Integration All feedback is welcome! All feedback? Even if it's 3 months too late? I'll have to be more careful next time to specify a time limit :) But really, thank you both for the comments. Feel free to add them to a nice to have list on the wiki page, or I can add it. Replies inline... If so, then here's a few comments: 1. oVirt-3.2 completely supports IPv6 within guests. It would be nice to carry this on to cloud-init, by allowing to set the IPv6 address of the guest. (or are we happy with the auto configured ipv6 addresses?) It would, but unfortunately cloud-init doesn't yet translate ipv6 fields from /etc/network/interfaces (its chosen networking input format) to ifcfg files. Now that you mention it, it doesn't add IPV6INIT=yes, either. ifcfg files? What's that? Those easily-edited text files that are being deprecated by NetworkManager? Does cloud-init play well with the latter? (we found a couple of pitfalls, the hard way). These are things we can add--to both oVirt and cloud-init, I guess at a later time. 2. I think that the GUI used for setting IP addresses should be immitated here. It allows Static/DHCP/None, and disables the irrelvant fields when DHCP/None is selected. It's close: there is a checkbox for dhcp, and if selected it will hide the non-relevant fields. I hate surprises, so I'm in favor of having the same thing, as well as the keep recent config in memory when bootproto is moved to None semantics. This applies more strongly to the REST api. Host level configuration http://www.ovirt.org/Features/Design/Network/SetupNetworks#Scheme has host_nic nameem1/name ip address=10.35.1.247 netmask=255.255.254.0 gateway=10.35.1.254/ boot_protocoldhcp/boot_protocol /host_nic And for reporting guest configuration http://www.ovirt.org/Feature/ReportingVnicImplementation#API_Changes has network_device namep1p2/name descriptionguest reported data/description ips ip version=v4 address=10.35.1.177/ ip version=v6 address=fe80::21a:4aff:fe16:151/ /ips /network_device which we should strive to maintain with this feature. Even if cloud-init is not currently capable of setting multiple addresses, let the API allow for it. Additionally, you should consider showing the vNIC name and not eth0 etc. IIUC udev rules are rather unpredictable in this regard and could give your vNIC a different name on different VM instances (probably by MAC address and/or PCI address). Either way, I think it's less confusing to refer to the vNIC itself. Similarly to the above, I'm not sure how much cloud-init supports with respect to vNICs. The name is used as the /etc/network/interfaces adapter name and the ifcfg-* suffix (per distro), so I guess if you plumbed everything around that in the image and could finish the setup with just the interfaces/ifcfg config file then it would work as-is. If that isn't adequate (I haven't looked or tested) then we may need to consider submitting a patch to add this to cloud-init. Either way, RHEV should not expose in its own interface the eth0 names that we cannot enforce within the guest. E.g., my Fedora has funny interface names such as em1 and wlp3s0, nothing like the good old eth*. 3. Is Support custom volume label for vm payloads still on the TODO list? Note: F19's dosfstools has renamed mkfs.msdos to mkfs.fat. This means that creating a virtual floppy with a payload currently does not work there (it's a tiny fix, for sure). It's implemented. Of course, it still uses mkfs.msdos. Implemented but not yet posted, I presume? Because upstream vdsm's does not use mkfs.msdos's -n. 4. I do not see ovirt-guest-agent mentioned in the feaure page. It is the obvious channel to report that cloud-init is Done to Engine. You're right, and this is one part of the feature that hasn't been done. It may also require some work on cloud-init, or for us to use a different input format (i.e. a mime-formatted sequence instead of vanilla config-drive-2). It would be great to add this, though my time to do that now is a bit limited. What
Re: [Engine-devel] Guest Reboot
On Jun 10, 2013, at 21:20 , David Jaša dj...@redhat.com wrote: Hi Martin, there may be more kinds of reboot in context of RHEV: warm reboot that keeps qemu process intact, or cold that would involve qemu process termination and start of new one - and this could be done with keeping of current configuration, or with applying settings that take effect after reboot that have changed during VM runtime; and all of these can be soft - when the guest OS reboots itself and hard when you perform the reboot right away. we plan to have 2 of them which seem to make most sense warm without applying config changes and keeping qemu process (i.e. also keeps Run Once,Stateless, pooled VM config/state) cold which kills qemu and is completely driven by Engine, and applies config changes and a policy option in VM properties to specify whether you should forcibly proceed with reboot/shutdown when graceful methods fail/timeout is there anything not covered for a typical user? We intentionally don't want to provide all possible options, just those making sense. The feature is about providing a convenient shortcut. Thanks, michal All of these have their use cases, so it should be documented what will you implement, and you may expect somebody asking you to implement the rest. ;) David Martin Betak píše v Pá 07. 06. 2013 v 12:32 -0400: Hi, engine-devel Customers request the ability to reboot a VM with a single click so I started designing the overall architecture and planing out the required changes to the respective components. You can find the wiki page for the initial draft at [1] and I would like to ask you for your input on my general design and potential issues that could arise in some corner cases. Please feel free to respond to this thread or add to the Issues section of [1]. Thanks in advance for your opinions :-) Martin [1] http://www.ovirt.org/Features/Guest_Reboot ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ 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] static header only in VM dialog?
On 31 May 2013, at 13:44, Einav Cohen wrote: - Original Message - From: Tomas Jelinek tjeli...@redhat.com Sent: Friday, May 31, 2013 2:22:57 AM - Original Message - From: Malini Rao m...@redhat.com To: Einav Cohen eco...@redhat.com Cc: Daniel Erez de...@redhat.com, Eldan Hildesheim i...@eldanet.com, engine-devel engine-devel@ovirt.org, Eldan Hildesheim ehild...@redhat.com, Tomas Jelinek tjeli...@redhat.com Sent: Thursday, May 30, 2013 5:56:59 PM Subject: 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,
Re: [Engine-devel] for a few clicks less
On May 22, 2013, at 14:21 , Itamar Heim ih...@redhat.com wrote: On 05/22/2013 03:19 PM, Laszlo Hornyak wrote: Hi, Today the default memory size when creating a VM is 512 MB, this is coming from the Blank template, which is not modifiable by user. This amount of memory is not enough for a installation for most Linux distros (and possibly for other mainstream OS either) so I think it would make sense to increase the default memory size to 1024 MB, for most users, it would save some time. This patch changes the memory size for new installations. http://gerrit.ovirt.org/14747 Roy is working on integration with osinfo which should give you the recommended memory size per OS type. short term for 3.3 your patch is probably better than nothing though:) Thx, Laszlo ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel makes sense to me. looking at the patch - worth handling upgrade as well? ___ 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] spice-xpi(firefox) plugin for Windows
On May 10, 2013, at 18:53 , David Jaša dj...@redhat.com wrote:
Hi,
writing from top of my head so this may not be 100 % accurate:
Dead Horse píše v Pá 10. 05. 2013 v 11:38 -0500:
I played a bit with the MIME and browsers.
When switching between spice/vnc/rdp protocols since the connection
file that comes down is extension .vv this is an issue. Once you
have associated a MIME type of .vv
one of the local clients (SPICE or VNC or RDP) the browser now thinks
that .vv files should be used with whatever it was associated with
only. This is to say should the extension be something different for
each protocol so each protocol could be used and associated with a
local client?
I guess that this exception should apply just for RDP because
{virt,remote}-viewer supports both spice and vnc AFAIK.
RDP is being worked on by Franta right now. It should make it for 3.3...
Also I have not yet been able to get RDP to work at all. On windows 7
systems under IE 9 is always greyed nor selectable (using latest
master). Using the connection files .vv and opening them with
remote-viewer to tight-vnc for example does not work at all.
Given ^^^ and that another vnc client would need to add the .vv file
format support, I don't think that it's a good idea
I have spice certificates and ssl disabled as well so that cannot get
in the way.
Unlike spice and vnc, rdp server is not provided by qemu but by VM
itself, so in order to make it work, engine must learn VM IP address
from RHEV Agent (so RHEV Agent service must be up'n'running in the VM)
and the VM must be configured to accept incoming RDP connections.
Because {virt,remote}-viewer doesn't support RDP (AFAIK) and no other
client has support for .vv files, I don't think that they should be
generated for rdp connection so if engine indeed generates the files,
that sound like a bug for me (for the time being, till
{virt,remote}-viewer gains RDP support or some rdp client gets .vv file
format support).
David
Any quick pointers on actually getting RDP to work or the connection
files to work with a local remote-viewer or vnc client?
- DHC
On Fri, Apr 19, 2013 at 3:08 AM, Michal Skrivanek
michal.skriva...@redhat.com wrote:
On 18 Apr 2013, at 17:57, Dead Horse wrote:
Nicely done and this would definitely be useful. Nothing is
more nauseating then being forced to use Internet Exploder
to interact with an ovirt/KVM SPICE console under windows.
For the plugin deployment this is definitely a point of
pain. At the moment ovirt users wishing to use the SPICE
Activex plugin must use an an dated version of the SPICE
client packaged with the necessary SpiceX.dll.
(http://elmarco.fedorapeople.org/spice.cab)
They must also take manual steps to install and deploy the
plugin on ovirt-engine server (this very painful to users).
The versions of the SPICE client also made available to the
community here: http://spice-space.org/download/gtk/windows/
are also a bit dated and do not include the plugin
(SpiceX.dll).
MIME file SPICE and VNC support is in oVirt master for couple
of weeks now. This should work on all browsers with latest
remote-viewer client.
Perhaps a plugin deployment page linked from the main ovirt
landing page would be a prudent way to deploy the plugin?
In any event a working SPICE Plugin for Firefox and newer
SPICE Client version under windows would be a very welcome
sight indeed.
definitely.
Another alternative planned for 3.3 is SPICE HTML5, it has
lots of limitations, but it's purely browser-based solution.
I think one of the most frequently asked questions or gripes
I see about ovirt is around SPICE console issues and
concerns.
indeed. And we'll have 3 solutions soon!:-)
Thanks,
michal
- DHC
On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau
cferg...@redhat.com wrote:
Hi everyone,
Lately I've been hacking on getting the spice-xpi
plugin to work on
Windows. This is the Firefox plugin that is used on
Linux to implement
the portal SPICE console.
This work has now been merged upstream (
http://cgit.freedesktop.org/spice/spice-xpi/ ), and
I've pushed a
scratch build using mingw available from
http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this
will go
away in several days). Copying this dll + its
dependencies to the
C:\Program Files\Mozilla Firefox\plugins directory
are enough to get
a spice-xpi plugin to show up in about:plugins, and
to then be able
to start a SPICE client from the spice-xpi test page
(
http://teuf.fedorapeople.org/plugins/test.html ).
The dependencies I had to copy are:
gspawn-win32-helper-console.exe
gspawn-win32-helper.exe
iconv.dll
Re: [Engine-devel] find-bugs errors - please investigate/fix
On Apr 24, 2013, at 07:49 , Sahina Bose sab...@redhat.com wrote: On 04/24/2013 07:47 AM, Einav Cohen wrote: ovirt find-bugs errors in jenkins - please investigate/fix asap. [@Eyal - FYI: some of them seem really strange - see Michal's section below] @Sahina Bose: find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-267688716/source.349621/#23 caused by: http://gerrit.ovirt.org/#/c/13831/ Have submitted a patch (http://gerrit.ovirt.org/#/c/14187/) fixing this. Thanks! @Michael Kublin: find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.-609324659/source.347305/#346 caused by: http://gerrit.ovirt.org/#/c/13740/ @Michal Skrivanek: the following seem strange - can you please investigate? could be false positives. - find-bugs error details: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/source.350390/#1349 [not sure when introduced - seems old, hence I suspect it is a false positive] - Two additional errors in the same file as ^^^, you can see them at: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-2082646592/ when clicking on them, there aren't any details, however according to their tool-tips, it seems to be an unreachable OnSuccess method within an anonymous class or something similar. - another suspicious error is in VmListModel.java: http://jenkins.ovirt.org/job/ovirt_engine_find_bugs/4064/findbugsResult/NORMAL/module.935532853/package.-1516395789/source.350485/#2406 [again - not sure when introduced - seems old, hence I suspect it is a false positive] Doesn't really seem to work correctly. Tooltip is talking about OnSuccess method for all mine above and it really doesn't seem to correspond with reality. Looks like findbugs is broken or confused Thanks, Einav ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] storage overallocation ratio
Hi, I was trying to find out how is this actually calculated. Doesn't look very straightforward…:) I'm curious about the following - vdsm reports something like truesize and apparentsize which IIUC should be distinct but then in engine, in backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java it's written to the same engine property actual_size. That doesn't sound right. Can someone enlighten me please? Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] spice-xpi(firefox) plugin for Windows
On 18 Apr 2013, at 17:57, Dead Horse wrote: Nicely done and this would definitely be useful. Nothing is more nauseating then being forced to use Internet Exploder to interact with an ovirt/KVM SPICE console under windows. For the plugin deployment this is definitely a point of pain. At the moment ovirt users wishing to use the SPICE Activex plugin must use an an dated version of the SPICE client packaged with the necessary SpiceX.dll. (http://elmarco.fedorapeople.org/spice.cab) They must also take manual steps to install and deploy the plugin on ovirt-engine server (this very painful to users). The versions of the SPICE client also made available to the community here: http://spice-space.org/download/gtk/windows/ are also a bit dated and do not include the plugin (SpiceX.dll). MIME file SPICE and VNC support is in oVirt master for couple of weeks now. This should work on all browsers with latest remote-viewer client. Perhaps a plugin deployment page linked from the main ovirt landing page would be a prudent way to deploy the plugin? In any event a working SPICE Plugin for Firefox and newer SPICE Client version under windows would be a very welcome sight indeed. definitely. Another alternative planned for 3.3 is SPICE HTML5, it has lots of limitations, but it's purely browser-based solution. I think one of the most frequently asked questions or gripes I see about ovirt is around SPICE console issues and concerns. indeed. And we'll have 3 solutions soon!:-) Thanks, michal - DHC On Wed, Apr 17, 2013 at 7:45 AM, Christophe Fergeau cferg...@redhat.com wrote: Hi everyone, Lately I've been hacking on getting the spice-xpi plugin to work on Windows. This is the Firefox plugin that is used on Linux to implement the portal SPICE console. This work has now been merged upstream ( http://cgit.freedesktop.org/spice/spice-xpi/ ), and I've pushed a scratch build using mingw available from http://koji.fedoraproject.org/koji/taskinfo?taskID=5265107 (this will go away in several days). Copying this dll + its dependencies to the C:\Program Files\Mozilla Firefox\plugins directory are enough to get a spice-xpi plugin to show up in about:plugins, and to then be able to start a SPICE client from the spice-xpi test page ( http://teuf.fedorapeople.org/plugins/test.html ). The dependencies I had to copy are: gspawn-win32-helper-console.exe gspawn-win32-helper.exe iconv.dll libffi-6.dll libgcc_s_sjlj-1.dll libgio-2.0-0.dll libglib-2.0-0.dll libgmodule-2.0-0.dll libgobject-2.0-0.dll libgthread-2.0-0.dll libintl-8.dll libstdc++-6.dll pthreadGC2.dll zlib1.dll (I picked them from the various mingw-* fedora packages). The reason for this email is that to be usable from oVirt, some portal changes are needed as it currently only tries to use the spice-xpi plugin on Linux platforms. Another fuzzy bit is how to get this plugin to the users' machines... And that's about all I had to say in that email ;) Let me know if that's useful to oVirt, how you want to integrate this, ... Cheers, Christophe ___ 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] Instance Types Feature
On Jan 28, 2013, at 17:57 , Yair Zaslavsky yzasl...@redhat.com wrote: Hi, Why are the flavors predefined, and not configured, or let's say that we provide predefined instance types, and let a way to provide custom instance types Our plan was to provide couple of predefined types and let user create own if needed. Custom means an extra type where you can specify anything when creating a VM (or use a template). A change to one of the instance type's parameter(say, mem size) will change the type to Custom while creating a VM. Otherwise the VM will be tied to its instance type and update to the instance type will be global and reflected in all relevant VMs. Thanks, michal Yair - Original Message - From: Tomas Jelinek tjeli...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, January 22, 2013 3:09:51 PM Subject: [Engine-devel] Instance Types Feature Hi All, this is the proposed new feature called instance types: http://www.ovirt.org/Features/Instance_Types Long story short - it should basically split the VM template into: - hardware profile called instance types - software profile called image This should enable to do something like: Create a new small VM and attach a disk with RHEL + Postgres installed. Any comments are more than welcome! Tomas ___ 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
[Engine-devel] SPICE IP override
Hi all, On behalf of Tomas - please check out the proposal for enhancing our SPICE integration to allow to return a custom IP/FQDN instead of the host IP address. http://wiki.ovirt.org/wiki/Features/Display_Address_Override All comments are welcome... Thanks, michal ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt on wikipedia
On 30 Oct 2012, at 06:48, Deepak C Shetty deepa...@linux.vnet.ibm.com wrote: Very nice, i did a minor grammatical edit as it the base for Red Hat Enterprise Virtualization. and it is the base for Red Hat Enterprise Virtualization. Also it would be good if the URL shows up as http://en.wikipedia.org/wiki/oVirt instead of OVirt I was not able to figure how to do that. It's a WikiWord, first letter needs to be uppercase I believe... better than Ovirt:) Thanks, michal On 10/29/2012 09:10 PM, Laszlo Hornyak wrote: Hi, http://en.wikipedia.org/wiki/OVirt At the moment there are OVirt pages in english, russian and hungarian. Any volunteers to write czech, hebrew, german, spanish, catalan? - just to mention the languages some ovirt-developers speak :-) Laszlo ___ 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] Unifying (parts of) commit templates.
On Aug 12, 2012, at 13:56 , Doron Fediuck wrote: - Original Message - From: Allon Mureinik amure...@redhat.com To: engine-devel@ovirt.org Sent: Sunday, August 12, 2012 11:17:19 AM Subject: Re: [Engine-devel] Unifying (parts of) commit templates. - Original Message - From: Livnat Peer lp...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel@ovirt.org Sent: Thursday, August 9, 2012 11:54:38 AM Subject: Re: [Engine-devel] Unifying (parts of) commit templates. On 09/08/12 11:52, Itamar Heim wrote: On 08/09/2012 09:11 AM, Livnat Peer wrote: On 09/08/12 00:41, Doron Fediuck wrote: Hi All, It seems that for commit subjects, vdsm is using a general concept of- BZ#??? some message I'd like to suggest adopting it to the engine template we use today- BZ#??? core | restapi | tools | history | engine | userportal | webadmin: short summary under 50 chars This may help us write some scripts which will work both for vdsm and engine BZs. Is is a problem adopting the same for all the projects? It would be nice to be really consistent everywhere. Is the core|restapi… really useful for anything? Many times its not easy to say which is the right one, things are shared between webadmin and portal, etc... In the past I found BZ #123456 - bug title on the first line to be the most helpful. Also it would imho be great if we get consistent tags for each build (or at least the commit ids) I know we are trying, but still its not really at the same time when the build is created. Thanks, michal +1 with a small change - adding a \n after the bz number - wouldn't this kill git shortlog? patch short summary must be in first line iirc yes it will. +1 for Doron's initial proposal +1. Also, while we're at it, a wiki explaining the correct way to use this template would be great. I know, it's pretty straight forward, but new contributed may get confused as to the distinction between core and engine, or how to mark a vertical patch that fixes a UI dialog and the backend logic behind it (with a coma between components? a slash? a pipe?) Patch submitted: http://gerrit.ovirt.org/#/c/7101/2 +2 is needed there. Wiki may take time, so anyone who's willing to spare some time, feel free to start with: git commit -s -F config/engine-commit-template.txt -e BZ#??? core | restapi | tools | history | engine | userportal | webadmin: short summary under 50 chars Long description of what this commit is about Livnat Doron. ___ 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 ___ 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] Adding VNC support
I've already expressed my inclination, but…:-) On Jul 31, 2012, at 08:18 , Itamar Heim wrote: On 07/26/2012 05:36 PM, snmis...@linux.vnet.ibm.com wrote: Hi, I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? so to sum this up: 1. there is the new dialog to open vnc manually. http://gerrit.ovirt.org/#/c/4790/ helps, but not really that friendly. In fact it sort of suggests we are not able to achieve a simple task of running an external app:) 2. Alon suggested it should be allowed to open this dialog for spice as well, not only for vnc. 3. Alon also suggested to have a launch button on that window (or parallel to it) which will try to launch vnc or spice by returning a specific mime type response, allowing client to choose the vnc/spice client to run for this mime type, and passing command line parameters to it in the mime type reply. I think this is reasonable result for little effort. It would allow to seamlessly open the connection for all other platforms we do not support today, Mac, iOS, it's quite easy to get a VNC on almost any platform as opposed to limited spiceclient support. 4. provide a vnc xpi/activex wrappers to allow launching it via web browsers like spice main limitation of this compared to novnc is you need to do this for every browser/platform. more effort than #3, too many browsers out there, and you have to install a plugin 5. novnc 5.1 novnc client - i'd start with the one recently pushed to fedora. https://bugzilla.redhat.com/show_bug.cgi?id=822187 5.2 novnc websocket server - i see three options 5.2.1 extend qemu to do this, so novnc can connect to it directly like we do today for vnc/spice 5.2.2 use the python based one from: https://bugzilla.redhat.com/show_bug.cgi?id=822187 5.2.3 look at a java based websocket solution, assuming easier to deploy it as part of webadmin/user portal war than another service (requires a bit of research) looking forward user portal and webadmin would be deployed on multiple hosts, so a websockets would need to be deployed next to them. from the little i looked at, the various websocket implementations are mostly nascent and are not scaleable/robust/etc. I'd love to be proven wrong, and worth playing with them a bit to measure that. and novnc client is still far less common than vnc. Having it in Fedora doesn't help much. 6. spice.html5 while very nascent - worth mentioning on this thread and trying to take a look: http://www.spice-space.org/page/Html5 more effort than #3, browser support questionable. I'd have doubts about performance on mobile devices even in the future ___ 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] Adding VNC support
On Jul 26, 2012, at 16:55 , Alon Bar-Lev wrote: On Thu, Jul 26, 2012 at 5:51 PM, Ewoud Kohl van Wijngaarden ewoud+ov...@kohlvanwijngaarden.nl wrote: On Thu, Jul 26, 2012 at 07:36:43AM -0700, snmis...@linux.vnet.ibm.com wrote: I am looking at adding VNC support in ovirt. What does the community think? Ideas, suggestions, comments? By that I think you mean adding VNC support to the java-based web interface. In that case +1. I can recommend noVNC[1], but you do need a websockets proxy. I can recommend VNCAuthProxy[2] as a programmable proxy with a JSON control channel. On the plus side all dependencies are in fedora/epel. Downside is no IPv6 support. Maybe you can also write a pure java implementation integrate this into the engine itself? [1]: http://kanaka.github.com/noVNC/ [2]: https://code.osuosl.org/projects/twisted-vncauthproxy/ Or launch client program via MIME bindings[1] both for Vnc and Spice. Not as neat as noVnc but will work in most scenarios, without having to maintain the actual console implementation. I would think there are many people out there who are not able to use current spice client, or not willing to(hate switching from chrome to firefox:-) Sure they can set up things manually but it would be way more convenient to allow a simple external launch of their VNC client of choice Regards, Alon. [1] https://bugzilla.redhat.com/show_bug.cgi?id=843410 ___ 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] java 1.6 compatibility no more?
On Jul 19, 2012, at 14:14 , Livnat Peer wrote: On 19/07/12 14:41, Juan Hernandez wrote: On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: On 07/19/2012 02:31 PM, Vojtech Szocs wrote: Don't we need that (the source part) to avoid Java 7 syntax in GWT code? That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech +1 - I really like this idea! +1 from me as well. There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them… There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both. Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it. Livnat - Original Message - From: Juan Hernandez jhern...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 10:09 AM, Vojtech Szocs wrote: As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Don't we need that (the source part) to avoid Java 7 syntax in GWT code? - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/18/2012 08:21 PM, Juan Hernandez wrote: On 07/18/2012 06:33 PM, Vojtech Szocs wrote: In fact, for both backend and frontend, Maven effective POM contains: artifactIdmaven-compiler-plugin/artifactId configuration source1.6/source target1.6/target /configuration Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used. The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). Vojtech As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes? - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: Vojtech Szocs vsz...@redhat.com Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more? Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo
Re: [Engine-devel] Separating engine-setup from ovirt-engine
On Jul 4, 2012, at 12:11 , Dan Kenigsberg wrote: On Wed, Jul 04, 2012 at 03:16:17AM -0400, Ofer Schreiber wrote: - Original Message - On Tue, Jul 03, 2012 at 06:20:43PM +0300, Michal Skrivanek wrote: On Jul 3, 2012, at 16:53 , Juan Hernandez wrote: On 07/03/2012 03:43 PM, Ofer Schreiber wrote: In our days, ovirt-engine-setup is a part of the big ovirt-engine rpm. This means that each time you need to build yourself a new ovirt-engine-setup rpm, you need to compile all the engine I'd expect that when you need a proper rpm then you have to go through all the pain and build everything from scratch to make it perfect. If you want to test something and debug, etc, you'd not build a full blown rpm anyway, would you? Well, either way, if you'd have 15 minutes for me I'd appreciate you show me how it's being done today…. thanks, michal Could this possibly be avoided by an optional flag to the build script? It's problematic, as ovirt-engine-setup is a sub rpm of ovirt-engine. I have no idea how can we just build the setup without the engine, which is compiled in a temporary directory (and removed straight after the build) I've started to think about separating it into another git (similar to ovirt-iso-uploader), so we will be able to build this rpm separately. This change is really easy to implement (actually, I have already done it locally), and sounds to me like it's the right thing to do. Thought? Ofer. I agree that is the right thing to do. Take into account that this also means that ovirt-engine-setup will no longer be a subpackage of ovirt-engine, so you will have to submit a new package request to have it included in Fedora. not quite sure having 10+ packages is a win… - why do you have to have a separate git? - why do you have to recompile when there's a change elsewhere? isn't that a matter of compilation scripts only? (though understand size of the rpm might be an issue…) I personally do not see a point in separating of something inseparable…but that's just me perhaps:) in other words, if you would kindly explain me the benefits please, I'll shut up:-) indeed - having another package, with its own release cycle and versioning scheme is quite costy. and isn't ovirt-engine-setup quite tightly coupled with Engine's db scheme? (I really do not know, I should probably shut up, too). Quite costly? why? It is another package to release, that requires its own errata process and inter-package dependencies. If you envisage a user that would like to use ovirt-engine-setup of one version, with an ovirt-setup of another one, then go ahead. I simply do not see the use case for this, only the complications. engine-setup is not tightly coupled with the db-scripts, we just execute the createDB script. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
