| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-17 | |||
| 13:56:11 | sean-k-mooney | kashyap: stephenfin is not seing vitio in the domcapablities output on f30 | |
| 13:56:42 | stephenfin | I'm referring to lines 101-105 from here http://paste.openstack.org/show/751514/ | |
| 13:56:53 | stephenfin | It doesn't matter much. More curiosity than anything | |
| 13:56:57 | kashyap | stephenfin: Can you post your `rpm -qa | grep -i qemu` output? | |
| 13:57:21 | kashyap | sean-k-mooney: Check this one that i did recently: https://github.com/rdo-packages/nova-distgit/commit/4e490d2348cfe99b68d70c4b95408348d0b54492 (" Use granular libvirt and QEMU RPMs for EL-8 Nova") | |
| 13:57:27 | stephenfin | kashyap: http://paste.openstack.org/show/751515/ | |
| 13:57:31 | sean-k-mooney | stephenfin: well its novas default for qemu | |
| 13:57:36 | sean-k-mooney | and kvm | |
| 13:57:46 | sean-k-mooney | so if it really is not there your vms wont boot | |
| 13:58:02 | kashyap | stephenfin: Can you install 'qemu-kvm-core'? | |
| 13:58:05 | sean-k-mooney | unless you set hw_disk_bus=sata in the image or something | |
| 13:58:35 | sean-k-mooney | kashyap: waith how is qemu-kvm install without qemu-kvm-core | |
| 13:58:37 | kashyap | stephenfin: The domainCapabilities output you posted -- is that from F30? | |
| 13:58:42 | sean-k-mooney | that seam like a packageing bug | |
| 13:58:51 | stephenfin | kashyap: Done. No good. That paste is from sean-k-mooney | |
| 13:59:07 | kashyap | sean-k-mooney: Hang on -- I find it strange, too many things flying around :-) | |
| 13:59:40 | stephenfin | Here's mine, fwiw http://paste.openstack.org/show/751516/ | |
| 13:59:53 | stephenfin | 5.0.16-300.fc30.x86_64 | |
| 14:00:03 | sean-k-mooney | kashyap: :) that ws from manjor/arch with the latest libvirt available. | |
| 14:00:27 | sean-k-mooney | stephenfin: i see it on my popos system too with libvirt 4.0.0 so its not a libvirt issue i dont think | |
| 14:02:44 | roukoswarf | any recommendations on how to get nova scheduler to anti-affinity a bigger unit than a "host"? i have many "hosts" in a single chassis, or sometimes a single rack, and i need the ability to get something like octavia to schedule things to different chassis/racks for HA. | |
| 14:03:38 | roukoswarf | masses of cells seems like... the wrong solution? | |
| 14:06:46 | kashyap | sean-k-mooney: It is _not_ a packaging bug: in stephenfin's paste: you _do_ have: qemu-system-x86-core-3.1.0-8.fc30.x86_64 | |
| 14:06:56 | kashyap | It is 'qemu-system-$ARCH-core' | |
| 14:08:11 | kashyap | (Also note: 'qemu-kvm-core' is a _dummy_ package that pulls in 'qemu-system-x86' on Fedora) | |
| 14:11:20 | mriedem | efried: remind me, mock spec is a string right? https://review.opendev.org/#/c/659726/2/watcher/tests/datasources/test_ceilometer_helper.py | |
| 14:11:31 | kashyap | stephenfin: You need libvirt-5.2.0 or newer to get the virtio-* enum values reported. | |
| 14:11:44 | efried | mriedem: no, it is *not* a string. Unless you want to spec a string. | |
| 14:11:55 | mriedem | gdi | |
| 14:12:24 | efried | hold on, I have a commit that explains it clearly (I hope) | |
| 14:12:41 | kashyap | stephenfin: It's noted "v5.2.0 (2019-04-03) | |
| 14:12:49 | efried | mriedem: https://review.opendev.org/#/c/650370/ | |
| 14:13:02 | kashyap | stephenfin: Err. I meant: It's noted as part of the release notes of libvirt "v5.2.0 (2019-04-03)" here: https://libvirt.org/news.html | |
| 14:13:48 | mriedem | so i just changed to this (added autospec=True): | |
| 14:13:49 | mriedem | @mock.patch.object(ceilometer_helper.CeilometerHelper, | |
| 14:13:49 | mriedem | 'statistic_aggregation', autospec=True) | |
| 14:13:53 | mriedem | and it blew up as expected | |
| 14:13:58 | mriedem | so why not just autospec? | |
| 14:15:50 | mriedem | i think the answer is "sometimes it doesn't work how you'd expect" is the answer | |
| 14:15:55 | mriedem | like everything with specs and mock | |
| 14:25:29 | stephenfin | mriedem: claudiub has a series to convert everything to autospec. Would it be worth reviving that? | |
| 14:25:49 | stephenfin | aspiers: Reviewed https://review.opendev.org/#/c/655268/. One concern about logging but otherwise it looks good | |
| 14:30:48 | openstackgerrit | Mark Goddard proposed openstack/nova master: [ironic] Don't remove instance info twice in destroy https://review.opendev.org/659809 | |
| 14:30:52 | efried | aspiers, kashyap: reviewed same, soft-ish -1 on some refactoring to make things cleaner. | |
| 14:31:37 | efried | stephenfin: If those guys aren't around rn, maybe you could look and tell me if I'm way off base with my comments; maybe there's some reason we put in extra fluff. | |
| 14:31:55 | stephenfin | sure | |
| 14:32:27 | kashyap | efried: Just skimmed (in a call); thanks for the detailed review. I'll pay full attention to your comments on Monday. | |
| 14:33:16 | efried | thanks both | |
| 14:35:24 | kashyap | Thank _you_ for spending a block of time on it. | |
| 14:35:47 | mriedem | stephenfin: this isn't a question for nova really | |
| 14:35:59 | mriedem | it's a generic dev thing | |
| 14:36:05 | mriedem | trying to apply it to a bug fix in watcher | |
| 14:37:01 | stephenfin | efried: Yup, they all look valid. I was ignoring the added config opts because I saw them used in later patches, but adding them then might make more sense, aye | |
| 14:37:10 | stephenfin | *config classes | |
| 14:37:26 | stephenfin | mriedem: Ah, fair. I didn't catch that | |
| 14:45:35 | efried | stephenfin: I'm less concerned about that than about the unnecessary middleman class | |
| 14:47:00 | cdent | mriedem: are your wips on https://review.opendev.org/#/q/topic:bug/1790204 still a going concern? | |
| 14:47:35 | mriedem | cdent: as in vmware needs them now? | |
| 14:47:43 | cdent | no, I'm writing the pupdate | |
| 14:47:47 | mriedem | oh | |
| 14:48:14 | mriedem | it's very complicated so i'm not working on it regularly no, maybe once per month before i write up my internal monthly report :) | |
| 14:48:52 | cdent | i'll keep them on the list as why not... | |
| 14:51:23 | mriedem | efried: this is why spec baffles me http://paste.openstack.org/show/751523/ | |
| 14:51:29 | mriedem | note expected and actual are identical | |
| 14:51:46 | mriedem | not sure wtf "b'TypeError: too many positional arguments'" is about | |
| 14:52:14 | mriedem | this being the test http://paste.openstack.org/show/751524/ | |
| 14:52:47 | efried | mriedem: what's the method signature for statistic_aggregation? | |
| 14:53:35 | mriedem | def statistic_aggregation(self, resource_id=None, meter_name=None, | |
| 14:53:35 | mriedem | period=300, granularity=300, dimensions=None, | |
| 14:53:35 | mriedem | aggregation='avg', group_by='*'): | |
| 14:54:14 | mriedem | is it complaining that kwargs aren't used for all params? | |
| 14:54:16 | efried | This looks to be a buglet in mock itself; it's confusingly triggering a failure on assert_called_once_with | |
| 14:54:18 | efried | yes | |
| 14:54:28 | efried | that's a little weird, but I'm a fan. | |
| 14:54:39 | efried | kwargs should be named | |
| 14:54:48 | mriedem | i've seen the tattoo | |
| 14:58:23 | aspiers | sean-k-mooney: yes, I got the sample XML from an SEV-capable test box | |
| 14:59:10 | mriedem | changing to use all kwargs results in an even weirder error, so i'll just not try spec | |
| 15:00:15 | mriedem | oh nvm | |
| 15:13:34 | artom | mriedem, yey, we can talk to you again! | |
| 15:13:57 | artom | Had some scary legals emails about the Huawei embargo thing | |
| 15:14:05 | aspiers | artom: :-( | |
| 15:14:12 | aspiers | what a crappy situation | |
| 15:14:35 | aspiers | also I'm guessing pretty unprecedented and nonsensical in an open source context | |
| 15:14:59 | jangutter | I am so glad South Africa is no longer under sanctions. | |
| 15:16:11 | mriedem | artom: i've heard | |
| 15:16:22 | mriedem | realize that i already know all of your secrets before you tell me | |
| 15:16:42 | artom | If you knew all my secrets you'd be in an asylum | |
| 15:19:16 | artom | aspiers, it's definitely weird... though I suspect if there's on legal department that can make sense of it, it's RH's, given our open source history | |
| 15:19:21 | artom | *one legal | |
| 15:19:59 | aspiers | or SUSE's - a few months older than RH even ;-) | |
| 15:20:07 | aspiers | although we're no longer an American company | |
| 15:20:13 | aspiers | so maybe we don't need to care as much | |
| 15:20:48 | aspiers | I'm sure RH has a much more impressive army of lawyers than we do too | |
| 15:22:23 | artom | True, though being German (albeit with US... affiliates?) they may not be subjected to the same laws | |
| 15:22:39 | aspiers | We're not German | |
| 15:22:46 | aspiers | Owned by EQT which is Swedish | |
| 15:23:02 | aspiers | but we have companies in many countries around the world, just like RH | |
| 15:23:28 | aspiers | so yeah, there'll be a SUSE Inc. or whatever | |
| 15:23:44 | aspiers | and SUSE GmbH, SUSE UK Ltd. etc. | |