Modify the code to make the libvirt url actually configurable,
as described in https://phab.qadevel.cloud.fedoraproject.org/T817
lbrabec | |
kparal | |
tflink | |
jskladan |
Modify the code to make the libvirt url actually configurable,
as described in https://phab.qadevel.cloud.fedoraproject.org/T817
just run testcloud as normal to see whether it still works well
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
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":) |
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
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: )
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.
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
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.
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:)
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). |
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. |
The new parameter should be added to the docstring.