| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-25 | |||
| 14:33:41 | efried | aspiers: I know of no graphical tool, but that definitely doesn't mean there isn't one. Might ask the infra guys | |
| 14:33:42 | kashyap | efried: Thank you! IIRC, it is "encouraged" to update the spec file as "new information arises" (I know jaypipes likes to use Labowski's phrase here :D)? | |
| 14:34:10 | aspiers | efried: yeah I was thinking of something like the way launchpad shows a dep graph for blueprints | |
| 14:34:16 | efried | kashyap: Yes, definitely. Common practice to propose spec amendments e.g. once the impl lands to make it reflect reality. | |
| 14:34:36 | kashyap | Alright, I've seen a few amendments in the specs repo. | |
| 14:34:53 | mriedem | gibi: i see you have https://blueprints.launchpad.net/nova/+spec/support-server-move-operations-with-ports-having-resource-request which your move spec is tracked against, and you also have https://blueprints.launchpad.net/nova/+spec/enhance-support-for-ports-having-resource-request | |
| 14:34:53 | aspiers | efried: speaking of which, I noticed one of the SEV work items might need changing but I'm not sure | |
| 14:34:54 | efried | kashyap: I can do that (respond to edleafe in the review) or you could just point to the eavesdrop of the conversation we had above. | |
| 14:35:00 | mriedem | gibi: does the former supersede the latter? | |
| 14:35:14 | kashyap | efried: Okay, I'll do the latter; it'll save you time. | |
| 14:35:21 | efried | kashyap: thanks | |
| 14:35:29 | mriedem | gibi: or is the latter the reason for ptg discussion? | |
| 14:35:35 | gibi | mriedem: https://blueprints.launchpad.net/nova/+spec/enhance-support-for-ports-having-resource-request is a collection of further enhancements for bandwidth | |
| 14:35:41 | aspiers | efried: work item #7 http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html | |
| 14:35:43 | efried | mriedem: As I understand it, enhance-support is an overarching longer-term bp that excludes support-server-move | |
| 14:35:54 | mriedem | ok | |
| 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? | |