Re: [ovirt-devel] Test day 1 results
- Original Message - > From: "Martin Betak" > To: devel@ovirt.org > Sent: Wednesday, July 2, 2014 3:20:00 PM > Subject: [ovirt-devel] Test day 1 results > > Hi all, > > During the first test day I tested BZ 1108602 "Implement REST API for oVirt > scheduler". > Most basic CRUD operations via rest worked well, but there was a problem with > accessing > the subcollections 'filters', 'weights' and 'balances' of the > /api/schedulingpolicies > resource by id. > > For this a bug was filed under > https://bugzilla.redhat.com/show_bug.cgi?id=1115071 great work Martin! and thanks! http://gerrit.ovirt.org/#/c/29513/ http://gerrit.ovirt.org/#/c/29514/ gilad :-) > > Martin > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [libvirt] [RFC][scale] new API for querying domains stats
- Original Message - > From: "Francesco Romani" > To: "Daniel P. Berrange" > Cc: libvir-l...@redhat.com, devel@ovirt.org > Sent: Wednesday, July 2, 2014 6:41:28 PM > Subject: Re: [ovirt-devel] [libvirt] [RFC][scale] new API for querying > domains stats > > - Original Message - > > From: "Daniel P. Berrange" > > To: "Francesco Romani" > > Cc: libvir-l...@redhat.com > > Sent: Tuesday, July 1, 2014 10:35:21 AM > > Subject: Re: [libvirt] [RFC][scale] new API for querying domains stats > > > > [...] > > > We [in VDSM] currently use these APIs for our sempling: > > > virDomainBlockInfo > > > virDomainGetInfo > > > virDomainGetCPUStats > > > virDomainBlockStats > > > virDomainBlockStatsFlags > > > virDomainInterfaceStats > > > virDomainGetVcpusFlags > > > virDomainGetMetadata > > > > Why do you need to call virDomainGetMetadata so often ? That merely > > contains > > a opaque data blob that can only have come from VDSM itself, so I'm > > surprised > > you need to call that at all frequently. > > We store some QoS info in the domain metadata. Actually we can elide this API > call > from the list and fix our coude to make smarter use of it. > > > > please note that we are much more concerned about thread reduction then > > > about performance numbers. We had report of thread number becoming a > > > real harm, while performance so far is not yet a concern > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) > > > > > > * bulk APIs for querying domain stats > > > (https://bugzilla.redhat.com/show_bug.cgi?id=1113116) > > > would be really welcome as well. It is quite independent from the > > > previous bullet point > > > and would help us greatly with scale. > > > > If we did the first bullet point, we'd be adding another ~10 APIs for > > async variants. If we then did the second bullet point we'd be adding > > another ~10 APIs for bulk querying. So while you're right that they > > are independent, it would be desirable to address them both at the > > same time, so we only need to add 10 new APIs in total, not 20. > > I'm fine with this approach. > > > > For the async API design, I could see two potential designs > > > > 1. A custom callback to run per API > > > > typedef (void)(*virDomainBlockInfoCallback)(virDomainPtr dom, > > bool isError, > > virDomainBlockInfoPtr > > info, > > void *opaque); > > > > int virDomainGetBlockInfoAsync(virDomainPtr dom, > >const char *disk, > >virDomainBlockInfoCallback cb, > >void *opaque, > >unsigned int flags); > > > > > > 2. A standard callback and a pair of APIs > > > > typedef void *virDomainAsyncResult; > > typedef (void)(*virDomainAsyncCallback)(virDomainPtr dom, > > virDomainAsyncResult res); > > > >void virDomainGetBlockInfoAsync(virDomainPtr dom, > >const char *disk, > >virDomainBlockInfoCallback cb, > >void *opaque, > >unsigned int flags); > >int virDomainGetBlockInfoFinish(virDomainPtr dom, > > virDomainAsyncResult res, > > virDomainBlockInfoPtr info); > > > > This second approach is the way GIO works (see example in this page > > https://developer.gnome.org/gio/stable/GAsyncResult.html ). The main > > difference between them really is probably the way you get error > > reporting from the APIs. In the first example, libvirt would raise > > an error before it invoked the callback, with isError set to True. > > In the second example, the Finish() func would raise the error and > > return -1. > > I need to check in deeper detail and sync up with other VDSM developers, > but I have a feel that the first approach is a bit easier for VDSM to > consume. The first approach looks simpler - I assume that on error will get the callback with isError set to True, and we can get the error details within the callback? I would like to see an example of client code using this api in both success and error cases. Nir ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [libvirt] [RFC][scale] new API for querying domains stats
- Original Message - > From: "Daniel P. Berrange" > To: "Francesco Romani" > Cc: libvir-l...@redhat.com > Sent: Tuesday, July 1, 2014 10:35:21 AM > Subject: Re: [libvirt] [RFC][scale] new API for querying domains stats > [...] > > We [in VDSM] currently use these APIs for our sempling: > > virDomainBlockInfo > > virDomainGetInfo > > virDomainGetCPUStats > > virDomainBlockStats > > virDomainBlockStatsFlags > > virDomainInterfaceStats > > virDomainGetVcpusFlags > > virDomainGetMetadata > > Why do you need to call virDomainGetMetadata so often ? That merely contains > a opaque data blob that can only have come from VDSM itself, so I'm surprised > you need to call that at all frequently. We store some QoS info in the domain metadata. Actually we can elide this API call from the list and fix our coude to make smarter use of it. > > please note that we are much more concerned about thread reduction then > > about performance numbers. We had report of thread number becoming a > > real harm, while performance so far is not yet a concern > > (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) > > > > * bulk APIs for querying domain stats > > (https://bugzilla.redhat.com/show_bug.cgi?id=1113116) > > would be really welcome as well. It is quite independent from the > > previous bullet point > > and would help us greatly with scale. > > If we did the first bullet point, we'd be adding another ~10 APIs for > async variants. If we then did the second bullet point we'd be adding > another ~10 APIs for bulk querying. So while you're right that they > are independent, it would be desirable to address them both at the > same time, so we only need to add 10 new APIs in total, not 20. I'm fine with this approach. > For the async API design, I could see two potential designs > > 1. A custom callback to run per API > > typedef (void)(*virDomainBlockInfoCallback)(virDomainPtr dom, > bool isError, > virDomainBlockInfoPtr info, > void *opaque); > > int virDomainGetBlockInfoAsync(virDomainPtr dom, >const char *disk, >virDomainBlockInfoCallback cb, >void *opaque, >unsigned int flags); > > > 2. A standard callback and a pair of APIs > > typedef void *virDomainAsyncResult; > typedef (void)(*virDomainAsyncCallback)(virDomainPtr dom, > virDomainAsyncResult res); > >void virDomainGetBlockInfoAsync(virDomainPtr dom, >const char *disk, >virDomainBlockInfoCallback cb, >void *opaque, >unsigned int flags); >int virDomainGetBlockInfoFinish(virDomainPtr dom, > virDomainAsyncResult res, > virDomainBlockInfoPtr info); > > This second approach is the way GIO works (see example in this page > https://developer.gnome.org/gio/stable/GAsyncResult.html ). The main > difference between them really is probably the way you get error > reporting from the APIs. In the first example, libvirt would raise > an error before it invoked the callback, with isError set to True. > In the second example, the Finish() func would raise the error and > return -1. I need to check in deeper detail and sync up with other VDSM developers, but I have a feel that the first approach is a bit easier for VDSM to consume. Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] few notes from the scale setup
Hi, I'd like to share couple of observations on the scale system, just a few chaotic notes mostly for the documentation purposes:-) 4 socket, 8 core, HT -> 64 CPU samples has been taken in +- stable conditions 1) running 100VMs; top sample with collapsed process usage (all threads sum up) top - 15:00:48 up 5 days, 6:31, 1 user, load average: 2.25, 1.90, 2.05 Tasks: 1989 total, 4 running, 1983 sleeping, 1 stopped, 1 zombie Cpu(s): 4.7%us, 1.9%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 396900992k total, 80656384k used, 316244608k free, 156632k buffers Swap: 41148408k total,0k used, 41148408k free, 12225520k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 9057 vdsm0 -20 17.5g 482m 9m S 162.7 0.1 446:46.28 vdsm 8726 root 20 0 979m 17m 7996 R 135.6 0.0 68:56.42 libvirtd 36937 qemu20 0 1615m 296m 6328 S 59.2 0.1 0:19.18 qemu-kvm 38174 root 20 0 16496 2724 880 R 32.1 0.0 0:00.54 top 2458 qemu 20 0 1735m 533m 6328 S 11.1 0.1 2:38.87 qemu-kvm 10203 qemu 20 0 1736m 511m 6328 S 11.1 0.1 2:32.53 qemu-kvm 27774 qemu 20 0 1730m 523m 6328 S 11.1 0.1 2:22.36 qemu-kvm 25208 qemu 20 0 1733m 514m 6328 S 9.9 0.1 2:22.47 qemu-kvm 51594 qemu 20 0 1733m 650m 6328 S 9.9 0.2 3:53.42 qemu-kvm … etc [ this one's not from stable conditions, unfortunately, as can be seen by PID 36937] 2) running 185 VMs - all threads sum up. VDSM has 411 threads; load is much higher; also note high sys time top - 07:10:28 up 5 days, 22:41, 1 user, load average: 19.10, 14.28, 13.17 Tasks: 2318 total, 9 running, 2308 sleeping, 0 stopped, 1 zombie Cpu(s): 10.8%us, 21.0%sy, 0.0%ni, 67.8%id, 0.1%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 396900992k total, 157267616k used, 239633376k free, 175700k buffers Swap: 41148408k total,0k used, 41148408k free, 12669856k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 9057 vdsm 0 -20 30.1g 856m 10m S 883.4 0.2 9818:59 vdsm 8726 root 20 0 975m 19m 7996 R 142.4 0.0 1370:15 libvirtd 19542 root 20 0 16700 3108 1020 R 15.1 0.0 0:18.11 top 17614 qemu 20 0 1730m 692m 6328 S 6.5 0.2 49:05.53 qemu-kvm 55545 qemu 20 0 1732m 708m 6328 S 6.3 0.2 48:42.01 qemu-kvm 28542 qemu 20 0 1724m 696m 6328 S 6.2 0.2 44:44.50 qemu-kvm 12482 qemu 20 0 1738m 822m 6328 S 6.0 0.2 51:02.71 qemu-kvm
Re: [ovirt-devel] github projects moved to gerrit
On Wed, Jul 02, 2014 at 07:43:34AM -0400, Saggi Mizrahi wrote: > Hi, we moved all of our stuff from github to > ovirt.gerrit.org. > > If you had pending pull-requests for: > * ioprocess > * cpopen > * pthreading > > Please resend them on Gerrit. Thanks! I appreciate it. > > Don't forget to update your git/config. > > ssh://gerrit.ovirt.org:29418/pthreading > ssh://gerrit.ovirt.org:29418/ioprocess > ssh://gerrit.ovirt.org:29418/cpopen > > Bugzilla components will be opened shortly ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Test day 1 results
Hi all, During the first test day I tested BZ 1108602 "Implement REST API for oVirt scheduler". Most basic CRUD operations via rest worked well, but there was a problem with accessing the subcollections 'filters', 'weights' and 'balances' of the /api/schedulingpolicies resource by id. For this a bug was filed under https://bugzilla.redhat.com/show_bug.cgi?id=1115071 Martin ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] github projects moved to gerrit
Hi, we moved all of our stuff from github to ovirt.gerrit.org. If you had pending pull-requests for: * ioprocess * cpopen * pthreading Please resend them on Gerrit. Don't forget to update your git/config. ssh://gerrit.ovirt.org:29418/pthreading ssh://gerrit.ovirt.org:29418/ioprocess ssh://gerrit.ovirt.org:29418/cpopen Bugzilla components will be opened shortly ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.5 test day 1 results
nice test, Nir. would you mind adding the important bugs to 3.5 tracker [1]? I'd agree that not being able to upgrade without removal of all hosts and vms is a blocker for a release:-) others seem to be quite important too Thanks, michal [1] http://bugzilla.redhat.com/1073943 On Jul 1, 2014, at 20:31 , Nir Soffer wrote: > Hi all, > > I tested today [RFE] replace XML-RPC communication (engine-vdsm) with > json-rpc based on bidirectional transport > > First I upgraded ovirt-3.4 stable engine to ovirt-3.5 - ok > Then I upgraded 4 hosts to latest vdsm - ok > > I upgraded 2 data centers to cluster version 3.5: > - 2 Fedora 19 hosts with 30 ISCSI storage domains - ok > - 2 RHEL 6.5 hosts with 45 NFS storage domains - failed > I had to remove the hosts and the virtual machines to complete > the upgrade [1] > > Then I removed the hosts and added them back (to configure jsonrpc), and > setup one host using jsonrpc and the other using xmlrpc - ok > > After moving the hosts to maintenance mode and starting them back, I found > that the host using jsonrpc was stuck in "Unassigned" state [2],[3]. > > The errors in the vdsm log were not clear enough. After I improving this [4], > I could fix it in one line patch [5]. > > Finally when I had a working system, I run some sanity tests: > - start/stop vm - ok > - create vm from template - ok > - migrate vms between two hosts concurrenly (one host use xmlrpc, one using > json) - ok > > Then I tried to test create template from vm, but I had low disk space > on that storage domain. So I tried to extend the domain which would be > useful test as well. > > But turns out that you cannot create or edit a block domain when using > jsonrpc [6] > > Looking at the logs, I found also that shutting down protocol detector fails > [7] > > Summary: > > - upgrade is broken in some cases - critical > - jsonrpc is not ready yet > - jsonrpc needs lot of additional testing - for next test day I suggest one > tester > from each team (virt, storage, networking, sla?) to test jsonrpc with > relevant > flows. > > [1] https://bugzilla.redhat.com/1114994 >Cannot edit cluster after upgrade from version 3.4 to 3.5 because cpu type > (Intel Haswell) does not match > > [2] https://bugzilla.redhat.com/1115033 >StoragePool_disconnect: disconnect() takes exactly 4 arguments > > [3] https://bugzilla.redhat.com/1115044 >Host stuck in "Unassinged" state when using jsonrpc and disconnection from > pool failed > > [4] http://gerrit.ovirt.org/29457 >bridge: Show more info when method call fail > > [5] http://gerrit.ovirt.org/29465 >api: Make remove optional > > [6] https://bugzilla.redhat.com/show_bug.cgi?id=1115152 >Cannot edit or create block storage doamin when using jsonrpc > > [7] https://bugzilla.redhat.com/1115104 >Shuting down protocol detector fails > > Nir > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [test day] day 1 results
Hi, during the test day I should test https://bugzilla.redhat.com/show_bug.cgi?id=1108599 - OVIRT35 - [RFE] [spice-html5] spice-html5 js client is dumb: no error about network connection issue However I wasn't able to get a working test plant due to network troubles. I'm on fully virtualized setup with two fedora 19 VM on KVM with nested virtualization. Engine got installed correctly on the first host but I wasn't able to add the second VM as an hypervisor. Trying to do that network connectivity get lost on the second VM. I tried more than once always with the same result. I opened a bug for that: https://bugzilla.redhat.com/show_bug.cgi?id=1115420 Still not comment on the spice-html5 feature cause I'm still not able to test it. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] test day upgrade failure
On Wed, Jul 02, 2014 at 05:28:24AM -0400, Eli Mesika wrote: > > > - Original Message - > > From: "Dan Kenigsberg" > > To: devel@ovirt.org, emes...@redhat.com > > Sent: Wednesday, July 2, 2014 11:27:19 AM > > Subject: test day upgrade failure > > > > For the test day I've tried to upgrade my ovirt-engine-3.4.2-1.el6.noarch to > > 3.5 beta. > > I've encountered > > > > psql:/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:2: > > ERROR: constraint "fk_event_subscriber_event_notification_methods" of > > relation "event_subscriber" does not exist > > FATAL: Cannot execute sql command: > > --file=/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql > > > > 2014-07-02 09:16:13 DEBUG otopi.context context._executeMethod:152 method > > exception > > Traceback (most recent call last): > > File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in > > _executeMethod > > method['method']() > > File > > > > "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", > > line 291, in _misc > > oenginecons.EngineDBEnv.PGPASS_FILE > > File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in > > execute > > command=args[0], > > RuntimeError: Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed > > to > > execute > > 2014-07-02 09:16:13 ERROR otopi.context context._executeMethod:161 Failed to > > execute stage 'Misc configuration': Command > > '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute > > > > Is this failure known? What is the remedy? > > Hi Dan > > I had created a 3.4.2 DB and upgraded it to 3.5 with no issues > fk_event_subscriber_event_notification_methods FK is created when creating > the initial base tales and nothing drops it except the failing upgrade script. > > I assume that a manual operation had dropped this FK on your DB, please try > to run the following before teh upgrade on your 3.4.2 DB and after that try > to upgrade again > > ALTER TABLE ONLY event_subscriber > ADD CONSTRAINT fk_event_subscriber_event_notification_methods FOREIGN KEY > (method_id) REFERENCES event_notification_methods(method_id) ON DELETE > CASCADE; How can I tell that I'm on the right DB? The refered table event_notification_methods seems to be missing. # su - postgres -bash-4.1$ psql engine psql (8.4.20) Type "help" for help. engine=# ALTER TABLE ONLY event_subscriber engine-# ADD CONSTRAINT fk_event_subscriber_event_notification_methods FOREIGN KEY (method_id) REFERENCES event_notification_methods(method_id) ON DELETE CASCADE; ERROR: relation "event_notification_methods" does not exist ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Github Repositories
On Wed 02 Jul 2014 11:26:08 AM CEST, Saggi Mizrahi wrote: > For all those complaining about those projects not being on Gerrit. > > I can't create a gerrit-project or set my own policy for it. > There is no open-source bug tracker so I have to wait until I > get a fedora package and even than it's less than ideal. > There is no place to put package documentation. Gerrit, unlike > github has no "welcome page", It's important for us in to have > that short explanation alongside the package. You can always use the README file. That's what github shows anyhow. > > In short, it's just simpler for me to get a github project up and > running than talking to numerous people about setting everything > set up. > > But, since it appears that there is a strong discontent towards that > way of doing thing I'll work with the respective parties to get > things setup on gerrit. Send email to in...@ovirt.org ccing Itamar with the name proposed for the repo and the acl, once the name is agreed upon we'll create a ticket with the info and solve it (it's easy to do, so it should not take too much time to get it), including mirrors on github under ovirt organization (https://github.com/ovirt), where you can see the 'welcome page' if you like. > > - Original Message - >> From: "Ewoud Kohl van Wijngaarden" >> To: "Roy Golan" >> Cc: devel@ovirt.org >> Sent: Wednesday, June 18, 2014 12:25:11 PM >> Subject: Re: [ovirt-devel] Github Repositories >> >> On Wed, Jun 18, 2014 at 11:51:20AM +0300, Roy Golan wrote: >>> On 06/17/2014 02:31 AM, Nir Soffer wrote: - Original Message - > From: "Eyal Edri" > To: "Saggi Mizrahi" > Cc: devel@ovirt.org > Sent: Sunday, June 15, 2014 4:40:33 PM > Subject: Re: [ovirt-devel] Github Repositories > > why not use gerrit.ovirt.org and mirror to github? +1 >>> >>> +1 >>> >>> can the mirror be attached to a newly created oVirt organization? >> >> We already have https://github.com/ovirt with mirrors. Wouldn't that be >> better? >> > - Original Message - >> From: "Saggi Mizrahi" >> To: devel@ovirt.org >> Sent: Sunday, June 15, 2014 1:29:34 PM >> Subject: [ovirt-devel] Github Repositories >> >> We are moving all ovirt stuff from my own user to >> the newly created ovirt-infra group on github. >> >> Update your git remotes! >> >> https://github.com/ovirt-infra >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] test day upgrade failure
- Original Message - > From: "Dan Kenigsberg" > To: devel@ovirt.org, emes...@redhat.com > Sent: Wednesday, July 2, 2014 11:27:19 AM > Subject: test day upgrade failure > > For the test day I've tried to upgrade my ovirt-engine-3.4.2-1.el6.noarch to > 3.5 beta. > I've encountered > > psql:/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:2: > ERROR: constraint "fk_event_subscriber_event_notification_methods" of > relation "event_subscriber" does not exist > FATAL: Cannot execute sql command: > --file=/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql > > 2014-07-02 09:16:13 DEBUG otopi.context context._executeMethod:152 method > exception > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in > _executeMethod > method['method']() > File > > "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", > line 291, in _misc > oenginecons.EngineDBEnv.PGPASS_FILE > File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in > execute > command=args[0], > RuntimeError: Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to > execute > 2014-07-02 09:16:13 ERROR otopi.context context._executeMethod:161 Failed to > execute stage 'Misc configuration': Command > '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute > > Is this failure known? What is the remedy? Hi Dan I had created a 3.4.2 DB and upgraded it to 3.5 with no issues fk_event_subscriber_event_notification_methods FK is created when creating the initial base tales and nothing drops it except the failing upgrade script. I assume that a manual operation had dropped this FK on your DB, please try to run the following before teh upgrade on your 3.4.2 DB and after that try to upgrade again ALTER TABLE ONLY event_subscriber ADD CONSTRAINT fk_event_subscriber_event_notification_methods FOREIGN KEY (method_id) REFERENCES event_notification_methods(method_id) ON DELETE CASCADE; > > Dan. > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [test day] day 1 results
Hi all, During Test Day 1 I have tested https://bugzilla.redhat.com/show_bug.cgi?id=1090511 ([RFE] Improve fencing robustness by retrying failed attempts). Since did not have a HW with fencing device, tested how does it behave if trying to fence when the device is not present. This flows fail on class cast exceptions (BZ posted by Juan: https://bugzilla.redhat.com/show_bug.cgi?id=1114977). Other than that tested the UP/WA basic functions in various browsers, found out that WA does not load on IE9, posted a BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1114863 Tomas ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Github Repositories
For all those complaining about those projects not being on Gerrit. I can't create a gerrit-project or set my own policy for it. There is no open-source bug tracker so I have to wait until I get a fedora package and even than it's less than ideal. There is no place to put package documentation. Gerrit, unlike github has no "welcome page", It's important for us in to have that short explanation alongside the package. In short, it's just simpler for me to get a github project up and running than talking to numerous people about setting everything set up. But, since it appears that there is a strong discontent towards that way of doing thing I'll work with the respective parties to get things setup on gerrit. - Original Message - > From: "Ewoud Kohl van Wijngaarden" > To: "Roy Golan" > Cc: devel@ovirt.org > Sent: Wednesday, June 18, 2014 12:25:11 PM > Subject: Re: [ovirt-devel] Github Repositories > > On Wed, Jun 18, 2014 at 11:51:20AM +0300, Roy Golan wrote: > > On 06/17/2014 02:31 AM, Nir Soffer wrote: > > >- Original Message - > > >>From: "Eyal Edri" > > >>To: "Saggi Mizrahi" > > >>Cc: devel@ovirt.org > > >>Sent: Sunday, June 15, 2014 4:40:33 PM > > >>Subject: Re: [ovirt-devel] Github Repositories > > >> > > >>why not use gerrit.ovirt.org and mirror to github? > > >+1 > > > > +1 > > > > can the mirror be attached to a newly created oVirt organization? > > We already have https://github.com/ovirt with mirrors. Wouldn't that be > better? > > > >>- Original Message - > > >>>From: "Saggi Mizrahi" > > >>>To: devel@ovirt.org > > >>>Sent: Sunday, June 15, 2014 1:29:34 PM > > >>>Subject: [ovirt-devel] Github Repositories > > >>> > > >>>We are moving all ovirt stuff from my own user to > > >>>the newly created ovirt-infra group on github. > > >>> > > >>>Update your git remotes! > > >>> > > >>>https://github.com/ovirt-infra > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [test day] day 1 results
Hi, During the day 1 I tested http://www.ovirt.org/Features/WebSocketProxy_on_a_separate_host Found a couple of minor issues, due to packaging glitches and wiki page not up to date. https://bugzilla.redhat.com/show_bug.cgi?id=1114920 https://bugzilla.redhat.com/show_bug.cgi?id=1114978 besides that the feature seems to work nicely -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] test day upgrade failure
For the test day I've tried to upgrade my ovirt-engine-3.4.2-1.el6.noarch to 3.5 beta. I've encountered psql:/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql:2: ERROR: constraint "fk_event_subscriber_event_notification_methods" of relation "event_subscriber" does not exist FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/03_05_0050_event_notification_methods.sql 2014-07-02 09:16:13 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 291, in _misc oenginecons.EngineDBEnv.PGPASS_FILE File "/usr/lib/python2.6/site-packages/otopi/plugin.py", line 871, in execute command=args[0], RuntimeError: Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute 2014-07-02 09:16:13 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute Is this failure known? What is the remedy? Dan. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
