| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-05 | |||
| 17:52:00 | dansmith | efried: certainly not the host cpus, but the mask is letting them choose which vcpus right? | |
| 17:52:00 | efried | dansmith: But it is necessary for the VM to be able to figure out which is which once they are assigned. | |
| 17:52:13 | dansmith | efried: sure, exposing which is which is fine | |
| 17:52:17 | efried | dansmith: Isn't that already supported for numa-isms? | |
| 17:52:21 | fungi | aspiers: could probably use some additional prose, yes. short answer is `echo foo|base64` | |
| 17:52:35 | dansmith | but making them request a complicated mask instead of "two dedicated please" is kinda crazy | |
| 17:52:41 | mriedem | aspiers: the CLI does it for you https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/servers.py#L669 | |
| 17:52:44 | aspiers | fungi: thanks. I find it kind of astonishing that the CLI doesn't just do it for you | |
| 17:52:51 | mriedem | so the doc is talking about the API but confusing when giving a CLI example | |
| 17:52:56 | aspiers | mriedem: hah OK | |
| 17:53:15 | aspiers | that's also astonishing, because it suggests to me that hardly anyone is using this feature? | |
| 17:53:25 | aspiers | or they're just not reading the docs | |
| 17:53:38 | efried | dansmith: I'm not an expert here, nor have I been following the technical details deeply. But I suspect if a mask is being suggested, it's for compat with some other syntax, like the one for NUMA. | |
| 17:53:49 | dansmith | efried: yes, specifying the numa topology is done via complex masking which is pretty gross | |
| 17:54:04 | fungi | aspiers: i can say i've used it for personal systems, but i don't remember which docs i read | |
| 17:54:09 | dansmith | efried: sure, but when that was defined, we didn't have anything else, as we do today | |
| 17:54:39 | aspiers | mriedem, fungi: having said that, I already tried passing unencoded userdata and I get this: | |
| 17:54:42 | aspiers | __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: 'b'network:'...' | |
| 17:54:57 | aspiers | maybe that's a separate issue | |
| 17:55:01 | efried | dansmith: I can't think of a reason why the mask would be a required thing, vs just a count as you say. But again, that's without having a bunch of context, and without rereading all the comment history leading up to whatever we've landed on at this point. | |
| 17:55:17 | efried | It would certainly reduce the test surface | |
| 17:55:21 | dansmith | efried: well, I found a comment from stephenfin which says it was rejected because "it didn't let you choose which ones" | |
| 17:55:26 | efried | though I don't imagine it would make much difference on the code side | |
| 17:55:28 | dansmith | but no explanation of why that's important | |
| 17:55:37 | fungi | aspiers: also i want to say the userdata workflow/model is sort of copied from ec2 so it may have been assumed by the authors that people were familiar with ec2... but yeah docs can always stand to be improved | |
| 17:55:38 | efried | since we would (again, guessing) reuse the code that does it for the numa pinsets. | |
| 17:56:05 | mordred | efried: woot | |
| 17:56:18 | dansmith | I guess if you want your dedicated cpu to be one of the ones with a large amount of memory or something, but we're just getting to the point where you're defining all the legacy hardware attributes fo the system and we lose all flexibility | |
| 17:56:59 | efried | dansmith: I'm pretty sure "just count 'em" is going to be supported as well, just like it is for numa split | |
| 17:57:06 | efried | but if we want to say that's the only thing... | |
| 17:57:14 | efried | I don't see a reason why that would be a problem. | |
| 17:57:21 | efried | Again, as long as the VM can figure out which is which. | |
| 17:57:25 | efried | oh | |
| 17:57:32 | efried | perhaps it's for when we *do* have numa split | |
| 17:57:52 | efried | because then you would have to be able to say which ones are P/V and which of those are from which NUMA node | |
| 17:58:06 | efried | but we could add pinset syntax support at that point?? Not sure. | |
| 17:59:56 | dansmith | that's what I just said above... if you really want your dedicated cpus to specifically be somewhere | |
| 17:59:58 | dansmith | but still | |
| 18:00:17 | dansmith | if you want to arrange your DIMMs in a specific order, maybe you want real hardware | |
| 18:01:00 | dansmith | honestly, I dunno what to say about this one for SFE | |
| 18:01:55 | dansmith | I've seen a couple patches in his code for this, | |
| 18:02:05 | dansmith | and it reports PCPUs to placement as inventory | |
| 18:02:12 | mriedem | traditionally, for both of these specs, if we're past spec freeze and it's not clear on either, and we're 5 weeks from feature freeze, i'd say there is no point in granting an exception for Train | |
| 18:02:21 | dansmith | I assume that if you put resources:PCPU=1 in a flavor, it'll break everything | |
| 18:02:35 | mriedem | if the goal is to just approve the specs to make life easier for re-approvals in U, then i guess....but i don't see either of these making Train | |
| 18:04:53 | openstackgerrit | Adam Spiers proposed openstack/nova master: Don't claim that CLI user data requires manual base64 encoding https://review.opendev.org/674665 | |
| 18:06:50 | openstackgerrit | Adam Spiers proposed openstack/nova master: Don't claim that CLI user data requires manual base64 encoding https://review.opendev.org/674665 | |
| 18:09:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: fix physets typo https://review.opendev.org/674667 | |
| 18:11:28 | aspiers | kashyap: are you still working on https://review.opendev.org/#/c/673790/ ? | |
| 18:11:38 | aspiers | kashyap: because it's definitely broken :) | |
| 18:11:55 | aspiers | if you've already gone I guess I'll try to fix it when I have time | |
| 18:18:27 | aspiers | kashyap: well, reviewed anyway | |
| 18:23:53 | kashyap | aspiers: Yes, it's still broken :-) | |
| 18:24:03 | kashyap | aspiers: Ah, you reviewed, will look :-) | |
| 18:24:14 | aspiers | kashyap: I didn't see any tests in there | |
| 18:24:20 | kashyap | Thanks! And hehe, you were too polite in saying tests were "missing" | |
| 18:24:22 | aspiers | kashyap: did you forget to git add? | |
| 18:24:35 | aspiers | or it's just WIP | |
| 18:24:38 | kashyap | aspiers: I was first getting the parsing right. The tests are only half-done, and I'm ill :-( | |
| 18:24:47 | aspiers | oh sorry to hear that :-((( | |
| 18:25:01 | aspiers | well, I think I've pointed out the parsing issues | |
| 18:25:02 | kashyap | (Before I need to board a flight early tomm. The 4 hours kayaking yesterday) | |
| 18:25:05 | aspiers | or maybe I misunderstood | |
| 18:25:08 | aspiers | ugh | |
| 18:25:16 | kashyap | That's what happens if you're an "indoors enthusiast" and go do sportsy things :D | |
| 18:26:20 | kashyap | aspiers: It's WIP. It will remain dormant until I get back I think. As nobody else has interest in this area, besides you :D | |
| 18:26:51 | aspiers | kashyap: well, when you've finished making changes, push everything you have, mark as WIP, and maybe I can fix it while you're away | |
| 18:27:06 | aspiers | kashyap: include the half-done tests so I don't have to start them from scratch | |
| 18:27:54 | kashyap | aspiers: Yeah, first need to go run an errand, will push it from here or tomm from the aiport... | |
| 18:28:02 | kashyap | Thanks for the help and review, much appreciated! | |
| 18:28:51 | aspiers | sure | |
| 18:29:02 | aspiers | get well soon and have a great vacation! | |
| 19:12:27 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Limit get_sdk_adapter to requested service type https://review.opendev.org/674678 | |
| 19:13:57 | efried | mriedem: ^ and dep ought to get rid of those warnings you mentioned earlier https://logs.opendev.org/57/666857/6/check/nova-live-migration/a379339/logs/screen-n-cpu.txt.gz#_Aug_01_21_21_25_517957 | |
| 19:29:59 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test blank sdk placement proxy https://review.opendev.org/674625 | |
| 19:31:09 | efried | mordred: Slight adjustment gets back to the previous behavior (but is even more hacky) ^ | |
| 19:31:30 | efried | sdk isn't running nova tests, is it? Cause we would have a chicken/egg there. | |
| 19:49:17 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Introduce libvirt/QEMU version constants for Secure Boot https://review.opendev.org/674657 | |
| 19:49:17 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Parse the 'os' element from domainCapabilities https://review.opendev.org/673790 | |
| 20:33:04 | openstackgerrit | Dustin Cowles proposed openstack/nova master: Provider config file schema and loader https://review.opendev.org/673341 | |
| 21:15:02 | mordred | efried: I stepped afk for a minute and had an idea of what I should do WRT the fixture we're talking about ... | |
| 21:15:40 | efried | oh, good, cause my latest attempt worked (passed tests) but failed miserably (bypassed the bit that was supposed to make the warnings go away) :( | |
| 21:15:43 | mordred | efried: so, hopefully i'll have something non-hacky for you to look at tomorrow | |
| 21:15:52 | mordred | efried: HAHAHAHA. | |
| 21:15:59 | efried | laugh it up fuzzball. | |
| 21:16:06 | mordred | I mean, that's not funny - but it's also funny - so, yeah - let's fix it properly | |
| 21:16:26 | mordred | (also, I think it'll remove some boilerplate in the sdk tests - so win/win all around) | |
| 21:16:32 | efried | nice. | |
| 21:16:46 | efried | Okay, I'll quit hacking at https://review.opendev.org/#/c/674625/ for the moment then. | |
| 21:16:50 | efried | thanks mordred | |
| 21:19:00 | mordred | efried: hopefully I'm not completely high :) | |
| 21:19:31 | efried | mordred: Whatever you do will be better than what I was about to have to do in nova. | |
| 21:19:41 | efried | mordred: which was basically mock a proxy object by hand | |
| 21:20:01 | mordred | efried: yeah. let's not do that - there's WAY too much magic under the scenes | |
| 21:20:03 | mordred | :) | |
| 21:20:08 | efried | totally | |
| 21:26:45 | efried | [2] https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/tenant_networks.py#L80 | |
| 21:26:45 | efried | [1] https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/tenant_networks.py#L70 | |
| 21:26:45 | efried | melwitt, mriedem, sean-k-mooney: Any idea why this [1] needs its own RequestContext, instead of reusing the one from the req.environ [2] which is just a couple hops up the call stack? | |
| 21:28:25 | efried | I guess it's because it needs to change the proj/user. Can we use temporary_mutation for that? | |