| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-16 | |||
| 16:56:43 | dansmith | we don't have to do something if we restart the db today, right? | |
| 16:56:55 | dansmith | it reconnects for us I think, so I'm not sure we need to actually worry about things going stale | |
| 16:57:03 | dansmith | and by conf change, I mean changing a cell record or something | |
| 16:57:10 | melwitt | I don't think so, no. good point | |
| 16:57:27 | melwitt | yeah, understood. like changing a connection string | |
| 16:57:33 | sean-k-mooney | cfriesen: you dont need nested virt you just need the kvm module loaded in the vm | |
| 16:57:35 | dansmith | right | |
| 16:57:48 | cfriesen | sean-k-mooney: the kvm module won't load without nested KVM | |
| 16:58:07 | sean-k-mooney | if they are using virt_type=qemu they cannont use any form of cpu pinning becasue TSG does not support it | |
| 16:58:23 | cfriesen | sean-k-mooney: it accepts the commands, it just doesn't work properly. :) | |
| 16:58:50 | sean-k-mooney | libvirt throws an error though whne you try to spawn the vm from nova | |
| 16:59:19 | cfriesen | sean-k-mooney: not ours...wonder what version that was added in | |
| 16:59:37 | sean-k-mooney | cfriesen: i am testing with qemu 2.8 | |
| 17:00:04 | sean-k-mooney | i also have libvirt 3.3 form master currently but this happens on older version too | |
| 17:00:22 | cfriesen | sean-k-mooney: I'm on qemu 2.6 and libvirt 2.0 | |
| 17:01:25 | sean-k-mooney | cfriesen: im a litlle unfortable adding a new conf option just for this as well if we do they are almost impossible to get rid of | |
| 17:01:33 | cfriesen | sean-k-mooney: we can work around it if necessary | |
| 17:02:08 | sean-k-mooney | cfriesen: do you know is there any way to query this from qemu/libvirt so we could decet at runtime? | |
| 17:03:55 | cfriesen | sean-k-mooney: no clue. :) I'm a bit surprised that your libvirt complains since for the most part (especially for single-vcpu guests) it seems to work okay. | |
| 17:06:43 | sean-k-mooney | cfriesen: i think it is actully qemu that is complaining rather then libvirt it just passes along the message | |
| 17:07:39 | sean-k-mooney | cfriesen: libvirt happilly accpts the xml as it is vailid but TCG then complaines when qemu is starting the instance | |
| 17:35:38 | openstackgerrit | Gage Hugo proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148 | |
| 18:04:17 | shewless | Hi. I have an openstack installation that has a working spice console (I can connect to the console via horizon). I'm trying to connect to the console using "virt-viewer" or some other local client instead of from the web. Any hints on how to do this? | |
| 18:04:34 | openstackgerrit | Gábor Antal proposed openstack/nova master: Transform keypair.delete notification https://review.openstack.org/463946 | |
| 18:05:08 | shewless | Basically I think that nova is serving spice via the html viewer over a proxy .. but I want to access the spice server directly using a spice client (to get audio, etc). | |
| 18:15:29 | sean-k-mooney | shewless: i belive 'nova help get-spice-console' will provide the info you are looking for | |
| 18:18:17 | sean-k-mooney | shewless: for my setup at least i dont see a way to connect directly to the spice console though | |
| 18:18:58 | sean-k-mooney | shewless: the different console types available are ['novnc', 'xvpvnc', 'rdp-html5', 'spice-html5', 'serial', 'webmks'] but not just spice | |
| 18:27:31 | shewless | sean-k-mooney: yeah that command gives me the spice url.. but I haven't been able to use my spice client to connect to that url | |
| 18:27:40 | shewless | I think because it's "http" and not "spice" protocol | |
| 18:28:51 | sean-k-mooney | shewless: ya im not sure that nova support direct connection as the client would have to connect directly to spice port on the vm via the compute node | |
| 18:29:40 | shewless | sean-k-mooney: fair enough. Is there a way to get sound to work through the spice html proxy? | |
| 18:30:24 | jose-phillips | hey | |
| 18:30:48 | sean-k-mooney | not that i have found though usally i just use x11 forwarding over ssh or install vnc in the guest and connect to it over its public ip so i have never tried | |
| 19:12:33 | mriedem | smcginnis: https://github.com/openstack/nova/commit/564f14f4bc67463d1ef185909e12ab090f10495b ? | |
| 19:13:25 | mriedem | smcginnis: policy is defined in code here https://github.com/openstack/nova/blob/master/nova/policies/assisted_volume_snapshots.py | |
| 19:13:56 | smcginnis | mriedem: Seeing this: http://logs.openstack.org/51/418451/12/check/gate-tempest-dsvm-full-devstack-plugin-nfs-nv/0f06284/logs/screen-c-vol.txt.gz?level=ERROR#_May_16_08_29_46_647815 | |
| 19:15:16 | smcginnis | mriedem: And http://logs.openstack.org/51/418451/12/check/gate-tempest-dsvm-full-devstack-plugin-nfs-nv/0f06284/logs/screen-n-api.txt.gz#_May_16_08_29_46_642168 | |
| 19:16:12 | mriedem | smcginnis: https://github.com/openstack/tempest/commit/529eefabc937b6dc6f7b3fae11b5942cc6ee452e | |
| 19:16:14 | mriedem | new tempest change | |
| 19:16:21 | mriedem | tempest doesn't gate on FS-style volume backends | |
| 19:16:23 | mriedem | so that's probably it | |
| 19:16:47 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Forbidden%3A%20Policy%20doesn't%20allow%20os_compute_api%3Aos-assisted-volume-snapshots%3Acreate%20to%20be%20performed.%20(HTTP%20403)%5C%22&from=7d | |
| 19:16:50 | mriedem | so yeah that's it | |
| 19:18:12 | armax | mriedem: we have a winner | |
| 19:18:13 | armax | http://logs.openstack.org/25/465125/1/experimental/gate-tempest-dsvm-neutron-pg-full-ubuntu-xenial/2a7a080/ | |
| 19:18:32 | mriedem | armax: sweet | |
| 19:19:07 | armax | mriedem: nice one | |
| 19:19:14 | armax | mriedem: you need to add a test now ;) | |
| 19:19:24 | mriedem | armax: yup, working on it | |
| 19:19:28 | armax | mriedem: you rock | |
| 19:19:40 | mriedem | smcginnis distracted me with all of his NFS love | |
| 19:22:14 | armax | mriedem: do you want to rerun the job to confirm if there’s another race lurking? | |
| 19:22:40 | armax | mriedem: I thought you learned the craft of multitasking when you became PTL | |
| 19:23:41 | mriedem | armax: i can run it again yeah while i work on tests | |
| 19:24:17 | armax | mriedem: does Zuul listens to one whilst there’s still another ongoing run? | |
| 19:24:33 | armax | oh | |
| 19:24:35 | armax | never mind | |
| 19:24:44 | mriedem | armax: i didn't see that you checked experimental before i did | |
| 19:24:50 | mriedem | so i'll have to do it again once that run is done i think | |
| 19:24:56 | armax | didn’t notice that jenkins came back, we’re good | |
| 19:24:59 | mriedem | artom_: let me know if i'm off base here https://review.openstack.org/#/c/415520/ | |
| 19:34:23 | mriedem | armax: do we need to worry about the subnet being gone too? | |
| 19:34:32 | mriedem | L450 | |
| 19:35:34 | openstackgerrit | sean mooney proposed openstack/nova master: do not set vcpu_pin elements when virt_type=qemu https://review.openstack.org/465160 | |
| 19:38:23 | artom_ | mriedem, will do, thanks for the comments! | |
| 19:39:45 | mriedem | artom: i think we should just get the device metadata first, then attach to the guest, and then if that's fine, do instance.save() to update the db | |
| 19:39:57 | mriedem | then we don't have to worry about rolling back the detach in the guest | |
| 19:43:01 | armax | mriedem: I’ll reply on the review | |
| 19:51:16 | artom | mriedem, do we have what we need to build the metadata if we do so before attaching? | |
| 19:51:30 | artom | I'm thinking of PCI and/or MAC addresses | |
| 19:52:23 | mriedem | artom: oh i guess i didn't dig into _build_device_metadata, but that reads from the guest xml doesn't it? | |
| 19:52:37 | mriedem | to correlate the tag with the device or something | |
| 19:52:49 | artom | mriedem, yeah | |
| 19:52:53 | mriedem | :( | |
| 19:53:32 | artom | mriedem, you're basically trying to answer the question "what happens if _build_device_metadata fails?" right? | |
| 19:54:07 | artom | Because the try block it's in only handles libvirtError... | |
| 19:54:12 | mriedem | yeah | |
| 19:54:39 | mriedem | as noted, the compute manager will handle any NovaException that comes out of the driver.attach_interface method | |
| 19:55:02 | mriedem | but that only deallocates the port, which if it's a pre-existing port is an unbind of the host on the port, if nova created the port then nova deletes the port, | |
| 19:55:15 | mriedem | which would trigger a network-vif-deleted event, and nova would get that and detach the interface from the guest, | |
| 19:55:26 | mriedem | but i'm worried about the case the the port was provided to nova to attach to the instance, and we just unbind it, | |
| 19:55:39 | mriedem | i don't think we'll get a network-vif-deleted event from neutron in that case, because it wasn't deleted | |
| 19:55:49 | mriedem | and we wouldn't detach the interface from the guest | |
| 19:57:30 | artom | That raises a question about the semantics of tagged attach, namely, do we fail the whole thing if only the tagging part fails | |
| 19:59:54 | artom | In situations like this I really miss Java's stricter exception system | |
| 20:21:02 | mriedem | artom: well, | |
| 20:21:25 | mriedem | if i'm attaching an interface with a tag and the interface shows up in my guest but the tag doesn't, i'm going to wonder wtf happened and create a support ticket, | |
| 20:21:38 | mriedem | so i'm thinking if any of the operation fails, it all needs to fail | |
| 20:21:41 | mriedem | and rollback the attach | |
| 20:32:12 | artom | mriedem, yeah. If we had a way to communicate partial failure to the user it might have been different, but we don't | |
| 20:32:50 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make the method to put allocations public https://review.openstack.org/464086 | |
| 20:32:50 | openstackgerrit | Ed Leafe proposed openstack/nova master: Have scheduler claim resources https://review.openstack.org/463993 | |
| 20:32:51 | openstackgerrit | Ed Leafe proposed openstack/nova master: Pass a list of instance UUIDs to scheduler https://review.openstack.org/465171 | |
| 20:33:37 | artom | mriedem, I feel like the cleanest would be to catch _build_device_metadata failures in attach_interface and unplug the vif, like we currently do upon libvirtError | |
| 20:34:22 | mriedem | artom: yeah probably, | |
| 20:34:34 | mriedem | then we'll get the network-vif-unplugged event from neutron | |
| 20:35:01 | mriedem | but, i don't think we handle that | |
| 20:35:08 | mriedem | 'instance'), | |
| 20:35:08 | mriedem | LOG.warning(_LW('Received unexpected event %(event)s for ' | |