| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-05 | |||
| 17:22:15 | dansmith | but | |
| 17:22:33 | dansmith | the image handling code on the compute is largely maligned, complicated, and fragile, so... | |
| 17:23:21 | fungi | yeah, i can't say i'm overly surprised... a lot of it has probably been there since aeons | |
| 17:24:50 | fungi | my main goal is to make sure we get expectations set as early as possible for the folks who are working on this, since there may be no point in pushing to get the implementations done in other projects until the u cycle if it's not going to be possible for nova in train | |
| 17:25:47 | fungi | and i wouldn't want the other projects stuck maintaining code for an incomplete feature through an entire release | |
| 17:29:00 | fungi | on a positive note, i think there's been a lot of progress getting this effort on all involved projects' radar in this cycle, which bodes well for earlier agreement on details in the next cycle if it needs to be deferred | |
| 17:33:09 | efried | dansmith: sounded like mriedem was lunching. | |
| 17:33:09 | efried | Meanwhile, how about the other one, mixed PCPU/VCPU in one instance | |
| 17:33:22 | dansmith | efried: yep, saw, figured he can answer later | |
| 17:33:42 | dansmith | efried: just commented on the image one, give me a few | |
| 17:34:22 | efried | Okay. Summary: It seems Stephen, Alex, and Sean have come to an agreement on the design. And it's strictly conditioned on the schedule around the cpu-resources impl. | |
| 17:34:49 | dansmith | efried: ah, looks like mriedem was +0 during the meeting, and had some of the same concerns re: other drivers, so.. | |
| 17:35:03 | dansmith | on the image one I mean | |
| 17:35:09 | efried | y | |
| 17:35:57 | dansmith | efried: I'm confused, I thought the poll on the ML was that shared+dedicated on one host had no major need from ops | |
| 17:36:53 | efried | I don't remember that hitting the ML. I just know this is a big deal for the use case involving CPU priority | |
| 17:37:36 | efried | Stemming from Jay's suggestion that, instead of supporting CPU priorities in any native way, we have the operator designate their "high priority" CPUs to the PCPU pool | |
| 17:37:57 | efried | so in order to have some high and some normal priority CPUs in one instance, we need to be able to support PCPU+VCPU in one instance. | |
| 17:39:06 | efried | (are you thinking of the "NUMA and non-NUMA instances on one host" issue?) | |
| 17:41:18 | openstackgerrit | Eric Fried proposed openstack/nova master: DNM: Test blank sdk placement proxy https://review.opendev.org/674625 | |
| 17:41:41 | dansmith | efried: yeah, just found it | |
| 17:41:45 | efried | mordred: I ran that locally (against just one of the failing tests) and it seems to make it happy enough) ---^ | |
| 17:42:15 | efried | big-ish hammer | |
| 17:49:55 | dansmith | efried: is it really necessary for the user to pick which of their virtual cpus are the dedicated ones? | |
| 17:50:13 | dansmith | like, I thought the point here was that a flavor would request PCPU=2 and VCPU=2 and get two of each? | |
| 17:50:29 | aspiers | is it just me or could the note about base64 encoding in https://docs.openstack.org/nova/latest/user/metadata.html#user-data be a lot more helpful? | |
| 17:51:01 | aspiers | IMHO it's expecting too much of the average user to know how to base64 encode stuff | |
| 17:51:04 | efried | dansmith: It is *not* necessary (and Sean & Stephen made it clear that this was never going to be supported) to be able to say which *host* CPUs you get. | |
| 17:51:24 | aspiers | Or if it's not, that means I'm dumber than the average user, because I'm going to have to look it up | |
| 17:51:41 | efried | dansmith: It's also not necessarily required for you to be able to dictate the set of *virtual* CPU IDs for each. | |
| 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:00 | dansmith | efried: certainly not the host cpus, but the mask is letting them choose which vcpus right? | |
| 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! | |