Modify the code to make the libvirt url actually configurable
ClosedPublic

Authored by lnie on Aug 1 2016, 5:43 AM.

Details

Summary

Modify the code to make the libvirt url actually configurable,

as described in https://phab.qadevel.cloud.fedoraproject.org/T817
Test Plan

just run testcloud as normal to see whether it still works well

Diff Detail

Repository
rTCLOUD testcloud
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
lnie retitled this revision from to Modify the code to make the libvirt url actually configurable.Aug 1 2016, 5:43 AM
lnie updated this object.
lnie edited the test plan for this revision. (Show Details)
lnie added reviewers: jskladan, kparal, lbrabec, tflink.
lnie updated this revision to Diff 2449.Aug 5 2016, 8:50 AM

modify the diff

kparal requested changes to this revision.Aug 8 2016, 12:28 PM

I'm not all that familiar with testcloud code. @lbrabec, @tflink, does that code look reasonable?

Lili, have you tested it with qemu:///session?

testcloud/cli.py
346

The new parameter should be added to the docstring.

testcloud/instance.py
338

For all these methods in Instance, wouldn't it be easier to add the connection parameter to __init__(), instead of adding it to each instance method?

This revision now requires changes to proceed.Aug 8 2016, 12:28 PM
lnie added a comment.Aug 9 2016, 5:25 AM

Lili, have you tested it with qemu:///session?

Nope(until I saw this comment),I'm not familiar with it,but doesn't it has drawbacks compared to qemu:///system?Is it likely that users will use qemu:///session instead of qemu:///system?
In case some users will use qemu:///session,I have tested it,and testcloud works well with it.

testcloud/instance.py
338

yeah,we don't need to add it to each instance method.Actually,I typed it incidentally after I typed "connection":)

kparal added a comment.EditedAug 9 2016, 11:25 AM

The point of that ticket is to make it configurable, so I expect people will use different libvirt connections :) qemu:///session is almost the same qemu:///system, it just doesn't need admin privileges, and its networking is not that good, but should be good enough.

I tried this:

$ testcloud instance --connection qemu:///session create -u 'file:///var/lib/taskotron/images/160729_1122-fedora-23-taskotron_cloud-x86_64.qcow2' foo

Which seemingly works, but the VM is created in the system scope, not in the session scope, so there's still some problem somewhere. Doesn't work as expected, the machine should be created in session scope (you can easily see that in virt-manager, if you connect to both qemu:///session and qemu:///system).

Also, please rebase to the latest dev branch:

$ git checkout dev
$ git update
$ git checkout libvirt-url
$ git rebase dev
lnie added a comment.EditedAug 10 2016, 3:20 AM
In D956#18198, @kparal wrote:

The point of that ticket is to make it configurable, so I expect people will use different libvirt connections :) qemu:///session is almost the same >qemu:///system, it just doesn't need admin privileges, and its networking is not that good, but should be good enough.

Can't agree more,"the point of that ticket is to make it configurable",that's exactly what I thought when I created this diff^^. Making the -c argument "not hardcoded",ie,configurable and that's all.Whether a specific connection works well is likely that kind connection's problem,and beyond the consideration of this diff.Think it's better to open another ticket if we see a problem with a specific connection:)

I tried this:

$ testcloud instance --connection qemu:///session create -u 'file:///var/lib/taskotron/images/160729_1122-fedora-23-taskotron_cloud-x86_64.qcow2' foo

Which seemingly works, but the VM is created in the system scope, not in the session scope, so there's still some problem somewhere. Doesn't work as >expected, the machine should be created in session scope (you can easily see that in virt-manager, if you connect to both qemu:///session and >qemu:///system).

I got the conclusion that this diff works well with qemu:///session by running a similar task but with sudo(haven't checked which scope it's in)

sudo testcloud instance --connection qemu:///session create -u 'file:///home/lnie/Fedora-Cloud-Base-24-1.2.x86_64.qcow2'  foo

Maybe that's the problem?

Also, please rebase to the latest dev branch:

$ git checkout dev
$ git update
$ git checkout libvirt-url
$ git rebase dev

I should do that every time before I try to submit a diff,will keep it on mind: )

In D956#18198, @kparal wrote:

I tried this:

$ testcloud instance --connection qemu:///session create -u 'file:///var/lib/taskotron/images/160729_1122-fedora-23-taskotron_cloud-x86_64.qcow2' foo

Which seemingly works, but the VM is created in the system scope, not in the session scope, so there's still some problem somewhere. Doesn't work as expected, the machine should be created in session scope (you can easily see that in virt-manager, if you connect to both qemu:///session and qemu:///system).

I was wrong about this, I haven't had this patch applied properly. It actually created 'foo' VM in qemu:///session scope, but it fails with this:

DEBUG:Creating domain foo
libvirt: Network Driver error : Network not found: no network with matching name 'default'
Traceback (most recent call last):
  File "/home/kparal/devel/taskotron/env_taskotron/bin/testcloud", line 9, in <module>
    load_entry_point('testcloud==0.1.2', 'console_scripts', 'testcloud')()
  File "/home/kparal/devel/testcloud/testcloud/cli.py", line 328, in main
    args.func(args)
  File "/home/kparal/devel/testcloud/testcloud/cli.py", line 96, in _create_instance
    tc_instance.start(args.connection, args.timeout)
  File "/home/kparal/devel/testcloud/testcloud/instance.py", line 383, in start
    create_status = dom.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Network not found: no network with matching name 'default'

The problem seems to be that testcloud configures networking to always use the default network, but that is only available in system scope, not in session scope - in session scope, you need to use user-mode networking.

The other issue I identified is that some calls do not use connection argument, like instance.find_instance and therefore things like testcloud instance --connection qemu:///session remove foo doesn't work properly.

We can tackle the user-mode networking issue in a separate diff, but please fix this patch as suggested (using instance as an attribute of Instance class instead of providing it to each class method) and make sure it is used everywhere (like instance.find_instance).

Whether a specific connection works well is likely that kind connection's problem,and beyond the consideration of this diff.Think it's better to open another ticket if we see a problem with a specific connection:)

I agree with you in general, but the problem here is that you need at least two different libvirt connections to be working in order to test that you actually made the connection configurable and didn't forget about anything. But I have no problem doing in this several smaller steps - let's fix this patch and commit this, then fix networking, and then figure out whether we forgot about anything to be made configurable.

lnie added a comment.Aug 11 2016, 7:42 AM

We can tackle the user-mode networking issue in a separate diff, but please fix this patch as suggested (using instance as an attribute of Instance class >instead of providing it to each class method) and make sure it is used everywhere (like instance.find_instance).

Sure thing.

Whether a specific connection works well is likely that kind connection's problem,and beyond the consideration of this diff.Think it's better to open another >>ticket if we see a problem with a specific connection:)

I agree with you in general, but the problem here is that you need at least two different libvirt connections to be working in order to test that you actually >made the connection configurable and didn't forget about anything. But I have no problem doing in this several smaller steps - let's fix this patch and commit >this, then fix networking, and then figure out whether we forgot about anything to be made configurable.

Sure,I'm going to update this patch ,but before that we need identify a problem:

The other issue I identified is that some calls do not use connection argument, like instance.find_instance and therefore things like testcloud instance >--connection qemu:///session remove foo doesn't work properly.

What do you mean by saying: remove foo with qemu:///session doesn't work properly?I have successfully removed the foo instance with qemu:///session connection.

(env_taskotron)[lnie@dhcp-128-50 testcloud]$ sudo testcloud instance -c qemu:///session remove foo
DEBUG:remove instance: foo
DEBUG:removing instance foo from libvirt.
DEBUG:Unregistering domain from libvirt.
DEBUG:removing instance /var/lib/testcloud/instances/foo from disk
In D956#18279, @lnie wrote:

What do you mean by saying: remove foo with qemu:///session doesn't work properly?I have successfully removed the foo instance with qemu:///session connection.

(env_taskotron)[lnie@dhcp-128-50 testcloud]$ sudo testcloud instance -c qemu:///session remove foo
DEBUG:remove instance: foo
DEBUG:removing instance foo from libvirt.
DEBUG:Unregistering domain from libvirt.
DEBUG:removing instance /var/lib/testcloud/instances/foo from disk

You must not use sudo. If you use sudo, you're connecting to the session instance of root, which is... qemu:///system. So the way you run it, you're actually using qemu:///system.

lnie added a comment.Aug 12 2016, 4:27 AM

You must not use sudo. If you use sudo, you're connecting to the session instance of root, which is... qemu:///system. So the way you run it, you're actually >using qemu:///system.

I thought you saw a problem using "sudo",and we still have other kinds of problem to handle before I update the diff:)

lnie updated this revision to Diff 2476.Aug 12 2016, 4:51 AM

modify the diff according to great suggestion gotten from the revision

This looks good. I played with it and a few adjustments are needed, and hopefully that should be all.

testcloud/instance.py
87

This also needs to get connection='qemu:///system'. All places where find_instance is called need to provide the argument.

98

And we pass connection in here.

464–466

Please add something like:

else:
    log.warning('Domain "%s" not found in libvirt (%s). Was it removed already? Did you '
                'want to use a different libvirt connection?', self.name, self.connection)

If the user runs testcloud instance remove with wrong libvirt connection, at least he/she will be notified that the domain was not found (and he/she needs to remove it manually).

lnie updated this revision to Diff 2483.Aug 15 2016, 3:32 AM

update the diff

lnie added a comment.Aug 15 2016, 3:34 AM
In D956#18354, @kparal wrote:

This looks good. I played with it and a few adjustments are needed, and hopefully that should be all.

Looks professional now. Thanks for your great patience and time with this:)

kparal accepted this revision.Aug 15 2016, 9:31 AM

Thanks, I'll do some further minor changes and push this.

testcloud/instance.py
395–397

This does not make much sense. The fact that the domain can't be found means the connection is wrong, not that it was started already (in that case, it would have been found). I believe it only makes sense to print this kind of message for remove(), because we don't raise exceptions if we try to remove something that doesn't exist. For other cases (stop(), start()) the user already receives a "can't find" error.

This revision is now accepted and ready to land.Aug 15 2016, 9:31 AM
This revision was automatically updated to reflect the committed changes.