Re: [ovirt-devel] Unstable network connections after installing vdsm
- Original Message - From: Nir Soffer nsof...@redhat.com To: Adam Litke ali...@redhat.com Cc: devel@ovirt.org, asegu...@redhat.com Sent: Monday, November 10, 2014 9:40:39 PM Subject: Re: [ovirt-devel] Unstable network connections after installing vdsm - Original Message - From: Adam Litke ali...@redhat.com To: devel@ovirt.org Sent: Monday, November 10, 2014 4:34:02 PM Subject: [ovirt-devel] Unstable network connections after installing vdsm I've been experiencing peculiar and annoying networking behavior on my oVirt development hosts and I'm hoping someone familiar with vdsm networking configuration can help me get to the bottom of it. My setup is two mini-Dells acting as virt hosts and ovirt engine running on my laptop. The dells get their network config from a cobbler instance running on my laptop which also provides PXE services. After freshly installing the dells, I get a nice, stable network connection. After installing vdsm, the connection seems to drop occasionally. I have visit the machine, log into the console, and execute 'dhclient ovirtmgmt'. This fixes the problem again for awhile. Sounds like an issue I have on Fedora 20 and RHEL 7 hosts. Antoni told me this is a known issue, and hopefully he can point us to the relevant bug. Yes. It is a bug in /sbin/dhclient-script https://bugzilla.redhat.com/show_bug.cgi?id=1116004 Does this sound like anything someone has seen before? What would be the best way to start debugging/diagnosing this issue? Thanks in advance for your responses. -- Adam Litke ___ 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] vdsm make rpm make check on fe vs el
- Original Message -
From: Francesco Romani from...@redhat.com
To: devel@ovirt.org
Sent: Monday, October 27, 2014 12:20:17 PM
Subject: Re: [ovirt-devel] vdsm make rpm make check on fe vs el
- Original Message -
From: Nir Soffer nsof...@redhat.com
To: Francesco Romani from...@redhat.com
Cc: devel@ovirt.org, Mooli Tayer mta...@redhat.com
Sent: Monday, October 27, 2014 12:16:11 PM
Subject: Re: [ovirt-devel] vdsm make rpm make check on fe vs el
[...]
I've also saw a different numbers of tests running for make rpm on
el.
I have seen this on several 6.5 machines - make rpm on does *not* run
the tests.
It would be nice if take a look at this.
It was made on purposes:
# Skips check since rhel default repos lack pep8 and pyflakes
%if ! 0%{?rhel}
%global with_check 1
%endif
http://gerrit.ovirt.org/#/c/29213/
I believe time has come for a more robust solution
As first aid, we should log something like Skipping tests because ...
in this case.
I think we need to change that so we disable only pep8 in make rpm.
Nir
+1
we can afford to skip local checks (pep8/pyflakes), but the core test suite
should run
anyway.
I'll post a patch today(ish) if noone is faster/disagrees with the above :)
I don't think the tests should run on make rpm. In make check, sure. In make
rpm...
It's a last resort for making people realize something is broken when they are
not
running make check.
--
Francesco Romani
RedHat Engineering Virtualization R D
Phone: 8261328
IRC: fromani
___
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] [ACTION NEEDED] Please fix vdsm build dependencies on master
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: devel@ovirt.org Sent: Monday, September 15, 2014 1:11:16 PM Subject: [ovirt-devel] [ACTION NEEDED] Please fix vdsm build dependencies on master Hi, looks like VDSM is missing python-ethtool as BuildRequire on EL6 and FC20: Master doesn't have any more dependency for it. Only vdsm-bootstrap, which still has it on the vdsm.spec.in. I'll look at the log. http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-fc20_created/352/artifact/exported-artifacts/build.log http://jenkins.ovirt.org/job/vdsm_master_install-rpm-sanity-el6_created/368/artifact/exported-artifacts/build.log Please fix. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ 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] Testday: json rpc
Hi fellow oVirters,
On this test day I picked JSON RPC for testing:
My initial environment consisted of a hosted engine setup with three hosts.
Upgrading
===
The first task, then, was to upgrade everything to 3.5.
My guide was http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine
One issue that I encountered was that after setting the 3.5 pre-release yum
repo on the engine VM and doing yum update, when doing
engine-setup
To make it handle the upgrade, that failed complaining about missing a package
called patternfly1. I remembered that on the list Greg Sheremeta mentioned a
copr repository for it, so I went ahead, installed it and repeated the
engine-setup
This time it succeeded, however I feel like patternfly1 should probably be an
ovirt-engine-3.5 dependency and it should be in the ovirt 3.5 repository.
I also noticed that after upgrading the hosts the amount of free system memory
is much lower, while the VMs continue to run fine. I opened:
https://bugzilla.redhat.com/1124451
Another thing that happened was that restarting ovirt-ha-agent and
ovirt-ha-broker using systemd fails silently and it says that they were killed.
I only got it to work again by doing:
/lib/systemd/systemd-ovirt-ha-broker restart
/lib/systemd/systemd-ovirt-ha-agent restart
However, and obviously, doing it like that escapes from the advisable control
of systemd. Another bad thing is that after doing all this we get that the
current host (which has the engine running displays):
--== Host 2 status ==--
Status up-to-date : False
Hostname : 10.34.63.180
Host ID: 2
Engine status : unknown stale-data
Score : 2000
Local maintenance : False
Host timestamp : 1406640293
Extra metadata (valid at timestamp):
metadata_parse_version=1
metadata_feature_version=1
timestamp=1406640293 (Tue Jul 29 15:24:53 2014)
host-id=2
score=2000
maintenance=False
bridge=True
cpu-load=0.0856
engine-health={health: good, vm: up, detail: up}
gateway=True
mem-free=3192
Why did the engine status go to unknown stale-data? (it also happened for the
other two hosts in the setup.
Changing hosts to use JSON RPC
===
After talking with Piotr and trying it with the webadmin UI, I found out that
there is no direct way to update a host's settings to use json rpc as its
connectivity mechanism with the engine. This constitutes a usabiltiy bug
which I filed:
https://bugzilla.redhat.com/1124442
It is presumable that users will want to move to the newer and better RPC
mechanism and they should be able to do so by merely putting the host in
maintenance and ticking some checkbox in the 'edit host' dialog.
I did the workaround of removing the host and adding it again and that worked,
the host went up.
Network operations via JSON RPC
After the host went up, I decided to send a setupNetworks command. The
operation worked out fine, but unfortunately we have a very serious gap that
makes it impossible for me to use jsonrpc for network operations/development.
**Logging**
When doing a network operation with xmlrpc we'd get the following in vdsm.log
Thread-21::DEBUG::2014-07-30
13:38:11,414::BindingXMLRPC::1127::vds::(wrapper) client [10.34.61.242]::call
setupNetworks with ({'10': {'nic': 'em2', 'vlan': '10', 'STP': 'no', 'bridged':
'true', 'mtu': '1500'}}, {}, {'connectivityCheck': 'true',
'connectivityTimeout': 120}) {} flowID [686033d4]
Thread-21::DEBUG::2014-07-30
13:38:32,689::BindingXMLRPC::1134::vds::(wrapper) return setupNetworks with
{'status': {'message': 'Done', 'code': 0}}
As you can see, we get the bare minimum logging one could ask for, an entry
with the command called and the data it received and another entry with the
return result data.
Doing the same with jsonrpc (and ignoring the excessive IOProcess) if I search
for setupNetworks the only thing I get is:
Thread-23057::DEBUG::2014-07-30
13:32:44,126::__init__::462::jsonrpc.JsonRpcServer::(_serveRequest) Looking for
method 'Host_setupNetworks' in bridge
And if I search for the data received, like 'STP', there is nothing whatsoever.
As I said, unless this is fixed and we get entries with the same amount of data
as before, it can't be used in production nor in development.
https://bugzilla.redhat.com/1124813
TL;DR:
- lack of usability upgrading an environment to use jsonrpc
https://bugzilla.redhat.com/1124442
- Failure on step 7 of upgrade steps:
https://bugzilla.redhat.com/1124826
- JSON RPC logging excessive but insuficient for network call debugging
https://bugzilla.redhat.com/1124813
___
Devel mailing list
Devel@ovirt.org
Re: [ovirt-devel] [ovirt-users] Testday: json rpc
- Original Message -
From: Francesco Romani from...@redhat.com
To: Antoni Segura Puimedon asegu...@redhat.com
Cc: devel@ovirt.org, users us...@ovirt.org
Sent: Wednesday, July 30, 2014 2:59:37 PM
Subject: Re: [ovirt-users] Testday: json rpc
- Original Message -
From: Antoni Segura Puimedon asegu...@redhat.com
To: devel@ovirt.org, users us...@ovirt.org
Sent: Wednesday, July 30, 2014 2:15:36 PM
Subject: [ovirt-users] Testday: json rpc
[...]
**Logging**
When doing a network operation with xmlrpc we'd get the following in
vdsm.log
Thread-21::DEBUG::2014-07-30
13:38:11,414::BindingXMLRPC::1127::vds::(wrapper) client
[10.34.61.242]::call setupNetworks with ({'10': {'nic': 'em2', 'vlan':
'10', 'STP': 'no', 'bridged': 'true', 'mtu': '1500'}}, {},
{'connectivityCheck': 'true', 'connectivityTimeout': 120}) {} flowID
[686033d4]
Thread-21::DEBUG::2014-07-30
13:38:32,689::BindingXMLRPC::1134::vds::(wrapper) return setupNetworks
with {'status': {'message': 'Done', 'code': 0}}
As you can see, we get the bare minimum logging one could ask for, an entry
with the command called and the data it received and another entry with the
return result data.
Doing the same with jsonrpc (and ignoring the excessive IOProcess) if I
search
for setupNetworks the only thing I get is:
Thread-23057::DEBUG::2014-07-30
13:32:44,126::__init__::462::jsonrpc.JsonRpcServer::(_serveRequest)
Looking for method 'Host_setupNetworks' in bridge
And if I search for the data received, like 'STP', there is nothing
whatsoever.
As I said, unless this is fixed and we get entries with the same amount of
data
as before, it can't be used in production nor in development.
https://bugzilla.redhat.com/1124813
Can you share some VDSM logs? Attaching them to BZ would be super.
Good point, I'll do that now.
I'd like to check if that applies to virt flows as well - as I actually tend
to believe.
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
Re: [ovirt-devel] ovirt-engine-3.5 branching
- Original Message - From: Allon Mureinik amure...@redhat.com To: Oved Ourfali ov...@redhat.com Cc: Piotr Kliczewski pklic...@redhat.com, devel@ovirt.org Sent: Thursday, July 3, 2014 4:57:55 PM Subject: Re: [ovirt-devel] ovirt-engine-3.5 branching I concur. There are too many flows broken on /master/ to consider the 3.5 branch anything remotely near stable. Wouldn't it be better to keep the current branch as stabilization branch and test extensively every patch that goes into it instead of keeping adding to the master branch and rebranch and then have the same or similar happen in the next test day? If I remember correctly in the previous release cycle something similar happened in the engine an teams tried to push non critical or stabilization patches after feature freeze. At the time, it was argued that this release cycle it would be branch and backport. I realize, of course, that it is painstaking to backport a great amount of patches, but this is a direct result of letting features get merged too late in the cycle and before being up to a certain standard of stability. I would say let this backporting frenzy be a lesson to all to be more conservative with the timelines in the next cycle but I understand the other side of the argument, so maybe instead we should just count with an extra week between freeze and branching (note that this will delay review and merge of work on master for the next feature reducing the chances of big features being merged early-middle cycle. wrt to holding off 3.6 features, I can confirm that from the storage side nothing has been merged, and we can keep holding them back. -Allon - Original Message - From: Oved Ourfali ov...@redhat.com To: devel@ovirt.org Cc: Piotr Kliczewski pklic...@redhat.com Sent: Thursday, July 3, 2014 5:31:43 PM Subject: [ovirt-devel] ovirt-engine-3.5 branching Hi all, The test day revealed a large amount of issues. These issues are being addressed in the last few days. To avoid the need to back-port each and every one of them to the ovirt-engine-3.5 stable branch, I suggest to give a few days for that effort, and revisit it on mid next week, to asses it again and decide whether to do the branching then. I ask the different maintainers not to push 3.6 relevant material into master in the next few days, until the branching is done. To my knowledge no major (or any) patch related to 3.6 has been merge on master, but please correct me if I'm wrong. Thanks all for your efforts in stabilizing the version. Regards, Oved ___ 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [VDSM] Re: XML benchmarks
- Original Message - From: Francesco Romani from...@redhat.com To: devel@ovirt.org Sent: Friday, June 27, 2014 2:43:01 PM Subject: [ovirt-devel] [VDSM] Re: XML benchmarks Of course this is VDSM-only, I tend to forget the tag, sorry. Bests, - Original Message - From: Francesco Romani from...@redhat.com To: devel@ovirt.org Sent: Friday, June 27, 2014 2:30:14 PM Subject: [ovirt-devel] XML benchmarks Hi, Due to the recent discussion (http://gerrit.ovirt.org/#/c/28712/), and as part of the ongoing focus on scalability and performances (http://gerrit.ovirt.org/#/c/17694/ and many others), I took the chance to do a very quick and dirty bench to see how it really cost to do XML processing in sampling threads (thanks to Nir for the kickstart!), and, in general, how much the XML processing costs. Please find attached the test script and the example XML (real one made by VDSM master on my RHEL6.5 box). On my laptop: $ lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order:Little Endian CPU(s):4 On-line CPU(s) list: 0-3 Thread(s) per core:2 Core(s) per socket:2 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family:6 Model: 58 Model name:Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Stepping: 9 CPU MHz: 1359.375 CPU max MHz: 3600. CPU min MHz: 1200. BogoMIPS: 5786.91 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 4096K NUMA node0 CPU(s): 0-3 8 GiBs of RAM, running GNOME desktop and the usual development stuff xmlbench.py linuxvm1.xml MODE 300 MODE is either 'md' (minidom) or 'cet' (cElementTree). This will run $NUMTHREADS threads fast and loose without synchronization. We can actually have this behaviour if a customer just mass start VMs. In general I expect some clustering of the sampling activity, not a nice evenly interleaved time sequence. CPU measurement: just opened a terminal and run 'htop' on it. CPU profile: clustered around the sampling interval. Usage negligible most of time, peak on sampling as shown below 300 VMs minidom: ~38% CPU cElementTree: ~5% CPU 500 VMs minidom: ~48% CPU cElementTree: ~6% CPU 1000 VMs python thread error :) File /usr/lib64/python2.7/threading.py, line 746, in start _start_new_thread(self.__bootstrap, ()) thread.error: can't start new thread I think this is another proof (if we need more of them) that * we _really need_ to move away from the 1 thread per VM model - http://gerrit.ovirt.org/#/c/29189/ and friends! Let's fire up the discussion! I'm all for this. * we should move to cElementTree anyway in the near future: faster processing, scales better, nicer API. It is also a pet peeve of mine, I do have some patches floating but we need still some preparation work in the virt package. Agreed! -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani ___ 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] multipath configuration
- Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: Nir Soffer nsof...@redhat.com, devel@ovirt.org Sent: Friday, June 27, 2014 3:10:51 PM Subject: Re: [ovirt-devel] multipath configuration - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Nir Soffer nsof...@redhat.com Cc: Federico Simoncelli fsimo...@redhat.com, devel@ovirt.org Sent: Friday, June 27, 2014 2:57:59 PM Subject: Re: [ovirt-devel] multipath configuration - Original Message - From: Nir Soffer nsof...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: devel@ovirt.org Sent: Friday, June 27, 2014 2:12:50 PM Subject: Re: [ovirt-devel] multipath configuration - Original Message - From: Federico Simoncelli fsimo...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: devel@ovirt.org Sent: Friday, June 27, 2014 3:03:56 PM Subject: Re: [ovirt-devel] multipath configuration - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Yeela Kaplan ykap...@redhat.com Cc: devel@ovirt.org, Federico Simoncelli fsimo...@redhat.com, Allon Mureinik amure...@redhat.com Sent: Thursday, June 26, 2014 1:56:32 PM Subject: Re: multipath configuration On Wed, Jun 25, 2014 at 09:58:52AM -0400, Yeela Kaplan wrote: Hi, Currently multipath.conf is being rotated each time we reconfigure it. We'd like to change the behaviour for multipath.conf so that current configuration will be commented out and we'd stop rotating (in the same manner as libvirt conf works today). Does anybody have any comment for/ against? I'd like to present the problem in a slightly different light. It is highly uncommon for a service to mangle the configuration files of another service. Administrator do not expect they complain (e.g. Bug 1076531 - vdsm overwrites multipath.conf at every startup) We used to have this problem with libvirtd.conf, but it has been aleviated by moving the configuration to vdsm-tool, which should do its thing when asked by the local admin, or once during automatic host installation. We should do this with multipath.conf, too. And we should deprecate the RHEV trademark that is stuck there while at it. +2 The only question is how. Should we place the old configuration in a rotated file (a-la .rpmsave) or should we place them in the same file, completely commented out. That is an all-or-nothing approach. VDSM probably relies only on few config entries. One thing is for sure, VDSM should be able to detect if the relevant multipath configs are not properly set and refuse to start. For the discovery of these values (read) we could use augeas. If the sysadmin already uses the correct parameters we may not even touch the file at all. Another question is how we should write the configuration file: should we do it as simple text, or should we take a smarter augeas-based approach. In my opinion, as long as we want to dump our own conf file, there is not motivation for augeas. If, on the other hand, we would like to replace only a section of the file, it should come into play. Is this what you have in mind for multipath.conf, Federico? Could you elaborate? My approach would be: 1. vdsm (or its service file) should discover if multipath.conf is configured properly and eventually refuse to start vdsm, the less the service file does the more likely we can have the same systemd unit file for all the distros without init common adapters. We need this check somewhere whether it is in the service file (maybe using ExecStartPre for cleanliness) or in the vdsm daemon the problem of supporting multiple distro remains. 2. vdsm-tool being able to configure multipath.conf (only the required entries), this would be very much similar to what we do with libvirt. If we want to use augeas it is just an implementation detail. 3. vdsm-tool being able to install/replace entire multipath.conf in case it wasn't already configured (or in case you want to force the default strict configuration, e.g. during initial automated deployment?) It is always polite to backup the previous config in .rpmsave. Point 1 implicitly allows the sysadmin to change multipath.conf, which could be harder to support (he could use conflicting entries) but anyway it gives the flexibility to customize multipath.conf if needed (which is something that we already have). Point 1 and 2 seem just read and write of the same parameters, which could
Re: [ovirt-devel] [vdsm] Infrastructure design for node (host) devices
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Martin Polednik mpole...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, June 25, 2014 9:15:38 AM Subject: Re: [ovirt-devel] [vdsm] Infrastructure design for node (host) devices On Jun 24, 2014, at 12:26 , Martin Polednik mpole...@redhat.com wrote: Hello, I'm actively working on getting host device passthrough (pci, usb and scsi) exposed in VDSM, but I've encountered growing complexity of this feature. The devices are currently created in the same manner as virtual devices and their reporting is done via hostDevices list in getCaps. As I implemented usb and scsi devices, the size of this list grew almost twice - and that is on a laptop. To be fair, laptops do have quite a bit of devices :P Similar problem is with the devices themselves, they are closely tied to host and currently, engine would have to keep their mapping to VMs, reattach back loose devices and handle all of this in case of migration. In general, with host device passthrough the simpler and first step would be that the VM gets pinned to the host if it uses a host device. If we want to make migration possible, we should whitelist devices or device classes for which it is not troublesome, but I would start small and have the VM pinned. I would like to hear your opinion on building something like host device pool in VDSM. The pool would be populated and periodically updated (to handle hot(un)plugs) and VMs/engine could query it for free/assigned/possibly problematic I'm not sure about making a pool. Having a verb for getting host devices sounds good though (Specially with the pinning solution, as the engine would only need to poll when the VM is pinned). How costly is it to list them? It shouldn't be much costlier than navigating sysfs and a potential libvirt call, right? devices (which could be reattached by the pool). This has added benefit of requiring fewer libvirt calls, but a bit more complexity and possibly one thread. The persistence of the pool on VDSM restart could be kept in config or constructed from XML. best would be if we can live without too much persistence. Can we find out the actual state of things including VM mapping on vdsm startup? I would actually go for not keeping this data in memory unless it proves really expensive (as I say above). I'd need new API verbs to allow engine to communicate with the pool, possibly leaving caps as they are and engine could detect the presence of newer vdsm by presence of these API verbs. +1 The vmCreate call would remain almost the same, only with the addition of new device for VMs (where the detach and tracking routine would be communicated with the pool). ___ 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VDSM sync meeting minutes June 24th, 2014
- Original Message - From: Francesco Romani from...@redhat.com To: Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, June 25, 2014 1:15:03 PM Subject: Re: [ovirt-devel] VDSM sync meeting minutes June 24th, 2014 - Original Message - From: Francesco Romani from...@redhat.com To: Dan Kenigsberg dan...@redhat.com, Saggi Mizrahi smizr...@redhat.com Cc: devel@ovirt.org Sent: Wednesday, June 25, 2014 10:06:37 AM Subject: Re: [ovirt-devel] VDSM sync meeting minutes June 24th, 2014 - Original Message - From: Dan Kenigsberg dan...@redhat.com To: devel@ovirt.org Sent: Tuesday, June 24, 2014 4:13:05 PM Subject: [ovirt-devel] VDSM sync meeting minutes June 24th, 2014 [...] - Francesco posted a new threadpool implementation. It's implemented with statistics threads in mind, but should be used by storage/tasks, too. As such infra and storage folks should review it. The code is on my github. The history may be messed, but the concepts are in there and it is reviewable: https://github.com/mojaves/vdsm/tree/master/lib/threadpool it is used only here: https://github.com/mojaves/vdsm/blob/master/vdsm/virt/sampling.py I'm now adding at least the initial test and polishing the code. I'll post a proper patch on gerrit hopefully within the end of the week, in order to ease the review. Initial draft posted in the hope to ease the review: http://gerrit.ovirt.org/#/c/29189/ http://gerrit.ovirt.org/#/c/29190/ http://gerrit.ovirt.org/#/c/29191/ These patches will be kept in-sync with changes I make on github: testing and docs, mostly, and adjustement of the code to make testing easier. The core concepts are there. This is the core part - the new pool implementation; the port of the virt sampling code and the other pieces will follow soon in separate patches. A very valid point was raised by Nir in #vdsm: if we choose to go ahead with this new thread pool, should this code put in a separate project like cpopen or ioprocess? I vote for separate oVirt gerrit project. 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Python-GTK User Portal
- Original Message - From: Itamar Heim ih...@redhat.com To: Vojtech Szocs vsz...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com Cc: devel@ovirt.org Sent: Thursday, June 5, 2014 9:36:01 PM Subject: Re: [ovirt-devel] Python-GTK User Portal On 05/27/2014 02:25 PM, Vojtech Szocs wrote: - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Michal Skrivanek michal.skriva...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, Amador Pahim ama...@pahim.org, devel@ovirt.org Sent: Tuesday, May 27, 2014 1:16:17 PM Subject: Re: [ovirt-devel] Python-GTK User Portal - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Vojtech Szocs vsz...@redhat.com, Amador Pahim ama...@pahim.org Cc: devel@ovirt.org Sent: Tuesday, May 27, 2014 12:54:16 PM Subject: Re: [ovirt-devel] Python-GTK User Portal On May 27, 2014, at 12:48 , Vojtech Szocs vsz...@redhat.com wrote: Hi, this project looks nice! Indeed, UserPortal can be sluggish on devices with limited performance. Going for custom, light-weight UserPortal sounds like a natural choice, samples-portals repo sounds like a natural place :) Note that (very) soon I'm going to present a prototype of oVirt.js, SDK for working with oVirt within JavaScript environment. In future, we could implement light-weight UserPortal as web application, or we could use Node.js to host the client application code. It's awesomely simple. Even as a non-web application I think it's worth it:) It can be a great way how to find out what are we missing in SDK, what is not effective enough for big scale usage, debugging, etc.. I wouldn't hesitate much to throw the current user portal away and replace it with this. One small bug in current portal takes longer to fix than this whole thing… I admit that current development workflow is quite complex for a rather simple application that UserPortal should be. Also consider that UserPortal contains two things, Basic + Extended section, so it's more complex by design :) Anyway, JavaScript SDK should bring more possibilities. I would not necessarily throw it away, but I'm completely for moving such a project to the oVirt umbrella. We could even have an image for thin clients that boots into this sort of application. Yes, thin clients for specific devices (like ones with limited performance) are clients too, so I agree with above. we could do a 'lighter' version of it (well, we could do a 'basic html' version if we really want it light...) The problem for ultra-thin clients, like the raspberry pi is, is that the browser itself is a taking a lot of resources. But in any case, making a lighter user portal, once wayland is stable and using midori, it could be performant enough for ultra-thin clients. Thanks, michal Regards, Vojtech - Original Message - From: Amador Pahim ama...@pahim.org To: devel@ovirt.org Sent: Tuesday, May 27, 2014 4:53:35 AM Subject: [ovirt-devel] Python-GTK User Portal Olá, I'm running some tests with Raspberry Pi, trying to use it as a thin client to oVirt. My initial test was just open web User Portal using a browser. But RasPi limited performance is leading browser to repeatedly show the warning for unresponsive script before load the portal. Trying to have a lighter way to access oVirt with the same functions as in Basic User Portal, I wrote this Python-GTK client. Its performance in RasPi is quite acceptable currently. I'm wondering if you guys have any interest in putting the bits somewhere along with the project repositories. Maybe in samples-portals? Source code: https://github.com/apahim/ovirt-userportal-gtk Here a screenshot with it in action: http://pbrd.co/1onSA7O Best Regards, -- Pahim ___ 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 ___ 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] latest python-lxml python-ethtool break VDSM on f19
- Original Message -
From: Roy Golan rgo...@redhat.com
To: devel@ovirt.org, Yaniv Bronheim ybron...@redhat.com, Francesco
Romani from...@redhat.com
Cc: Gianluca Cecchi gianluca.cec...@gmail.com
Sent: Monday, May 12, 2014 8:13:01 AM
Subject: [ovirt-devel] latest python-lxml python-ethtool break VDSM on f19
FYI and please guide Gianluca against what to open a BZ
I don't think python-lxml is related. I think it's only python-ethtool.
Original Message
Subject: Re: [ovirt-users] getVdsCapabilites unexpected exception [was:
Re:
AIO 3.4 on fedora 19 initial errors before coming up]
Date: Sun, 11 May 2014 23:49:06 +0200
From: Gianluca Cecchi gianluca.cec...@gmail.com
To: Roy Golan rgo...@redhat.com
CC: users us...@ovirt.org
On Sun, May 11, 2014 at 8:41 PM, Gianluca Cecchi gianluca.cec...@gmail.com
wrote:
On Sun, May 11, 2014 at 8:18 PM, Gianluca Cecchi gianluca.cec...@gmail.com
wrote:
On Sun, May 11, 2014 at 4:10 PM, Roy Golan rgo...@redhat.com wrote:
The vm will stay in Waiting.. as the getVdsCaps is failing and the
monitoring of Vms will not take place.
need to fix this Unexpected error first. is it a matter of ssl enabled
configuration for host communication? i.e. can you try vdsClient -s 0
getVdsCaps ?
___
Users mailing list
us...@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
I didn't change anything on this server.
It is an all-in-one config so both engine and vdsm host are on it.
Yesterday and every previous day I was able to start the system and start the
VM; I only applied the yum update command yeseterday
(with --exclude=sos due to the opened bug) and then I made shutdown of the
system.
Today after startup I got this problem.
[root@tekkaman vdsm]# vdsClient -s 0 getVdsCaps
Unexpected exception
it seems the error in vdsm.log when I run the command above is of this type:
Thread-25::ERROR::2014-05-11
20:18:02,202::BindingXMLRPC::1086::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 1070, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/BindingXMLRPC.py, line 393, in getCapabilities
ret = api.getCapabilities()
File /usr/share/vdsm/API.py, line 1185, in getCapabilities
c = caps.get()
File /usr/share/vdsm/caps.py, line 369, in get
caps.update(netinfo.get())
File /usr/lib64/python2.7/site-packages/vdsm/netinfo.py, line 557, in get
netAttr.get('qosOutbound'))
File /usr/lib64/python2.7/site-packages/vdsm/netinfo.py, line 487, in
_getNetInfo
ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(iface)
File /usr/lib64/python2.7/site-packages/vdsm/netinfo.py, line 317, in
getIpInfo
ipv6addrs = devInfo.get_ipv6_addresses()
SystemError: error return without exception set
Based on above errors, I think that for some reason these two python related
packages that were updated yesterday are causing some problems with vdsm.
Can you confirm that you can run ok the 3.4 vdsm with those?
vdsm-4.14.6-0.fc19.x86_64
May 10 21:24:23 Updated: python-ethtool-0.9-2.fc19.x86_64
May 10 21:24:23 Updated: python-lxml-3.3.5-1.fc19.x86_64
I can also try to rollback and see...
I was right.
Against what to bugzilla?
This is a show stopper for fedora 19 ovirt users...
[root@tekkaman log]# vdsClient -s 0 getVdsCaps
Unexpected exception
[root@tekkaman log]# yum downgrade python-lxml python-ethtool
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, versionlock
Dropbox | 951 B 00:00:00
adobe-linux-x86_64 | 951 B 00:00:00
fedora-virt-preview | 2.9 kB 00:00:00
google-chrome | 951 B 00:00:00
livna | 1.3 kB 00:00:00
ovirt-3.3.3 | 2.9 kB 00:00:00
ovirt-stable | 2.9 kB 00:00:00
rpmfusion-free-updates | 3.3 kB 00:00:00
rpmfusion-nonfree-updates | 3.3 kB 00:00:00
updates/19/x86_64/metalink | 28 kB 00:00:00
Loading mirror speeds from cached hostfile
* fedora: mirror.netcologne.de
* livna: rpm.livna.org
* rpmfusion-free: mirror.switch.ch
* rpmfusion-free-updates: mirror.switch.ch
* rpmfusion-nonfree: mirror.switch.ch
* rpmfusion-nonfree-updates: mirror.switch.ch
* updates: mirror.netcologne.de
Resolving Dependencies
-- Running transaction check
--- Package python-ethtool.x86_64 0:0.8-1.fc19 will be a downgrade
--- Package python-ethtool.x86_64 0:0.9-2.fc19 will be erased
--- Package python-lxml.x86_64 0:3.2.1-1.fc19 will be a downgrade
--- Package python-lxml.x86_64 0:3.3.5-1.fc19 will be erased
-- Finished Dependency Resolution
Dependencies Resolved
==
Package Arch Version Repository Size
==
Re: [ovirt-devel] [Devel] Vdsm functional tests
- Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Francesco Romani from...@redhat.com Cc: vdsm-de...@ovirt.org, devel@ovirt.org Sent: Thursday, April 10, 2014 8:37:18 AM Subject: Re: [ovirt-devel] [Devel] Vdsm functional tests On Apr 10, 2014, at 08:34 , Francesco Romani from...@redhat.com wrote: - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Dan Kenigsberg dan...@redhat.com Cc: vdsm-de...@ovirt.org, devel@ovirt.org Sent: Thursday, April 10, 2014 8:13:55 AM Subject: Re: [ovirt-devel] [Devel] Vdsm functional tests When could we expect to have it running per commit on a Jenkins slaves? virt tests are running There is a common initialization issue with VdsProxy at the moment, once it's fixed the virt tests can be un-silenced and they will hopefully come out of failing-only mode:) I'd say end of this week... Confirmed. This http://gerrit.ovirt.org/#/c/26514/ should fix the current VdsProxy troubles Plus ideally a better initialization to get rid of that embarrassing sleep 10 in gerrit config. Well, that happens to you because you all copied our network functional tests job xD Where it really doesn't matter 10 seconds since the tests take upwards of 10 minutes to run. We should check and wait till vdsm responds in VdsProxy init. We need to make the test as fast as possible, otherwise people won't run them... Thanks, michal 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [Engine-devel] [vdsm] Copy reviewer scores on trivial rebase/commit msg changes
- Original Message - From: Greg Sheremeta gsher...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Saturday, January 18, 2014 1:35:57 AM Subject: Re: [Engine-devel] [vdsm] Copy reviewer scores on trivial rebase/commit msg changes - Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Friday, January 17, 2014 6:48:52 PM Subject: [vdsm] Copy reviewer scores on trivial rebase/commit msg changes I'd like to enable these - comments welcome: 1. label.Label-Name.copyAllScoresOnTrivialRebase If true, all scores for the label are copied forward when a new patch set is uploaded that is a trivial rebase. A new patch set is considered as trivial rebase if the commit message is the same as in the previous patch set and if it has the same code delta as the previous patch set. This is the case if the change was rebased onto a different parent. This can be used to enable sticky approvals, reducing turn-around for trivial rebases prior to submitting a change. Defaults to false. 2. label.Label-Name.copyAllScoresIfNoCodeChange If true, all scores for the label are copied forward when a new patch set is uploaded that has the same parent commit as the previous patch set and the same code delta as the previous patch set. This means only the commit message is different. This can be used to enable sticky approvals on labels that only depend on the code, reducing turn-around if only the commit message is changed prior to submitting a change. Defaults to false. Do the above apply to verify+1? Cause I'd handle that separately. Verification should be done even after trivial rebase. https://gerrit-review.googlesource.com/Documentation/config-labels.html ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel +1 from me on both. I think they're great features. ___ 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] Copy reviewer scores on trivial rebase/commit msg changes
- Original Message - From: Itamar Heim ih...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com, Greg Sheremeta gsher...@redhat.com Cc: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Saturday, January 18, 2014 2:49:45 PM Subject: Re: [Engine-devel] [vdsm] Copy reviewer scores on trivial rebase/commit msg changes On 01/18/2014 01:39 PM, Antoni Segura Puimedon wrote: - Original Message - From: Greg Sheremeta gsher...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Saturday, January 18, 2014 1:35:57 AM Subject: Re: [Engine-devel] [vdsm] Copy reviewer scores on trivial rebase/commit msg changes - Original Message - From: Itamar Heim ih...@redhat.com To: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Friday, January 17, 2014 6:48:52 PM Subject: [vdsm] Copy reviewer scores on trivial rebase/commit msg changes I'd like to enable these - comments welcome: 1. label.Label-Name.copyAllScoresOnTrivialRebase If true, all scores for the label are copied forward when a new patch set is uploaded that is a trivial rebase. A new patch set is considered as trivial rebase if the commit message is the same as in the previous patch set and if it has the same code delta as the previous patch set. This is the case if the change was rebased onto a different parent. This can be used to enable sticky approvals, reducing turn-around for trivial rebases prior to submitting a change. Defaults to false. 2. label.Label-Name.copyAllScoresIfNoCodeChange If true, all scores for the label are copied forward when a new patch set is uploaded that has the same parent commit as the previous patch set and the same code delta as the previous patch set. This means only the commit message is different. This can be used to enable sticky approvals on labels that only depend on the code, reducing turn-around if only the commit message is changed prior to submitting a change. Defaults to false. Do the above apply to verify+1? Cause I'd handle that separately. Verification should be done even after trivial rebase. we can decide for which label. for example, we can decide just changing the commit message doesn't clear the verification flag, but changing the code does require re-verification. That sounds great. https://gerrit-review.googlesource.com/Documentation/config-labels.html ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel +1 from me on both. I think they're great features. ___ 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] Using REST API in web UI - review call summary
- Original Message - From: Michael Pasternak mpast...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 24, 2013 9:37:22 AM Subject: Re: [Engine-devel] Using REST API in web UI - review call summary On 11/22/2013 12:00 AM, Itamar Heim wrote: On 11/21/2013 11:56 PM, Vojtech Szocs wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Vojtech Szocs vsz...@redhat.com, engine-devel engine-devel@ovirt.org Cc: Einav Cohen eco...@redhat.com Sent: Thursday, November 21, 2013 10:25:04 PM Subject: Re: Using REST API in web UI - review call summary On 11/21/2013 11:18 PM, Vojtech Szocs wrote: Hi guys, this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something. -- Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael Gilad) A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us. As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code). -- Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav) [For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.] A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like get VMs and related data would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding. oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1]. For example: sdk.getVmsWithExtraData( callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API callbackFiredWhenAllDataIsReady // update client only when all data is ready ) would this also resolve RunMultipleActions? Yes, I think so. There could be API to pass multiple actions and get notified when they complete. sounds like no reason to have RunMultipleQueries, although i'm still sure a single call to engine for multiple keys would be much more efficient than multiple async calls? (I understand we may not be able to model this). Efficiency-wise, yes, single call to get all data seems optimal. API-wise, I don't think it really matters from oVirt.js client perspective. We can proceed with simple (possibly inefficient) solution and improve as needed. We're making baby steps now.. [1] http://en.wikipedia.org/wiki/Leaky_abstraction -- Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library. I agree that conceptually both above mentioned projects should go into dedicated ovirt-engine-sdk-js git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of ovirt-engine git repository. ... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law) I think the entities should just be generated from the xsd. +1 The JavaScript Binding (aka low-level SDK) module should follow same concepts
Re: [Engine-devel] Things to be done to support Ubuntu hosts
Would it make sense to leverage packagekit to abstract away the distro packaging differences? http://www.packagekit.org/pk-using.html - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 9:53:29 AM Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 3:53:17 AM Subject: Re: Things to be done to support Ubuntu hosts on 2013/11/16 02:52, Alon Bar-Lev wrote: - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: engine-devel engine-devel@ovirt.org Cc: Itamar Heim ih...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Thursday, November 14, 2013 8:57:19 AM Subject: Things to be done to support Ubuntu hosts Hi, Recently Ubuntu support is added to VDSM, and .deb binray packages can be downloaded from launchpad.net PPA [1]. Most of the key features such as storage management and VM lifecycle work on Ubuntu. The cross distribution network management patches are upstream as well. One big piece left is making ovirt-host-deploy support Ubuntu, so that we can manage Ubuntu hosts from Engine, thus close the gap on host side. In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it skipped parts not supported on Ubuntu and configure the environment manually, and successfully added Ubuntu host to Engine [2]. Unfortunately I have no plans to continue on it, but I'd like to make a summary of the things I hacked to help anyone who wants to submit patches in future. I was to add a WIKI page but I found there were not many items, so a mail would be enough. 1. Package management operations Both otopi and ovirt-host-deploy query for dependency packages and install them on demand. The otopi package management just supports yum, we need to add apt-get support. Package names are different in Ubuntu, so I made a list mapping the names. The list in in VDSM source directory, debian/dependencyMap.txt . Please try putting the following file on host: /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf --- ODEPLOY/offlinePackager=bool:True --- This will replace the disable section of packaging in your patch. It will make host-deploy not to install any package and assume all is pre-installed. Great! Do we have plan to implement apt-get support in ovirt-host-deploy? Plans - yes. Not sure when exactly. I prefer first to handle the ovirt-engine porting to ubuntu at first opportunity. 2. Network configuration operations ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. Cross distribution support patches for configNetwork.py are under review. ovirt-host-deploy supports Ubuntu bridge configuration as long as they are merged. This is not happening any more at 3.3, so no need to change anything. I think that in 3.3 with the above offline packaging use, you can use vanilla otopi/host-deploy. Regards, Alon Bar-Lev [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf Here goes the detailed hack patch. The hack was base on v1.0.1, I rebased it to the latest master. The rebased patch are not tested. If you find this email useless, it's actually a good news, which means there is not a lot of work and problems ahead ;-) Hack patch for ovirt-host-deploy. From 120493a242046d19794ef3da83b32486d372aa39 Mon Sep 17 00:00:00 2001 From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com Date: Wed, 13 Nov 2013 18:02:26 +0800 Subject: [PATCH] Ubuntu Hacks ___ 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] Things to be done to support Ubuntu hosts
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 1:03:05 PM Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 1:50:46 PM Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts Would it make sense to leverage packagekit to abstract away the distro packaging differences? http://www.packagekit.org/pk-using.html Not really... as it is egg and chicken... How do I install this package on vanilla host? True And... it does not support gentoo as far as I can see :))) Yeah... I guess writing a backend for gentoo's ebuilds or for Arch's AUR would be quite a challenge. - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 9:53:29 AM Subject: Re: [Engine-devel] Things to be done to support Ubuntu hosts - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: Alon Bar-Lev alo...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Wednesday, November 20, 2013 3:53:17 AM Subject: Re: Things to be done to support Ubuntu hosts on 2013/11/16 02:52, Alon Bar-Lev wrote: - Original Message - From: Zhou Zheng Sheng zhshz...@linux.vnet.ibm.com To: engine-devel engine-devel@ovirt.org Cc: Itamar Heim ih...@redhat.com, Alon Bar-Lev alo...@redhat.com Sent: Thursday, November 14, 2013 8:57:19 AM Subject: Things to be done to support Ubuntu hosts Hi, Recently Ubuntu support is added to VDSM, and .deb binray packages can be downloaded from launchpad.net PPA [1]. Most of the key features such as storage management and VM lifecycle work on Ubuntu. The cross distribution network management patches are upstream as well. One big piece left is making ovirt-host-deploy support Ubuntu, so that we can manage Ubuntu hosts from Engine, thus close the gap on host side. In May 2013 I made some hacks to ovirt-host-deploy and otopi. I made it skipped parts not supported on Ubuntu and configure the environment manually, and successfully added Ubuntu host to Engine [2]. Unfortunately I have no plans to continue on it, but I'd like to make a summary of the things I hacked to help anyone who wants to submit patches in future. I was to add a WIKI page but I found there were not many items, so a mail would be enough. 1. Package management operations Both otopi and ovirt-host-deploy query for dependency packages and install them on demand. The otopi package management just supports yum, we need to add apt-get support. Package names are different in Ubuntu, so I made a list mapping the names. The list in in VDSM source directory, debian/dependencyMap.txt . Please try putting the following file on host: /etc/ovirt-host-deploy.conf.d/10-ubuntu.conf --- ODEPLOY/offlinePackager=bool:True --- This will replace the disable section of packaging in your patch. It will make host-deploy not to install any package and assume all is pre-installed. Great! Do we have plan to implement apt-get support in ovirt-host-deploy? Plans - yes. Not sure when exactly. I prefer first to handle the ovirt-engine porting to ubuntu at first opportunity. 2. Network configuration operations ovirt-host-deploy asks VDSM's configNetwork.py to create bridge network. Cross distribution support patches for configNetwork.py are under review. ovirt-host-deploy supports Ubuntu bridge configuration as long as they are merged. This is not happening any more at 3.3, so no need to change anything. I think that in 3.3 with the above offline packaging use, you can use vanilla otopi/host-deploy. Regards, Alon Bar-Lev [1] https://launchpad.net/~zhshzhou/+archive/vdsm-ubuntu [2] http://www.ovirt.org/images/5/57/Shanghai-VDSM-on-Ubuntu.pdf Here goes the detailed hack patch. The hack was base on v1.0.1, I rebased it to the latest master. The rebased patch are not tested. If you find this email useless, it's actually a good news, which means there is not a lot of work and problems ahead ;-) Hack patch for ovirt-host-deploy
Re: [Engine-devel] server/api/ full_version tag stability
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Antoni Segura Puimedon asegu...@redhat.com, engine-devel engine-devel@ovirt.org, Michael Pasternak mpast...@redhat.com Sent: Friday, August 2, 2013 5:55:45 PM Subject: Re: [Engine-devel] server/api/ full_version tag stability On 08/01/2013 11:27 AM, Alon Bar-Lev wrote: - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, August 1, 2013 11:24:18 AM Subject: [Engine-devel] server/api/ full_version tag stability Hello list, In order to smarten up the ovirt-node registration flow I will ask the engine via rest API for it's version number, so that I can take decisions about capabilities for networking. I found that https:/server/api/ provides an xml document with a full_version tag that suits my purposes and I wanted to make sure that the stability of such element can be depended upon by asking you about it. IMHO, it could be nice instead that we would have an api endpoint (if it is not there and I missed it) that would provide capability tags information such as: bridgeless_nets, vm_live_snapshot, etc. It also should be anonymous API. iirc, the rest api doesn't support yet anonymous access. Indeed it doesn't, and unfortunately one flow of node registration doesn't have any credentials, so we'll have to add a checkbox in the registration UI (and on the kernel cmdline params for pxe booting). i think the api should allow getting the version anonymously. Agreed, version and if possible, capabilities. other possible places are the registration servlet or the health servlet, both anonymous today. If it were possible to get the version from the registration servlet it would solve the problem with the registration flow. ___ 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
I would advocate for option 2. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org, arch a...@ovirt.org, users us...@ovirt.org Sent: Tuesday, July 30, 2013 3:25:24 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19misses 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 ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal for new commit msg design for engine commits
I like the idea of having a label in the bottom part of the commit that is: METADATA: network which would be your second proposal. - Original Message - From: Eyal Edri ee...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: infra in...@ovirt.org Sent: Tuesday, July 9, 2013 11:38:51 AM Subject: [Engine-devel] Proposal for new commit msg design for engine commits Hi, You all probably know and familiar with 'ovirt-engine' git hook for commit msg template [1]. this helps understand the general area of the patch in the project but it lacks additional info that might be valuable for scaling automatic tests in Jenkins CI. Let me explain: Infra team is working hard on expanding oVirt CI infrastructure and adding more tests in jenkins (per commit/patch). Adding important meta-data per patch can significatly improve the ability to run specific tests for each patch/commit, and not waste valuable resources on Jenkins jobs that are not relevant to the code in the patch. So the idea is to add/expand current metadata per patch, in the form of: (either) 1. expanding current header template to include more data like 'network' , 'setup', 'tools', 'virt' 2. adding a new label with relevant tags for the patch, called e.g 'METADATA: network, rest, virt' Jenkins jobs will then be able to parse that data and trigger only relevant jobs for it. this can also allow us to add more jobs per patch, an option that is very problematic today considering the amount of patches coming in to engine. Once agreed on a format, we'll be able to add a git hook to verify the validity of the commit msg. (similar to bug-url). if we're not 100% sure that the tags will cover all corner cases and we feel like we need to run the code on all jobs, we can a nightly job to run all the remaining jobs (but at least it won't run on every patch/commit). [1] core | restapi | tools | history | engine | userportal | webadmin: thoughts? Eyal Edri. ___ 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] gerrit command line client
Hi all, Having yesterday a slow Saturday and inspired by a link sent by ewoud about gerrit ssh interface. I coded a very basic command line script to retrieve information from gerrit. You can find it on: https://github.com/celebdor/perryt As of now it doesn't have a lot of options and the code is quite horrible still. But it does allow some useful queries like the ones at the end of this email. The classes on perryt.py are close to modelling all the information that gerrit 2.4.2 exposes through this interface, so it should be easy to add more complicated and useful queries (checking dependencies and such). You might ask: Why to do that if gerrit already has quite big querying possibilities?. The answers are twofold: 1. Because I can and it was raining. 2. Because it is easier for me to use than the ssh gerrit thingy. I welcome pull requests ;-) ./perryt.py reviewer apuimedo reviewed any verified markw Results: 31(time: 537µs) (vdsm)Iece96: ifcfg: preserve 'NM_CONTROLLED=no' on removal - (OUTDATED DEP) - wudxw http://gerrit.ovirt.org/15148 P4 (v: 1, r: 2 - [wudxw(v:1), asegurap(r:1), gvallare(r:1)]) (vdsm)I32e8e: Simplify setNewMtu() - (UP TO DATE) - wudxw http://gerrit.ovirt.org/15355 P6 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) (vdsm)I9e11f: NetReload: netmodels for delNetwork - (OUTDATED DEP) - wudxw http://gerrit.ovirt.org/14873 P10 (v: -1, r: 1 - [wudxw(v:-1), asegurap(r:1)]) (vdsm)Id254a: Move removing libvirt network to configurator - (UP TO DATE) - wudxw http://gerrit.ovirt.org/15417 P1 (v: 0, r: -1 - [wudxw(v:1), oVirt Jenkins CI Server(v:-1), asegurap(r:-1)]) P3 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) P5 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) (vdsm)I798cc: Separate libvirt network configuration from ifcfg - (UP TO DATE) - wudxw http://gerrit.ovirt.org/15178 P5 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) P7 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) P8 (v: 2, r: 1 - [wudxw(v:1), asegurap(r:1), asegurap(v:1)]) (vdsm)I9ab6f: NetReload: netmodels for editBonding/removeBonding - (UP TO DATE) - wudxw http://gerrit.ovirt.org/15356 P4 (v: 1, r: -1 - [wudxw(v:1), asegurap(r:-1)]) P6 (v: 1, r: 1 - [wudxw(v:1), asegurap(r:1)]) P7 (v: 2, r: 1 - [wudxw(v:1), asegurap(r:1), asegurap(v:1)]) or another example: ./perryt.py owner alonbl status open Results: 12(time: 161µs) (ovirt-engine)I76019: packaging: periodically check if ovirt-engine upgrade available - (UP TO DATE) - alonbl http://gerrit.ovirt.org/10976 P2 (v: 0, r: -1 - [oschreib(r:-1), alourie(r:1), alonbl(r:-1)]) (ovirt-engine)I017a5: packaging: setup: use firewalld implementation of otopi - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15114 P1 (v: 0, r: 0 - [alonbl(r:-1), sbonazzo(r:1)]) (ovirt-engine)I3570a: packaging: log rotate - (UP TO DATE) - alonbl http://gerrit.ovirt.org/14961 P3 (v: 2, r: 4 - [yzaslavs(r:1), amureini(r:1), alonbl(v:1), sbonazzo(r:1), didi(r:1), didi(v:1)]) (ovirt-engine)I7f3ab: pki: set ownership of apache key to root - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15266 P1 (v: 1, r: 0 - [alonbl(v:1)]) (ovirt-engine)I638e9: pki: upgrade: do not overwrite apache certificate and key - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15267 P1 (v: 1, r: 0 - [alonbl(v:1)]) (ovirt-image-uploader)Id8600: core: modify copyright of base po - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15294 P1 (v: 0, r: 1 - [kroberts(r:1)]) (ovirt-iso-uploader)I11ea0: core: modify copyright of base po - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15295 P1 (v: 0, r: 1 - [kroberts(r:1)]) (ovirt-engine)Iec8bb: pki: remove database config upgrade - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15184 P1 (v: 1, r: 1 - [emesika(r:1), alonbl(v:1)]) (ovirt-engine-sdk-java)I2f390: build: support make out of tarball - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15332 P1 (v: 1, r: 0 - [alonbl(v:1)]) (ovirt-engine-sdk-java)I0eb58: build: spec: support rhel and centos - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15333 P1 (v: 1, r: 0 - [alonbl(v:1)]) (ovirt-log-collector)Ieef24: core: modify copyright of base po - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15293 P1 (v: 0, r: 1 - [kroberts(r:1)]) (ovirt-engine)Icf94f: packaging: setup: support older psycopg2 - (UP TO DATE) - alonbl http://gerrit.ovirt.org/15358 P2 (v: 1, r: 1 - [alonbl(v:1), sbonazzo(r:1)]) ___ Engine-devel mailing list Engine-devel@ovirt.org
[Engine-devel] Intel workshop in Shangai
Hi List, You might be interested in the Intel oVirt workshop schedule. Here it is: Wednesday, May 8, 2013 - Operations Track 08:30-09:00 Opening remarks and Keynote : Intel Open Source Strategy Jackson He (Intel) 09:00-10:00 oVirt Introduction Doron Fediuck (Red Hat) 10:00-11:00 oVirt Architecture Overview Dan Kenigsberg (Red Hat) 11:00-11:15 Coffee Break 11:15 - 12:15 Deploying and testing oVirt using nested virtualization Mark Wu (IBM) 12:15-13:30 Lunch 13:30-14:30 oVirt SLA overview Doron Fediuck (Red Hat) 14:30-15:00 oVirt storage system and IBM's activity Shu Ming (IBM) 15:00-15:15 Coffee Break 15:15-16:15 Troubleshooting oVirt Tal Nisan (Red Hat) 16:15-17:00 Converged Infrastructure with oVirt and Gluster Theron Conrey (Red Hat) Wednesday, May 8th, 2013 - oVirt / Gluster Integration Track TimeTitle Speaker 08:30-09:00 Opening remarks and Keynote : Intel Open Source Strategy Jackson He 09:00-10:00 Gluster Community Overview and Roadmap John Mark Walker (Red Hat) 10:00-11:00 Gluster Architecture Overview To be announced 11:00-11:15 Coffee break 11:15-12:15 oVirt Configurations and GlusterTal Nisan (Red Hat) 12:15-13:30 Lunch 13:30-14:30 Converged Infrastructure with oVirt and Gluster Theron Conrey (Red Hat) 14:30-15:30 Gluster and Swift Object Store (UFO) John Mark Walker (Red Hat) 15:30-15:45 Coffee break 15:45-16:45 Developing with GlusterFS - translator framework, libgfapi and more Vijay Bellur (Red Hat) Thursday, May 9, 2013 - Developer Track TimeTitle Speaker 09:00-10:00 oVirt-node overview Ying Cui and Guohua Ouyang (Red Hat) 10:00-11:00 Packaging oVirt for Ubuntu Zhengsheng Zhou (IBM) 11:00 - 11:15 Coffee Break 11:15-12:15 oVirt SLA- MoM as host level enforcement agent Doron Fediuck (Red Hat) 12:15-13:30 Lunch 13:30-14:30 Trusted Compute Pools Deep Dive Gang Wei 14:30-15:30 KVM Nested Virtualization to be announced 15:30-15:45 Coffee break 15:30-17:00 The present and future of SetupNetwork in oVirt Dan Kenisberg (Red Hat) 17:00-17:30 Closing remarks and closing keynote Thursday, May 9, 2013 - Self paced labs / oVirt Install TimeTitle Speaker 09:00-12:00 oVirt Hands-on Workshop To be announced 12:00-13:30 Lunch 13:30-16:00 oVirt and Gluster configurationsTo be announced ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID?
Did you try to do it with the browser in rpivate mode? - Original Message - From: Einav Cohen eco...@redhat.com To: Tomas Jelinek tjeli...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Thursday, May 2, 2013 2:57:08 PM Subject: Re: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID? Hi Tomas, I had this issue when I have enabled the google+ on my account - it changes something with openID. Did you do this? I enabled google+ on my account a *long* time ago, however problems with signing into gerrit started only today (yesterday it worked fine). I haven't changed anything in my google account settings recently. other ideas?... Tomas - Original Message - From: Einav Cohen eco...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Thursday, May 2, 2013 2:45:42 PM Subject: [Engine-devel] cannot sign in to gerrit.ovirt.org with google ID? Hi, It seems that I cannot log into gerrit.ovirt.org web-interface with my google ID anymore: when attempting to sign-in, it asks me for my Open ID, and when providing my google ID - the page just refreshes without signing me in. [see attached video] [same behavior from FireFox and Chrome] [tried deleting cookies/history/etc...] [I experience no problems signing in with my google account to chrome/gmail] [I can sign in to gerrit.ovirt.org with my Yahoo ID (as an Anonymous Coward...)] did someone else experience that? any idea how to solve it? Thanks, Einav ___ 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] Proposal to make REST API more webapp-friendly
Incidentally, the other day reading hacker news I happened upon a similar discussion and article. It might be an interesting lecture to put in perspective our own discussion: article: http://swaggadocio.com/post/48223179207/why-the-hell-does-your-api-still-use-http-basic-auth discussion: https://news.ycombinator.com/item?id=5569625 - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, April 17, 2013 3:08:31 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly Hi Oved, The only difference would be, when REST API receives the request, it looks for Prefer:use-jsessionid-header, and if it's present, it uses JSESSIONID header value to look up HttpSession in some way (not sure about implementation details, though, but this should be possible to do). So, what do you think? As far as I saw, the handling of the cookie is done before the REST code, and that's why we need the cookie. Perhaps there is a way to make jboss take the JSESSIONID from the HTTP header, and not the cookie, but I didn't find a way to do that yet. I'm also not sure about this, so far I've only found: http://stackoverflow.com/questions/5807664/tomcat-how-to-access-session-manager-from-servlet It seems that the solution is to either provide custom session manager implementation in JBoss, or to obtain standard session manager early when processing request and create session manually there. Vojtech - Original Message - From: Oved Ourfalli ov...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, April 17, 2013 12:29:09 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Oved Ourfalli ov...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-devel@ovirt.org Sent: Wednesday, April 17, 2013 1:25:06 PM Subject: Re: [Engine-devel] Proposal to make REST API more webapp-friendly Hi Oved, thanks for your feedback! We currently return the JSESSIONID also using HTTP headers. We currently return the jsession id also as part of the response HTTP headers, but the client still needs to pass a cookie with the appropriate value in order for the REST session to work. Isn't that enough to cope with this issue? Right, currently REST API responds with JSESSIONID cookie + separate JSESSIONID response header, both carrying session ID value. As I wrote in my original email: JavaScript running at [http://example.com/webapp] *cannot* get/set cookies from requests at [http://example.com/restapi] So WebAdmin cannot get/set REST API JSESSIONID cookie directly, which is why it uses separate JSESSIONID response header in order to *read* the session ID value. As for sending JSESSIONID cookie, WebAdmin currently relies on standard cookie-handling implemented in browsers: all cookies for location X [http://example.com/restapi] will be part of any request to location X. So it's the browser who sets JSESSIONID cookie for REST API request, not WebAdmin. To answer your question, currently it's enough to work around the cookie access limitation, but it's not good enough in my opinion (from JavaScript/webapp perspective).. If not, then we might be able to do option #2: Today, we keep the engine session ID on the HTTP session attributes. So, we can support either passing the cookie with the JSESSIONID (taking the engine session ID from the http session), or passing the engine session ID as HTTP header (assuming we would also return the engine session ID upon first REST request). Well, the problem I described only relates to the way how JSESSIONID value is transmitted between client and server: currently using cookies, so REST API client has to do cookie handling. It would be really great if I could tell REST API to use plain (i.e. *not* Set-Cookie Cookie) HTTP header, for example JSESSIONID, for the purpose of transmitting session ID value between client and server. For example, the request to acquire session would be: GET /api HTTP/1.1 Host: www.example.org Prefer: use-jsessionid-header JSESSIONID: xxx [Feel free to replace use-jsessionid-header with anything you like. If client doesn't specify use-jsessionid-header, server expects Cookie header by default to preserve compatibility.] And the response would be: HTTP/1.1 200 OK JSESSIONID: xxx [If client didn't specify use-jsessionid-header, server would use Set-Cookie header by default to preserve compatibility.] This approach is problematic, as it might work well now, when the only attribute we use
Re: [Engine-devel] Changing Gerrit -1 message
I like most of these proposals. It'll make gerrit friendlier :-) - Original Message - From: Itamar Heim ih...@redhat.com To: Laszlo Hornyak lhorn...@redhat.com Cc: engine-devel@ovirt.org Sent: Wednesday, February 20, 2013 9:32:53 AM Subject: Re: [Engine-devel] Changing Gerrit -1 message On 19/02/2013 12:06, Laszlo Hornyak wrote: Hi, I agree with that. for the - messages this in my opinion would be both more clear and friendly: -1: In my opinion it needs work. how about -1: Please review my comments -2: I disagree. -2: Please reconsider - Original Message - From: Ofer Schreiber oschr...@redhat.com To: engine-devel@ovirt.org Sent: Tuesday, February 19, 2013 10:51:15 AM Subject: [Engine-devel] Changing Gerrit -1 message I feel that the current -1 I would prefer that you didn't submit this message in Gerrit is pretty rude, as usually those -1 reviews are just small fix-ups in the code itself. Any thoughts about a more suitable -1 message? I thought about -1 Please fix your code or something similar. 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 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-sdk at pypi
Thanks! - Original Message - From: Michael Pasternak mpast...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: engine-devel engine-devel@ovirt.org Sent: Sunday, November 4, 2012 9:12:05 AM Subject: Re: [Engine-devel] ovirt-sdk at pypi Hi Toni, do: 1. nics = api.hosts.get(name=xxx).nics 2. nics_arr = nics.list() (change nics_arr as you need, according to __doc__, also see [1]) 3. my_nics = params.HostNics(host_nic=[nics_arr[0],nics_arr[1],...]) or my_nics = params.HostNics(host_nic=nics_arr) 4. nics.setupnetworks(action=params.Action(host_nics=my_nics)) [1] http://wiki.ovirt.org/wiki/SDK#Development_tips On 11/02/2012 11:29 AM, Antoni Segura Puimedon wrote: Hi Michael, One question though, I would like to use the setupNetworks command and the docstring says that I should use params (ovirtsdk.xml.params) and inside those ivars. I don't know how or were these ivars are to be used. Could you point me where I should look at or, alternatively, give me an example? Thanks a lot for this nice api. Best, Toni - Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: us...@ovirt.org Sent: Friday, November 2, 2012 8:44:40 AM Subject: [Engine-devel] ovirt-sdk at pypi From now on latest ovirt-sdk will be available at pypi, for more details see [1]. [1] http://wiki.ovirt.org/wiki/SDK#pypi -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-sdk at pypi
Great Michael! I will update the wiki part I did the other day for different distros. - Original Message - From: Michael Pasternak mpast...@redhat.com To: engine-devel engine-devel@ovirt.org Cc: us...@ovirt.org Sent: Friday, November 2, 2012 8:44:40 AM Subject: [Engine-devel] ovirt-sdk at pypi From now on latest ovirt-sdk will be available at pypi, for more details see [1]. [1] http://wiki.ovirt.org/wiki/SDK#pypi -- Michael Pasternak RedHat, ENG-Virtualization RD ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt on wikipedia
Very good idea Laszlo. I'll get to it as soon as I can. - Original Message - From: Laszlo Hornyak lhorn...@redhat.com To: engine-devel engine-devel@ovirt.org Sent: Monday, October 29, 2012 4:40:28 PM Subject: [Engine-devel] ovirt on wikipedia 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
