Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-01
15:44:38 mriedem alex_xu: gibi: replied in https://review.openstack.org/#/c/539658/ - see what you think, it's nuanced for sure
15:45:11 edleafe gibi: sure, that would work. I considered doing a shift of 8 instead of 1 for the same reason, but I thought an explicit shift-unshift difference would be less likely to be confusing. IOW, a real entry is shifted for creating a marker, and unshifted to return to the original value
15:45:20 mriedem kashyap: stephenfin: there has already been a "next version" in the driver since pike, so we'd use that,
15:45:29 mriedem the question is what the next version would be after that
15:45:34 jroll mgoddard_: that looks complicated :|
15:45:44 mriedem which is likely whatever our min is for supported distros today
15:45:55 stephenfin mriedem: Yup, that's the version I'm referring to
15:45:57 kashyap mriedem: Ah, right. We're looking for the one _after_
15:46:23 mgoddard_ jroll: I think we just need to report inventory for nodes with instances
15:47:00 jroll mgoddard_: we should be already, is the thing
15:47:15 mgoddard_ jroll: nope https://github.com/openstack/nova/blob/d25feca/nova/virt/ironic/driver.py#L758
15:47:33 jroll mgoddard_: right, tracking it down, because that's the real bug like you say
15:47:58 mgoddard_ jroll: I think we didn't then briefly we did, then we didn't again :)
15:48:34 jroll mgoddard_: yeah we broke that. sigh.
15:48:51 mgoddard_ I think this fixed it briefly: https://github.com/openstack/nova/commit/c92337bdf80fea4c0a8ebb433bacec4cc07f7a94
15:49:12 mgoddard_ jroll: then this broke it again: https://github.com/openstack/nova/commit/d25feca90ec4bad6ec9ececedced63b9f00b4c87
15:49:27 gibi edleafe: I don't know why shifting by 1 is more explict that shifting by 8. In the other hand you can keep shift and un_shift function so that the client code will be explict but simply calls shift from un_shift to make the implementation simpler
15:49:59 mgoddard_ jroll: there's also the matter of this TODO: https://github.com/openstack/nova/blob/d25feca/nova/virt/ironic/driver.py#L753
15:53:28 edleafe gibi: the explicitness is that as written, shift(shift(uuid)) will not return the original value. IOW, you have to be explicit that you are encoding/decoding
15:54:48 jroll mgoddard_: hm, I'm not sure the best way to handle this, though completing that todo may just solve it forever :)
15:55:20 mgoddard_ jroll: +1, but seems late in the cycle for that change
15:56:11 jroll mgoddard_: agree, though if it's just spurious logs, I think it's fine to wait
15:57:05 gibi mriedem: see my answer in https://review.openstack.org/#/c/539658/1/doc/source/user/placement.rst@279
15:58:42 gibi edleafe: this is why I suggest to keep shift and un_shift for the caller. So on the caller side it is explicitly encode/decode the marker. But the implementation can be like un_shift(uuid): return shift(uuid) and shift(uuid) can also be written in a single line
15:59:52 gibi mriedem: I would go for less options to avoid some later confusions
16:00:06 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: trivial: Resolve Python 3 issues https://review.openstack.org/539907
16:00:46 edleafe gibi: ok, that's fair. Not sure why a one-line function is desireable, though
16:00:55 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass limit to /allocation_requests https://review.openstack.org/531517
16:02:18 mgoddard_ jroll: yeah I guess so
16:05:16 gibi edleafe: it is not the one linenes that really matters, but the simple reverse has a smaller cyclomatic complexity as well
16:07:30 openstackgerrit Eric Fried proposed openstack/nova master: Ensure resource classes correctly https://review.openstack.org/539738
16:07:42 melwitt mriedem: ack, will review
16:08:01 efried jaypipes: The above fixes a bug I *do* think we need resolved in Q.
16:08:18 efried edleafe, cdent: may also interest y'all.
16:09:00 edleafe efried: ack. In meeting hell today.
16:09:09 efried no worries
16:12:55 openstackgerrit Eric Fried proposed openstack/nova master: Avoid inventory DELETE API (no conflict detection) https://review.openstack.org/539712
16:19:18 mriedem stephenfin: you know zuulv3 things, care to take a look at the nova-multiattach job? https://review.openstack.org/#/c/532689/
16:19:24 mriedem dependent patches are approved
16:19:45 stephenfin Sure thing
16:19:56 mriedem thanks; will be good to not regress that stuff
16:36:53 mriedem ameeda: easy docs bug to fix in cinder https://bugs.launchpad.net/cinder/+bug/1711267
16:36:55 openstack Launchpad bug 1711267 in Cinder "Boot from volume in cinder" [Undecided,New]
16:36:58 mriedem has some broken links
16:51:41 stephenfin mriedem: Comments left
16:59:09 mriedem stephenfin: replied; i'm not sure i follow your confusion though
17:00:22 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Make sure that we have usable input for graphical console https://review.openstack.org/538003
17:01:25 hrw mriedem, stephenfin: rewroted. now it adds usb host controller if there is none and adds usb keyboard if there is no keyboard. and does it on !(x86(-64), ppc64, s390x) architectures
17:02:49 jaypipes efried: IBM PowerKVM CI failure. I'll wait until that is resolved.
17:03:25 efried jaypipes: PowerKVM? Non-voting, right? I've been steadfastly ignoring that guy.
17:03:40 jaypipes efried: I was joking with you.
17:03:50 efried jaypipes: PowerVM failures are due to the fact that esberglu is rebuilding some CI systems, I think.
17:03:53 jaypipes efried: clearly, you do not share my brand of humour.
17:04:25 hrw jaypipes: https://review.openstack.org/538003 ^^ ;D
17:04:33 efried jaypipes: Sorry, the gate has me grumpy about CI holding up patches.
17:05:03 efried jaypipes: Just for that, I'm going to put you down as the approver for this blueprint I'm writing up.
17:05:22 mmedvede PowerKVM is voting, but it is not blocking, i.e. it can not prevent a patch with +2+w from merging
17:05:43 esberglu efried: Huh? I'm not doing anything with prod CI, just staging
17:05:55 esberglu Oh this is PowerKVM we're talking
17:06:32 efried esberglu: Okay, so I should be able to recheck powervm failures?
17:06:55 efried esberglu: Seeing OOT failures pretty frequently.
17:07:04 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: trivial: Resolve Python 3 issues https://review.openstack.org/539907
17:07:23 jaypipes hrw: I thought mriedem was a no go on that getting in Queens?
17:07:34 jaypipes efried: :P
17:08:23 hrw jaypipes: how that holds you from reviewing?
17:08:46 esberglu efried: Yeah recheck. Only 1 issue hitting OOT, was gonna have someone from REST take a look this afternoon
17:08:55 efried ight
17:09:25 hrw jaypipes: for me it may land in Rocky cycle as well as in Queens. I just have spare time now as what I wanted to have in nova/Queens got merged.
17:09:44 mriedem the usbhost controller for aarch64 is a bug
17:09:53 mriedem working around a limitation in libvirt for non-x86
17:09:54 hrw jaypipes: just prefer to have it reviewed when I still remember what is it all about
17:09:54 mriedem so that's fine
17:09:56 efried stephenfin: I think if we get up to PS4, you have to remove "trivial".
17:10:11 stephenfin Hahaha
17:10:12 hrw mriedem: is not a bug. but also not a feature
17:10:18 stephenfin efried: Touche :)
17:10:26 esberglu efried: And I would say pretty frequently is a stretch :)
17:10:44 esberglu OOT has failed like 6 times in the last 2 days (and at least 1 was a bad patch)
17:10:47 efried esberglu: Okay; first three I looked at just now.
17:10:53 hrw libvirt devs are very curious about changing defaults so I made patch for nova to do what needs to be done
17:11:02 jaypipes hrw: https://wattsupwiththat.files.wordpress.com/2015/09/not_a_bug_but_a_feature.jpg
17:11:13 stephenfin mriedem: So QEMU broke something and then libvirt managed to fix it?
17:11:46 stephenfin Meaning libvirt 3.10+ and any version of QEMU (including 2.10?) would work?
17:11:54 hrw https://www.redhat.com/archives/libvir-list/2018-February/msg00043.html is thread on libvirt ML if someone want
17:12:15 stephenfin But not libvirt < 3.10 and QEMU >= 2.10?
17:13:19 hrw stephenfin: nevermind which version they change situation I may still end with nova on aarch64 with older libvirt/qemu combo so https://review.openstack.org/538003 is a way
17:13:58 stephenfin hrw: Um, come again?
17:14:22 stephenfin hrw: I was referring to https://review.openstack.org/#/c/532689/, btw
17:14:28 hrw stephenfin: ah
17:14:48 hrw sorry, too late for me probably
17:15:01 hrw multiattach is qemu 2.10+ yes
17:15:09 hrw or sth
17:24:20 cfriesen mriedem: release note has been added as per your request for https://review.openstack.org/#/c/520187/
17:25:02 mriedem cfriesen: ok but i'm not looking at that until after queens
17:25:48 mriedem stephenfin: you can do multiattach if (1) qemu<2.10 or (2) libvirt>=3.10 (regardless of qemu version)
17:26:00 mriedem libvirt 3.10 does a thing to make it work with qemu 2.10+
17:26:04 mriedem for shared disks
17:26:52 mriedem stephenfin: https://bugzilla.redhat.com/show_bug.cgi?id=1378242
17:26:54 openstack bugzilla.redhat.com bug 1378242 in libvirt "QEMU image file locking (libvirt)" [Unspecified,Verified] - Assigned to pkrempa
17:27:08 stephenfin mriedem: Right, figured out the source of my confusion. It was this https://review.openstack.org/#/c/532214/

Earlier   Later