Earlier  
Posted Nick Remark
#openstack-nova - 2019-08-05
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 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

Earlier   Later