Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-12
12:07:24 openstackgerrit Merged openstack/nova master: Fix target_cell usage for scatter_gather_cells https://review.openstack.org/510691
12:09:13 gibi mdbooth: as far as I know every functional test uses the virt driver called FakeDriver so no libvirt driver is loaded and no libvirt/kvm is started in the functional env
12:09:18 openstackgerrit Matthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/511466
12:09:30 mdbooth gibi: That's what I thought, thanks.
12:10:12 bauzas mdbooth: the reason why I want to implement some functional tests using a LibvirtFixture
12:11:46 mdbooth bauzas: i.e. you specifically want to run libvirt/kvm?
12:12:11 mdbooth Or you don't and you use LibvirtFixture to do that?
12:12:40 mdbooth iirc, LibvirtFixture monkey patches libvirt-python to be semi-usefully faked, right?
12:13:52 bauzas mdbooth: no, something telling you : okay, here are my XML capabilities
12:14:02 bauzas faking the host
12:15:55 mdbooth Although I think we *could* test that the generated XML contains a serial number
12:16:31 mdbooth That might be better than tempest, tbh
12:16:35 gibi bauzas: libvirt already has support for that with a test:// connection url
12:17:17 gibi bauzas: but of course that would mean we have to run libvirt in the test env
12:24:50 bauzas gibi: I know about the libvirt fake conn
12:25:13 bauzas gibi: but for example, if I want to get some specific capabilities, then meh
12:27:15 gibi bauzas: you can specify the host capability in the test:// connection url so libvirt will report whathever you need
12:28:14 gibi bauzas: at some point in the past I planned to build something up with this but never actually did it
12:28:50 gibi bauzas: but totally on the side of bulding a test env that could cover the libvirt driver code
12:29:55 bauzas gibi: yup, you can do that but AFAIK there is a bug about what libvirt retuens
12:30:59 bauzas anyhow, I need to test
12:34:37 gibi bauzas: if it is buggy then I understand looking at other ways to do the test. I thought libvirt community uses the test:// connection to test libvirt so I assumed it is at least as good as libvirt
12:35:17 bauzas ok, I could try to do it then
12:35:27 bauzas anyway, working on a separate series as of now
12:35:48 gibi bauzas: I don't want to pressure anything :)
12:36:26 bauzas gibi: np :)
12:39:45 bhagyashris johnthetubaguy: Hi, I need some guidance for patch https://review.openstack.org/#/c/409644/ ?
12:41:27 openstackgerrit Hironori Shiina proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487
12:42:52 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Fully destroy instances during a hard reboot https://review.openstack.org/400384
12:45:23 bhagyashris johnthetubaguy: Actually as per our discussion I have bumped the api microversion and service version as well but there is one problem that is if user will request the backup image api for old microversion for example 2.45 then in that case it's raises the on my fix because as we are skipping the image creation for rotation 0
12:46:14 bhagyashris johnthetubaguy: *it raises KeyError
12:46:56 bhagyashris johnthetubaguy: at api side and returns the HTTP 500 internal server error
12:47:00 johnthetubaguy bhagyashris: that sounds incorrect to me. You should only skip the image creation if you user requests the new API version, if you are going that way. I guess you should skip the image upload and just delete the image for the older API version.
12:47:36 johnthetubaguy bhagyashris: as mentioned before, if its a new API microversion, it will need an approved nova-spec before it can be merged.
12:48:09 mriedem claudiub|2: can you take a look at these pike backports? need a final +2 https://review.openstack.org/#/q/topic:bug/1718455+branch:stable/pike
12:48:19 bhagyashris johnthetubaguy: yeah i am working on nova-apec
12:49:18 mriedem for other stable cores, we have a series of changes for fixes in pike starting here that need review https://review.openstack.org/#/c/509922/1
12:49:24 mriedem lyarwood: ^
12:49:29 lyarwood mriedem: ack
12:50:26 openstackgerrit Hironori Shiina proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487
12:52:09 openstackgerrit Eric Fried proposed openstack/nova master: Get auth from context for glance endpoint https://review.openstack.org/490057
12:52:24 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
12:52:41 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for neutron client https://review.openstack.org/509892
12:52:52 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for keystone conf & requests https://review.openstack.org/507693
12:53:56 mriedem dansmith: that person's instance 404 problem in the ML from ocata was using the wsgi stuff :)
12:54:13 mriedem almost wonder if we should delete those files in ocata
12:56:13 openstackgerrit Merged openstack/nova stable/pike: Support qemu >= 2.10 https://review.openstack.org/509774
12:56:15 bhagyashris johnthetubaguy: i am not clear about how i will skip the image creation for new api version because code to skip image creation is at /nova/compute/api/py and that is common code
12:56:28 mriedem bhagyashris: pass a flag
12:57:00 bhagyashris mriedem: ohh ok
12:57:25 mriedem check the microversion in the REST API handler code, and pass some flag down to the compute api, with the default being backward compatible
12:57:52 gibi mriedem: I saw your comment and left a question about possible solution inline in https://review.openstack.org/#/c/510938/2/nova/compute/manager.py
12:59:03 mriedem gibi: yeah was just replying
12:59:18 mriedem i forgot that ironic and vmware support rebuild
13:00:17 gibi if it just rebuild then we don't have to care (I guess) but if they support evacuation as well then we have to me smarter
13:00:46 mriedem yeah i know vmware deployments use evacuate,
13:01:20 mriedem because before dansmith robustified it, if you started up a 2nd nova-compute to manage the same cluster as another, it would think all of the instances were evacuated and delete them from the cluster
13:01:24 mriedem which people didn't like for some reason
13:02:06 mriedem i fondly remember being on several customer calls at ibm because of that issue
13:02:10 gibi I can imagine the how big was that dislike :)
13:03:16 gibi what if I just ask for all the compute nodes for this host before the loop and look up the needed node in the loop?
13:04:56 mriedem gibi: replied inline
13:05:14 mriedem you could also probably do that
13:05:33 mriedem i was suggesting lookup by host/node, cache the result
13:06:07 gibi OK. let's do that
13:07:12 mriedem so that made me think of something https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L752
13:07:30 mriedem if you force an evacuate for ironic or vmware, you're going to probably be busted
13:07:39 mriedem because you can only specify the host, but not the node
13:07:59 mriedem we just pick a node randomly from those available for the host
13:08:26 mriedem probably need to make a note of that in the API, and another reason why the force flag is bad
13:08:40 gibi could we be busted here as well? https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2787
13:08:53 gibi the _get_compute_info call also uses the compat call to the db
13:09:47 mriedem possibly
13:10:54 mriedem gibi: well, that's if you force
13:10:58 mriedem if you force, scheduled_node is None
13:10:58 mriedem https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2762
13:11:22 mriedem so another reason why forced host evacuate won't work for ironic or vmware
13:11:30 mriedem although does vmware still have multiple nodes? i can't remember
13:11:36 mriedem bauzas: ^?
13:11:43 gibi ahh OK
13:13:23 mriedem dims: remember long ago the thing you removed for the vmware driver in nova - was that for a single compute managing multiple clusters? or something to do with a 1:M host:node mapping for vmware?
13:13:34 mriedem i think it was the former
13:18:09 openstackgerrit priyaduggirala proposed openstack/nova master: Rename parameters in call() of nova/image/glance.py https://review.openstack.org/508533
13:21:12 kaisers Hi! If somebody with libvirt/assisted volume snapshot deletion experience could visit https://bugs.launchpad.net/nova/+bug/1716920 it'd be great, I'm stuck analyzing this.
13:21:13 openstack Launchpad bug 1716920 in OpenStack Compute (nova) "online snapshot deletion breaks volume info and backing chain (with remotefs drivers?)" [Undecided,New]
13:21:22 kaisers kashyap: ----^
13:21:54 kashyap kaisers: Hey, I noticed your latest update on the bug
13:22:13 kashyap kaisers: Wasn't ignoring it; just was looking at something more broken elsewhere
13:22:36 kaisers kashyap: no worries :)
13:22:38 kashyap kaisers: You say you're back to "square one"
13:23:01 kaisers I believed novas block rebase operation to be stuck but that was wrong
13:23:05 kashyap From your comment#6, what did you patch there while testing?
13:23:26 kaisers kashyap: debug log messages to see what's happening and if that operation is terminating
13:23:37 kaisers it does
13:23:49 kaisers I'm not sure if i read the libvirt log correctly
13:24:06 kaisers (comment #7)
13:27:45 kashyap kaisers: I'll look in a bit; I have 2 calls to attend now.
13:27:46 kaisers This version of the log excerpt is probably easier to read: http://paste.openstack.org/show/623456/
13:27:58 kaisers kashyap: yeah, thanks
13:27:59 kashyap kaisers: But here's some past notes of what to make of libvirt debug logs: http://lists.openstack.org/pipermail/openstack-dev/2016-October/105158.html

Earlier   Later