| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-25 | |||
| 14:19:56 | kashyap | aspiers: I saw your reorg comment, still have to look at it. (I'm still a bit unwell, so, slow today as well) | |
| 14:20:09 | aspiers | kashyap: sorry to hear that :-( no pressure | |
| 14:20:10 | efried | when we first split os-traits out of placement (in nova) there was a proposal (from jaypipes iirc) to do it with a more complex architecture that would allow for deprecation and removal. | |
| 14:20:21 | efried | but we decided on the super-simple approach instead. | |
| 14:20:40 | sean-k-mooney | efried: not quite but maybe have _NO_IMG_ or something | |
| 14:20:43 | efried | aspiers: No plans in the forseeable future. | |
| 14:20:47 | aspiers | efried: just wondering if https://review.opendev.org/#/c/655673/ should have explained that too | |
| 14:21:00 | sean-k-mooney | that or add them to a seperate dict in os-traits | |
| 14:21:05 | efried | sean-k-mooney: Yeah, no. We don't want to try to predict what those would be, and that's not the responsibility of os-traits IMHO. | |
| 14:21:07 | sean-k-mooney | or list | |
| 14:21:16 | kashyap | aspiers: Ah, nice. It's actually merged; efried++ | |
| 14:21:43 | efried | aspiers: Sure, could do, looks like mriedem felt the same. It's docs, easy to add more. | |
| 14:22:13 | sean-k-mooney | well we should ask ourselve is this a security issue when adding new traits in general. anway i need to go finsih packing | |
| 14:22:22 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Prevent "qbr" Linux Bridge from replying to ARP messages https://review.opendev.org/655332 | |
| 14:23:00 | kashyap | efried: Thanks; good point -- so nothing is blocking from adding the trait. Good | |
| 14:23:01 | jaypipes | efried: you mean os-resource-classes, not os-traits, but yeah. | |
| 14:23:04 | efried | sean-k-mooney: If we do the whitelist thing, then it forces us to think about it for every trait. But in the context of nova, not os-traits. | |
| 14:23:05 | aspiers | efried: Well, if adding a deprecation mechanism to the code isn't completely ruled out, then probably no change is needed | |
| 14:23:15 | efried | jaypipes: oh, was it os-resource-classes, okay. | |
| 14:23:23 | jaypipes | efried: yeah. my proposal was here: https://github.com/jaypipes/os-resource-classes | |
| 14:23:31 | efried | aspiers: FYI ^ | |
| 14:23:33 | sean-k-mooney | efried: we could do it in nova i guess instead | |
| 14:23:36 | aspiers | efried: In general I don't think it makes sense to document "we have no plan to do $X any time soon", since $X could be any number of things :) | |
| 14:23:39 | kashyap | efried: (The "good point" being your "vuln. occurs when we expose them [traits] via compute") | |
| 14:23:49 | jaypipes | efried: with a version history: https://github.com/jaypipes/os-resource-classes/blob/master/os_resource_classes/__init__.py#L21 | |
| 14:24:03 | sean-k-mooney | just have a list of traits in nova that lists trats that cant be in an image or put it in a config | |
| 14:24:06 | jaypipes | we ended up not going with that and instead simply listing constants in a library. | |
| 14:24:15 | efried | aspiers: Yes, that's true, but I think we're talking more about like in the SEV case: "We misnamed this one when we introduced it - please use $Y instead." | |
| 14:24:33 | sean-k-mooney | then as we add usage in nova we can extend the defualt of the config option | |
| 14:24:53 | aspiers | efried: no I was talking specifically about https://docs.openstack.org/os-traits/latest/contributor/index.html | |
| 14:25:07 | aspiers | efried: but I was also about to ask whether I should submit a follow up to https://review.opendev.org/#/c/655671/ to "rename" the SEV trait (deprecating the original) ? | |
| 14:25:16 | aspiers | efried: or whether I should instead amend that review | |
| 14:25:30 | aspiers | I guess amending makes more sense | |
| 14:25:40 | efried | aspiers: I think kashyap is going to do that as part of his patch, because he's going to be splitting x86 into amd and intel | |
| 14:25:50 | efried | It could be done as separate patches, but meh. | |
| 14:26:41 | aspiers | kashyap: when do you expect your reorg to land? | |
| 14:27:36 | kashyap | aspiers: As soon as I address the feedback :-) We can work it out | |
| 14:27:53 | openstackgerrit | Surya Seetharaman proposed openstack/python-novaclient master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648659 | |
| 14:28:03 | efried | kashyap: CPU with hypervisors spec is merging and bp is approved, striking from PTG agenda, cool? | |
| 14:28:43 | mriedem | btw, with trait names like HW_CPU_X86_POTENTIAL_SECURITY_VULNERABILITY_NO_SSB i look forward to the day when we blast the url limit for GET query params | |
| 14:29:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | |
| 14:29:07 | efried | I was being facetious with that. | |
| 14:29:08 | sean-k-mooney | mriedem: im sure we already to if we try to use everything we currently support | |
| 14:29:23 | efried | mriedem: By then we'll surely have json payload for requests. | |
| 14:29:30 | jaypipes | mriedem: coupled with NET_BW_EGR_KILOBIT_PER_SEC, that would be awesome. | |
| 14:29:51 | jaypipes | used to be even longer than that :) | |
| 14:29:51 | aspiers | kashyap: just trying to work out the order of work, since a lot of these changes depend on each other | |
| 14:29:56 | sean-k-mooney | efried: if we do have a json payload we will also need to use a post not a get | |
| 14:30:04 | efried | you keep saying that :P | |
| 14:30:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | |
| 14:30:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't run tempest/devstack jobs on nova/test.py only changes https://review.opendev.org/655121 | |
| 14:30:12 | sean-k-mooney | i do | |
| 14:30:32 | efried | I'm sure you must be right. I don't really care what http verb it is. | |
| 14:30:35 | aspiers | do we have any mechanism for plotting dependency graphs between commits in Gerrit? | |
| 14:30:47 | efried | aspiers: You mean visually? | |
| 14:30:47 | sean-k-mooney | because i keep seeing peole propose apis with get bodies | |
| 14:31:05 | mriedem | efried: gibi: ^ so that series now does 2 things: 1. the nova change sets a low recursion limit (probably won't help) and 2. the oslo.config change doesn't print, it just counts recursion and raises if we call _get() more than 5 times on the same option | |
| 14:31:26 | efried | mriedem: ack | |
| 14:31:36 | kashyap | aspiers: Will address that as quickly as I can. | |
| 14:31:38 | gibi | mriedem: ack, fingers crossed | |
| 14:31:49 | efried | aspiers: And do you mean dependencies based on line conflicts, or based on commits in series and Depends-On? | |
| 14:32:02 | efried | The former is displayed in gerrit, top right corner, "Conflicts With" | |
| 14:32:02 | openstackgerrit | Merged openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec https://review.opendev.org/645814 | |
| 14:32:14 | efried | ^ kashyap \o/ | |
| 14:32:31 | aspiers | efried: commits in series and Depends-On | |
| 14:32:45 | kashyap | efried: In your "copious free time", want to respond to Ed here on "NO_{trait_name}", since your "Traits muscle" is better trained? -- https://review.opendev.org/#/c/655193/2/os_traits/hw/cpu/amd.py@19 | |
| 14:33:07 | aspiers | efried: well, IMNSHO https://github.com/aspiers/git-deps does a nicer job of the former ;-) | |
| 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? | |