Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-25
14:36:10 gibi mriedem: on the ptg I would like to get decision about 1) the microversion for move 2) the priority of the items in https://blueprints.launchpad.net/nova/+spec/enhance-support-for-ports-having-resource-request
14:36:20 aspiers efried: should it be checking the trait or the resource class? I guess only the trait is SEV-specific and so is the required XML, so maybe this is still correct
14:36:40 mriedem btw, we have a working multi-cell ci job https://review.opendev.org/#/c/655222/
14:36:53 efried aspiers: I would check the allocation. Remember, the request won't necessarily include the trait.
14:37:22 efried aspiers: So yeah, that should be amended at some point.
14:37:34 dansmith is this a known thing? http://logs.openstack.org/37/655137/2/check/openstack-tox-lower-constraints/6363387/testr_results.html.gz
14:37:36 efried You may want to open a change set with that, but leave it -W to collect such deltas as they arise.
14:37:43 dansmith testrpc fail
14:37:47 kashyap aspiers: BTW, to quickly answer on the SEV trait -- I'd suggest to keep it as-is: HW_CPU_AMD_SEV (in amd.py)
14:37:48 dansmith on a lower constraints job no less :)
14:37:55 aspiers efried: I was thinking the request filter could add not only resources:MEM_ENCRYPTION_CONTEXT=1 but also traits:HW_CPU_X86_AMD_SEV=required
14:37:59 efried dansmith: yes, that's bug...
14:38:06 kashyap aspiers: Because we'll be consolidating all AMD-related stuff in one place, as it should be.
14:38:14 efried dansmith: bug 1825435
14:38:15 openstack bug 1825435 in OpenStack Compute (nova) "TestRPC unit tests intermittently fail with "'>' not supported between instances of 'NoneType' and 'datetime.datetime'" - maybe due to "Fatal Python error: Cannot recover from stack overflow."" [High,Confirmed] https://launchpad.net/bugs/1825435
14:38:21 dansmith ack
14:38:31 aspiers kashyap: so not under HW_CPU_X86_AMD?
14:38:56 aspiers isn't that the opposite of what efried wrote 20 mins ago?
14:39:20 kashyap aspiers: Wait, disregard me. I'll re-read the chat and slow-respond later.
14:39:26 aspiers kashyap: OK :)
14:39:34 efried aspiers: We talked about this. The request filter shouldn't do that. The admin (or whoever authors the flavor/image-meta) should request SEV via the trait if they want SEV specifically. Otherwise you could theoretically land anywhere that supports mem enc.
14:40:01 aspiers efried: but at some point in the workflow the code needs figure out that SEV is the technology which will be used to implement it. Where should that happen?
14:40:26 aspiers I guess your point is that doing it in a request filter is too early
14:40:36 sean-k-mooney aspiers: in the virt dirver
14:40:41 efried aspiers: Right; at spawn time, libvirt will use the same mechanism it used to decide to expose that trait in the first place.
14:41:07 efried aspiers: ...or possibly just look for the trait itself as already exposed, not sure if you have access to the provider tree in spawn
14:41:14 sean-k-mooney placment will land the vm on a host that support mem encryption and then the virt driver can figure out which tech implementes it
14:41:20 efried ^
14:41:31 aspiers yeah makes sense
14:42:20 mriedem dansmith: yes
14:42:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable n-novnc in nova-multi-cell job https://review.opendev.org/655711
14:42:24 openstackgerrit Matt Riedemann proposed openstack/nova master: Add nova-multi-cell job https://review.opendev.org/655222
14:42:32 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Stop ignoring unknown libvirtError exceptions during volume attach https://review.opendev.org/655696
14:42:33 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Always disconnect volumes after libvirtError exceptions https://review.opendev.org/655712
14:42:38 mriedem http://status.openstack.org/elastic-recheck/#1825435
14:42:58 aspiers efried, sean-k-mooney: so other than updating the commit message and maybe the trait name, I think https://review.opendev.org/#/c/633855/ can remain the same
14:43:04 mriedem http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005392.html
14:43:07 dansmith mriedem: I didn't get an e-r report on it
14:43:20 mriedem dansmith: e-r bot has been off for weeks as far as i know
14:43:25 openstackgerrit Stephen Finucane proposed openstack/os-vif stable/stein: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655678
14:43:30 mriedem dansmith: i have a couple of debug patches up to try and recreate to figure out what's causing the recursion stack dump
14:43:30 aspiers efried, sean-k-mooney: and I'll add a separate review which adds the new config option and inventory of the new resource class from it
14:43:42 dansmith mriedem: consider me shamed
14:43:50 mriedem dansmith: https://review.opendev.org/#/q/topic:bug/1825435+status:open
14:44:10 mriedem if you have ideas on that it'd be cool because so far my recreate attempts are failing
14:44:32 mriedem it seems to have started somewhere along the lines of the cells v1 removal series
14:44:40 mriedem but looking through those changes i don't see anything obvious
14:44:54 mriedem it's in both py36 (upper-constraints) and lower-constraints so it's not some specific oslo.config version either
14:45:06 efried aspiers: I haven't reviewed that patch in forever, sorry.
14:45:14 mriedem i also didn't see any python3.6 changes recently in the bionic UCA changelog
14:45:36 dansmith mriedem: ack, I heard about the recursion thing, but this is a single output message (not a very long stack trace) so I didn't connect the two
14:45:37 aspiers efried: it's drastically simpler now
14:45:59 efried aspiers: I probably won't get a chance to review patches-that-aren't-specs until after the PTG dust settles.
14:46:07 mriedem dansmith: yeah the TestRPC ... inprogress seems to be a result of the stack dump earlier in the logs
14:46:16 aspiers efried: because kashyap persuaded me to split out most of it into https://review.opendev.org/#/c/655268/
14:46:17 mriedem the former doesn't always show up when this hits, but the latter does
14:46:25 efried aspiers: sight unseen, split is good.
14:46:30 aspiers efried: ok
14:47:17 kashyap Yeah, that split is useful -- because that split-up patch, which introduces getDomainCapabilities API, can be used by many other things
14:47:56 kashyap So it can be merged as a separate piece once we iron out any remaining wrinkles.
14:48:19 kashyap Thanks for doing the split, aspiers.
14:50:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Enable n-novnc in nova-multi-cell job https://review.opendev.org/655711
14:50:52 mriedem dansmith: btw https://review.opendev.org/#/c/655222/ is passing which is pretty exciting
14:51:26 dansmith mriedem: that's cool
14:52:41 dansmith mriedem: is that intended to be voting?
14:52:47 mriedem once that lands, i can throw a patch at the end of my cross-cell-resize series to enable resize and cold migrate across the cells
14:52:51 mriedem dansmith: yes
14:52:58 dansmith are you ready for it to go in?
14:53:12 mriedem we could recheck a few times if we care and then turn it on next week
14:53:18 mriedem i can also send a heads up to the ML
14:53:24 openstackgerrit garyk proposed openstack/nova master: VMware: populate datastore refs at init https://review.opendev.org/574688
14:53:28 mriedem if we want, we can land it as non-voting check only for now
14:53:41 mriedem but i'd really like it to be voting asap since we should have had this several releases ago
14:54:32 mriedem i'll post to the ML first
14:55:51 openstackgerrit garyk proposed openstack/nova master: Improve metadata performance https://review.opendev.org/615435
14:59:37 efried mriedem: Do we start -2ing pike patches now, unless they're security or something?
14:59:47 efried (and by "we" I mean stable folk)
14:59:47 mriedem no
15:00:06 mriedem that's pre-em process
15:00:11 mriedem because there was an eol
15:00:13 openstackgerrit Adam Spiers proposed openstack/nova-specs master: Update SEV work item to new approach based on MEM_ENCRYPTION_CONTEXT https://review.opendev.org/655717
15:00:23 mriedem with em we've done away with eol unless we can't manage the branch anymore (or don't want to)
15:00:35 aspiers efried, sean-k-mooney: ^^^ minor tweak based on discussion just now
15:00:37 efried so what does em actually mean?
15:00:56 efried how is it different from just continuing to backport changes?
15:01:41 mriedem efried: https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html
15:02:00 mriedem or https://superuser.openstack.org/articles/extended-maintenance-openstack/ if you like bloggy
15:02:06 sean-k-mooney efried: extended mainatince
15:03:06 efried aspiers: not quite, commented.
15:03:50 efried mriedem: ugh, I'm totally not going to read that much text right now. I'll satisfy my curiosity later.
15:04:31 mriedem mission accomplished
15:04:42 aspiers efried: OK thanks. I was thinking it could rely on the translation from hw:mem_encryption to resource class in the request filter, but checking allocations dict also sounds fine
15:05:07 efried aspiers: Remember that translation isn't being persisted, so the flavor spawn gets to look at won't have it.
15:06:21 aspiers efried: ohhhh, you mean that only happens in the scheduler, and the resulting RequestSpec doesn't get passed through to the nova-compute service?
15:06:23 efried mriedem: I've updated the nova mtg agenda
15:06:59 efried aspiers: Yes, iiuc. I could be missing something though
15:07:27 aspiers efried: that makes sense - this stuff isn't obvious to me yet since I'm still very unfamiliar with the nova codebase, so thanks for the pointers
15:07:28 efried aspiers: But IMO looking at the allocation is a cleaner solution regardless.
15:07:44 aspiers efried: yup, sounds fine to me
15:08:24 mtreinish aspiers: unfortunately I won't be at Denver. But I save that talk to watch later, at least based on the abstract it looks like they had a similar idea to what andreaf and I were starting to do in CIML (at a high level)

Earlier   Later