Earlier  
Posted Nick Remark
#openstack-nova - 2019-05-17
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 'statistic_aggregation', autospec=True)
14:13:49 mriedem @mock.patch.object(ceilometer_helper.CeilometerHelper,
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 aggregation='avg', group_by='*'):
14:53:35 mriedem period=300, granularity=300, dimensions=None,
14:53:35 mriedem def statistic_aggregation(self, resource_id=None, meter_name=None,
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.
15:24:11 aspiers each of those subject to the whims of the respective country
15:24:12 openstackgerrit Merged openstack/python-novaclient master: Optimize limit option docs string description for novaclient https://review.opendev.org/643035
15:24:53 aspiers I wonder if it could result in situations where Huawei-related work could get taken off the hands of American members of a team and given to colleagues in other countries
15:24:58 artom aspiers, in our case even our non-US companies are subject to the embargo
15:25:09 aspiers interesting, why's that?
15:25:13 artom IANAL
15:25:18 aspiers because the parent company is US? or some other reason
15:25:26 artom I guess
15:25:44 aspiers if so, SUSE wouldn't have the same issue
15:25:47 artom But yeah, we got a pretty strongly worded email that we essentially need to stop all dealings with Huawei, all over the world

Earlier   Later