| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 10:13:06 | kashyap | artom: When you get time, can you confirm if I answered your questions on PS-11: https://review.opendev.org/#/c/506720/11/specs/train/approved/allow-secure-boot-for-qemu-kvm-guests.rst | |
| 10:13:15 | kashyap | (On the review is fine.) | |
| 10:18:37 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Run revert resize tests in nova-live-migration https://review.opendev.org/653498 | |
| 10:18:38 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert resize: wait for external events in compute manager https://review.opendev.org/644881 | |
| 10:18:38 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.opendev.org/639396 | |
| 10:20:40 | artom | kashyap, ya | |
| 10:23:34 | artom | kashyap, yep, your answers make sense | |
| 10:23:47 | artom | I'll leave it to your judgment on whether you want to include any of them in the spec proper :) | |
| 10:52:01 | kashyap | artom: Some of them I will. Next iteration coming soon to a Firefox tab near you :D | |
| 11:09:06 | jaypipes | kashyap: hmm, didn't I +2 that yesterday? did you push new revs? | |
| 11:09:15 | jaypipes | or am I confusing with the AMD SEV one... | |
| 11:09:33 | sean-k-mooney | jaypipes: you did | |
| 11:09:50 | sean-k-mooney | there was a few tiny nits that were fixed | |
| 11:10:43 | sean-k-mooney | oh sorry no i confused myself | |
| 11:10:43 | NewBruce | sean-k-mooney that workaround patch is holding up splendidly; but man is the live migration process dicey - any failure can really leave you messed up at times…. | |
| 11:11:03 | sean-k-mooney | jaypipes: you +2'd the sev one not the secure boot one | |
| 11:11:05 | NewBruce | but the workaround +1 so thanks for that | |
| 11:11:09 | sean-k-mooney | jaypipes: ignore me | |
| 11:12:10 | sean-k-mooney | NewBruce: way we know we can harden that code more, especially in the failure case | |
| 11:12:38 | sean-k-mooney | NewBruce: ill try and make the code a bit more presentable (pass tests) after the ptg | |
| 11:12:57 | NewBruce | aye, admittedly the cleanup is a complex beast and really depends on where the failure happens; but if the second ports are set up, you can be in for a bad time in some cases | |
| 11:13:22 | NewBruce | sean-k-mooney no worries mate; if i get some more time, ill try and dig into that flow a bit more | |
| 11:19:24 | sean-k-mooney | jaypipes: fyi if you have time to look at the latest revision of the sev spec https://review.opendev.org/#/c/641994/12 we shoudl be able to remove it form the PTG agenda assumeing your good with it still. | |
| 11:20:12 | jaypipes | sean-k-mooney: k, will try this afternoon. | |
| 11:20:23 | jaypipes | (need to get car repair done now) | |
| 11:21:04 | sean-k-mooney | car trouble is the worst, best of luck, hopfully its minor | |
| 11:29:28 | jaypipes | efried, aspiers: AMD SEV re-proposal +W'd | |
| 11:29:37 | jaypipes | sean-k-mooney: ^ | |
| 11:29:49 | sean-k-mooney | :) | |
| 11:30:02 | jaypipes | sean-k-mooney: and yeah, it's just a servicing. nothing major (I hope!) | |
| 11:36:55 | jaypipes | efried: what are the numbers that start off each bullet point/topic in the nova ptg train etherpad? for example: | |
| 11:36:57 | jaypipes | " 66 :30 Disabled compute service request filter (mriedem)" | |
| 11:37:03 | jaypipes | what does '66' mean there? | |
| 11:37:15 | sean-k-mooney | i had the same question | |
| 11:37:25 | sean-k-mooney | but didnt ask | |
| 11:37:46 | sean-k-mooney | how many bottels of beer we need? | |
| 11:39:32 | jaypipes | heh | |
| 11:40:24 | kashyap | jaypipes: Yeah, you're mixing up two different specs :-) | |
| 11:40:48 | kashyap | jaypipes: Mine is the Secure Boot spec (https://review.opendev.org/#/c/506720/) | |
| 11:40:57 | jaypipes | kashyap: ETOOMANYSPECS ;) | |
| 11:41:27 | kashyap | :-) Understandable. | |
| 11:44:47 | openstackgerrit | Merged openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.opendev.org/641994 | |
| 11:44:54 | openstackgerrit | Kashyap Chamarthy proposed openstack/os-traits master: Add CPU traits for Meltdown/Spectre mitigation https://review.opendev.org/655193 | |
| 11:45:03 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Add HW_CPU_X86_* traits for Meltdown/Spectre mitigation https://review.opendev.org/655191 | |
| 11:56:49 | kashyap | mdbooth_: When you're get a minute, a blast from the past: wanted to triple-check if I need to raise at all in the 'else' condition: https://review.opendev.org/#/c/639091/4/nova/virt/libvirt/driver.py | |
| 11:57:11 | kashyap | mdbooth_: (You have context for it; it is the "Make EBUSY handling suck less" thing) | |
| 11:57:37 | kashyap | s/you're get/you get/ | |
| 11:59:36 | kashyap | (I think I should 'raise' _something_ there.../me refreshes context) | |
| 12:20:02 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655332 | |
| 12:56:52 | hemna | hey guys, I have libvirt section in nova.conf setup to use rbd as the libvirt_images_type, to use ceph for all image storage, and yet the placement API says I don't have a provider with enough space to create an 80G vm (flavor m1.large) | |
| 13:04:04 | stephenfin | alex_xu: Firefox is really quite nice nowadays :) | |
| 13:04:37 | stephenfin | I'd argue better than Chrome in many cases (certainly resource utilization) | |
| 13:05:25 | lyarwood | hemna: https://review.opendev.org/#/c/650188/ is aiming to model that in Placement, I assume you don't have 80G of local disks? | |
| 13:05:41 | hemna | yah I don't have 80G in local disk | |
| 13:05:54 | alex_xu | ok, I can a try, I'm enough with the screen always scrolling automatically... | |
| 13:05:54 | hemna | hence the usage of ceph | |
| 13:07:16 | lyarwood | hemna: right, I was just trying to confirm that DISK_GB wouldn't be >= 80GB for the compute node | |
| 13:07:56 | hemna | http://paste.openstack.org/show/749699/ | |
| 13:08:01 | lyarwood | hemna: I guess that's a valid bug, you could use volumes to workaround it. | |
| 13:09:18 | hemna | I have a single compute node (devstack) | |
| 13:10:05 | lyarwood | so the pool doesn't even have 80GB in it? | |
| 13:12:59 | hemna | 6.5Tib available | |
| 13:15:53 | hemna | lyarwood: http://paste.openstack.org/show/749700/ | |
| 13:16:12 | hemna | walt-cloud-vms is my pool for nova | |
| 13:16:18 | hemna | nothing in it so far | |
| 13:18:06 | efried | jaypipes, sean-k-mooney: Those are my personal scratch notes for priority (lower==earlier) and estimated time needed. | |
| 13:18:58 | efried | alex_xu, stephenfin: What issues are you seeing with chrome+gerrit? I've been using that combo for years without heartache, but maybe I'm missing out on something amazing on Firefox | |
| 13:19:30 | hemna | hrmm | |
| 13:20:56 | stephenfin | efried: Oh, no issues on that particular use case for me: I use Firefox for other reasons (it performs better, supports pretty much everything Chrome doesn't, and is worth supporting to avoid a browser monoculture) | |
| 13:20:58 | alex_xu | efried: the screan always auto scrolling, and jump to another random place... | |
| 13:21:02 | efried | alex_xu: Oh, screen flickers up and down when reviewing big files/deltas? You can fix that by toggling the gerrit option: <your name> => Settings => Diff Options => Render => Slow | |
| 13:21:07 | alex_xu | s/screan/screen | |
| 13:21:20 | alex_xu | yes | |
| 13:21:31 | alex_xu | let me try | |
| 13:22:00 | lyarwood | hemna: sorry on a call, reading over the update_provider_tree code for the libvirt driver this should actually be set to the overall rbd pool size | |
| 13:22:11 | efried | It still jumps a little for me, but only occasionally, and it never does the thrashing thing it used to do. | |
| 13:22:11 | stephenfin | but the only time I've seen an autoscrolling issue in Gerrit is when I'm creating/editing a comment and I try to scroll down. It jumps me back up | |
| 13:22:17 | hemna | it's ok. I'm looking further | |
| 13:22:21 | lyarwood | hemna: can you confirm what placement actually has as DISK_GB for the compute node | |
| 13:22:35 | hemna | I just bounced n-cpu and none of the settings in the [libvirt] section of nova.conf are being used. | |
| 13:22:53 | alex_xu | efried: oh yeah, looks better, thanks | |
| 13:23:01 | efried | cool | |
| 13:23:08 | hemna | lyarwood: http://paste.openstack.org/show/749701/ | |
| 13:23:18 | alex_xu | yea, i saw a little jump, but far better than previous | |
| 13:24:12 | lyarwood | hemna: ah, so the images_type isn't rbd for some reason | |
| 13:24:24 | hemna | yah, it's all the defaults | |
| 13:24:30 | hemna | instead of what I have in nova.conf [libvirt] | |
| 13:24:34 | lyarwood | hemna: it's images_type | |
| 13:24:39 | lyarwood | hemna: not libvirt_images_type | |
| 13:24:59 | hemna | guess it was renamed ? | |
| 13:24:59 | lyarwood | hemna: you've prefixed everything with libvirt_* in there it seems | |
| 13:25:18 | hemna | bah ok | |
| 13:25:25 | hemna | I'll update that and retry | |
| 13:25:29 | hemna | not sure how/why I did that | |
| 13:25:46 | lyarwood | hemna: it has always been images_type, libvirt is just the config section. | |
| 13:26:25 | hemna | must have been a copy/paste from somewhere | |
| 13:28:51 | efried | alex_xu: Would you be willing to be the first contact liaison for your time zone, per http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005555.html ? | |
| 13:29:01 | hemna | hrmm that didn't do it | |
| 13:29:14 | hemna | looks like the conf is read from nova-cpu.conf not nova.conf ? | |
| 13:29:45 | lyarwood | yeah with devstack it is | |