On Mon, Jun 18, 2018 at 9:23 PM Richard W.M. Jones <rjo...@redhat.com> wrote:
> On Mon, Jun 18, 2018 at 08:55:13PM +0300, Nir Soffer wrote: > > On Mon, Jun 18, 2018 at 1:37 PM Richard W.M. Jones <rjo...@redhat.com> > > wrote: > > > > > On Thu, Jun 14, 2018 at 09:24:48PM +0300, Nir Soffer wrote: > > > > On Thu, Jun 14, 2018 at 9:16 PM Nir Soffer <nir...@gmail.com> wrote: > > > > > + headers = {"Content-Type": "application/json", > > > > > + "Content-Length", str(len(buf))} > > > > > > There were a few Python syntax errors such as this one. They > > > can be found by running: > > > > > > make -C v2v check TESTS=test-v2v-python-syntax.sh > > > > > > > Cool. Why not include this in "make check"? > > It is! That command is just if you want to run the single test. > Strange, I did run "make check" but it did not fail on checking the rhv plugin. It was failing because of unralted c-api test. Maybe make aborted before running the v2v tests? > > > > Not really. In fact we don't have any unit tests for -o rhv-upload > > > functionality because there's no way to simulate the imageio server. > > > > > > > Actually it is easy to use real imageio server for testing. > > > > 1. install ovirt-imageio-daemon > > Yup, problem is this part. > > However I'll look to see if we can make the tests run optionally _if_ > someone has installed ovirt-imageio-daemon or has a local copy of the > sources, so the rest of the instructions are useful. I think this > method looks most promising, but as you say I'd have to see about > mocking the other engine methods: > There is also: https://github.com/kevin1024/vcrpy I don't like these mocking libraries very much, but this may be useful. After you run the tests once with a real system it can record all the interactions, and the next time you run the tests it will use recorded data. See https://il.pycon.org/2018/schedule/presentation/37/ > > > Another option is to start the server from your tests like this. This > > is how we run our tests. > > > > from ovirt_imageio_daemon import server > > from ovirt_imageio_daemon import config > > > > config.daemon.pki_dir = test/pki > > config.daemon.poll_interval = 0.1 > > config.images.port = 9876 > > config.tickets.socket = "/tmp/ovirt-imageio-daemon.sock" > > > > server.start(config) > > > > # run your test here... > > > > server.stop() > > [...] > > However you can run virt-v2v locally against an oVirt instance without > > > needing VMware. The command is rather lengthy, but here it is: > > > > > > $ virt-builder fedora-27 > > > $ ./run virt-v2v -i disk /var/tmp/fedora-27.img \ > > > -o rhv-upload \ > > > -oc https://ovirt-engine.example.com/ovirt-engine/api \ > > > -os ovirt-data \ > > > -op /tmp/password \ > > > -of raw \ > > > -oo rhv-cafile=/tmp/ca.pem \ > > > -oo rhv-direct > > > > > > /tmp/password should contain the oVirt admin password. > > > /tmp/ca.pem should contain the oVirt CA cert. > > > > > > This will create a guest called ‘fedora-27’ which you'll need to > > > delete (on oVirt) afterwards. You can add ‘-on name’ to name it > > > something else. > > > > > > > Should we document this? > > It's just the normal way to run virt-v2v, eg as documented here: > > http://libguestfs.org/virt-v2v.1.html#convert-from-vmware-to-rhv-ovirt > > ... except that I've changed the input side to use a local disk. > > We did consider having an ‘-i builder’ input method (just for testing). > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html >
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs