| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-10 | |||
| 14:06:10 | stephenfin | but I do, to be safe | |
| 14:06:42 | stephenfin | the firmware metadata files won't report support for pc-i440fx-* machine types with the secure-boot feature | |
| 14:06:54 | stephenfin | so we'll hit https://review.opendev.org/c/openstack/nova/+/779302/2/nova/virt/libvirt/host.py#1506 | |
| 14:07:07 | stephenfin | see also line 1499 in that | |
| 14:07:34 | stephenfin | one of the reasons I invested so much time in beefing up the FakeLibvirtFixture was to "automate" as much of this as possible | |
| 14:07:35 | kashyap | stephenfin: Indeed, the JSON files report, correctly so, only for pc-q35-* (ugly name; but it's QEMU's "historical decision) | |
| 14:07:45 | stephenfin | correct | |
| 14:08:07 | kashyap | stephenfin: I see. Yeah, I've seen your work fly-by on the test / fixtures stuff. Fine work | |
| 14:08:22 | stephenfin | with that being said https://review.opendev.org/c/openstack/nova/+/776681/7/nova/virt/libvirt/driver.py#5837 | |
| 14:08:37 | stephenfin | That's mostly for test purposes | |
| 14:09:09 | stephenfin | actually, no, I remember - it's so we can decided whether to enable secure boot or not in the 'optional' case | |
| 14:09:40 | stephenfin | if we didn't have that, we'd attempt to enable it and fail | |
| 14:09:40 | kashyap | stephenfin: Ah, I didn't get tot he _check-secure_boot_support() method yet; looks good | |
| 14:12:18 | kashyap | Yeah, we don't want to enable secure Boot by "default" (may people tend to opt out of the UEFI complexity, for good reasons) | |
| 14:14:14 | sean-k-mooney | stephenfin: artom summerised that here https://review.opendev.org/c/openstack/nova/+/772779/17#message-744974dfe27df3782bd2e6c066aa1b241fc7136a | |
| 14:14:28 | sean-k-mooney | ill be afk untill the top of the hour and ill rebase my patches then | |
| 14:14:56 | gibi | stephenfin, sean-k-mooney, artom: fixing the sharp edges in artoms socket policy series as a followup works for me. I can review both that and the port numa policy when they are put in order. The order does not matter to me I have the intention to push both through :) | |
| 14:16:28 | sean-k-mooney | :) | |
| 14:16:48 | gibi | and we have more than a day! :D | |
| 14:22:50 | bauzas | I'm switching away a bit from stephenfin's uefi secure boot series while 50% of the changes are now approved | |
| 14:22:57 | bauzas | who wants reviews here? | |
| 14:23:08 | bauzas | sean-k-mooney: vDPA series or the policy one ? | |
| 14:23:28 | bauzas | gibi: nothing crucial for your eyes ? | |
| 14:23:35 | stephenfin | gibi: plus a week for them to actually get through the gate /o\ | |
| 14:23:40 | stephenfin | sigh | |
| 14:23:49 | stephenfin | it really hates my db migration series | |
| 14:23:57 | bauzas | stephenfin: well, no worries if they are accepted before FF | |
| 14:24:07 | bauzas | if they are in the gate, we can recheck if needed | |
| 14:24:18 | artom | stephenfin, sean-k-mooney, so one thing that hadn't occurred to me what we could do is still store something in self (let's say self.numa_topology for now), but access it from consume_requests() and supports_requests(), which are already at the object level, and pass it to the _filter() methods, and we can keep them classmethods in that way | |
| 14:24:19 | bauzas | even if we're past the feature freeze | |
| 14:25:15 | artom | But to be honest, I'm burnt out on the thing. It's good enough as is, I'll remove my -1, merge, and that way folks are free to concentrate on other stuff before FF | |
| 14:25:24 | artom | Instead of endlessly revisiting this | |
| 14:27:31 | stephenfin | ack | |
| 14:27:59 | gibi | stephenfin: I will recheck the db series into W or at least "die" trying :) | |
| 14:27:59 | sean-k-mooney | artom: ya that would have worked. | |
| 14:28:01 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: Change default policy for GET '/os-hypervisors' API https://review.opendev.org/c/openstack/nova/+/765798 | |
| 14:28:17 | sean-k-mooney | i have a ptg topic on reworking the pci handeling and fixing bugs | |
| 14:28:28 | artom | sean-k-mooney, you have *all* the PTG topics ;) | |
| 14:28:30 | sean-k-mooney | artom: lets think about it as part of that next cycle | |
| 14:28:34 | stephenfin | gibi: gmann: That's my approach to the 'os-hypervisors as project admin' change ^ | |
| 14:28:49 | sean-k-mooney | artom: ya i know i feel bad for adding them but we might just skip some | |
| 14:28:49 | stephenfin | gibi: gmann: tbh, for what it gives us I'm thinking it's less and less a good idea | |
| 14:29:12 | sean-k-mooney | artom: more a list of what i knwo we shoudl addrss right now then what we plann on adressing next cycle | |
| 14:29:38 | stephenfin | bauzas: ta for the reviews, btw :) | |
| 14:29:45 | gibi | artom: as I said follow up work for me for the refactor. Do we know that socket - numa cardinality issue on the gate is just gate test node specific and fixebale later? | |
| 14:29:56 | bauzas | stephenfin: sorry for stopping but I want to zap here | |
| 14:30:01 | sean-k-mooney | artom: i plan to stick through or otherwise note which one wont be worked on in xena after we discuss downstream what we have capsity to work on | |
| 14:30:13 | bauzas | so, which one to pick ? | |
| 14:30:14 | artom | gibi, the thing stephenfin pointed out? It's normal, our nodepool VMs are set up that way | |
| 14:30:16 | stephenfin | bauzas: all good. chances are something will fail in the gate so no point bulk approving them | |
| 14:30:29 | artom | gibi, the new code correctly noped out when it saw there were multiple sockets per NUMA node | |
| 14:30:45 | bauzas | stephenfin: that's the usual game | |
| 14:31:14 | gibi | artom: does it also mean that we cannot test this now on the gate in tempest? | |
| 14:31:17 | sean-k-mooney | gibi: it can happen on really old hardware with a frontside bus. its unlkely to happen on any moderne (made in the last 12 years) hardware | |
| 14:31:17 | bauzas | gibi: again, nothing to point out specifically ? | |
| 14:31:32 | bauzas | if not, I'll choose sean-k-mooney's vDPA stuff as it's HPC | |
| 14:31:32 | artom | gibi, I mean we never could we don't have PCI devices :) | |
| 14:31:33 | gibi | sean-k-mooney: thanks, so it is just gate env issue, cool | |
| 14:31:38 | sean-k-mooney | gibi: multipl socket per numa ndoe imples the memory contoler was on the motherboard not the cpu | |
| 14:31:41 | gibi | artom: correct, sorry :) | |
| 14:31:54 | sean-k-mooney | intell moved it to the cpu 12 years ago with nehelem | |
| 14:32:05 | gibi | OK, then I'm fine with the socket policy series as is | |
| 14:32:07 | bauzas | that reminds me, any barebone server you could recommend me for running an openstack env ? | |
| 14:32:20 | artom | gibi, cool, thanks! | |
| 14:32:23 | gibi | let's merge it and do whathever refactor you agree on as a followup | |
| 14:32:59 | sean-k-mooney | bauzas: i got one from ebay for 1600 or so but i allo have older ones for about 500 | |
| 14:33:01 | gibi | it also means that Sean's port policy patch should go on top | |
| 14:33:17 | sean-k-mooney | bauzas: thre are lots you can get second hand depending on your budget | |
| 14:33:20 | bauzas | sean-k-mooney: woah that's expensive | |
| 14:33:28 | sean-k-mooney | bauzas: if you dont have an atic get a tower server | |
| 14:33:30 | gmann | stephenfin: on shelve block: by this you mean you will return this in new code based on config right ? "the current block we have uses https://github.com/openstack/nova/blob/ab07507e5cfce6232fef373d07ff92ea704541da/nova/exception.py#L158-L159" | |
| 14:33:34 | gmann | sean-k-mooney: ^^ | |
| 14:33:38 | gmann | not stephenfin | |
| 14:33:54 | bauzas | sean-k-mooney: I have a cave, but it's already fully packed so a barebone would get my preference | |
| 14:34:10 | gmann | stephenfin: ack, sorry i missed that part of filtering. I will check that | |
| 14:34:24 | bauzas | a tower is nice but too huge for the place I'd put it in there | |
| 14:34:41 | sean-k-mooney | bauzas: i have to run but we can talk about it later if you want you can get ceaper system if you hapy to go older in 200-500 price point | |
| 14:34:57 | bauzas | sean-k-mooney: I'd appreciate it | |
| 14:35:06 | bauzas | I honestly don't need a lot of power | |
| 14:35:13 | bauzas | I just want rapid disks and RAM | |
| 14:35:20 | bauzas | for spinning VMs | |
| 14:35:39 | sean-k-mooney | gmann am it would return that for vms with cyborg prots and a similer new excpetion for vms with sriov port | |
| 14:35:45 | bauzas | I was both frustrated and ashamed by gibi testing my own series :p | |
| 14:35:50 | sean-k-mooney | gmann: the new one woudl also just inherit form forbidden | |
| 14:35:58 | stephenfin | gmann: Ack. Like I said, I don't really like it myself. Relying on this obscure aggregate metadata property that was previously only used for a specific filter and optional pre-filter feels wrong | |
| 14:35:59 | sean-k-mooney | gmann: so no change in error code | |
| 14:36:22 | gibi | bauzas: no worries. I'm lucky as I have access to a lab with decent hardware (even with SRIOV capable NICs) | |
| 14:36:39 | bauzas | gibi: that's what I honestly'd like to have | |
| 14:36:44 | stephenfin | gmann: If it were me, I'd probably just drop the idea and remove that idea from the spec but perhaps there are people who really want this? :-D | |
| 14:36:57 | sean-k-mooney | but ya basically return that for shelve based vnic_type in (direct,direct-pyshical ...) all the sriov or cyborg vnic types | |
| 14:37:01 | gmann | sean-k-mooney: +1, as long as it inherit from forbidden error, wsgi layer will handle it as 403 otherwise you need to handle it explicitly in API controller. | |
| 14:37:28 | sean-k-mooney | ok ill add you to the patch to review if that is ok when i get time to write it | |
| 14:37:43 | gmann | sean-k-mooney: and yes 403 return for error cases does not need microversion as it is already generic return code as you mentioned. | |
| 14:37:52 | yonglihe | gibi： hope you have some bandwidth . I can fix comments at you guys night. wish me lucky. -:) | |
| 14:38:11 | gibi | yonglihe: I plan to get to the smartnic series before I leave for today | |
| 14:38:15 | gibi | yonglihe: have a nice night | |
| 14:38:22 | gmann | stephenfin: but if we drop we again go back to the problem of using PROJECT_AMDIN for POST /server API on specific host | |
| 14:38:58 | stephenfin | gmann: That's a fair point | |
| 14:39:00 | yonglihe | gibi: thanks have a good day. | |
| 14:39:14 | stephenfin | gmann: In that case, we can persist with it. I wasn't sure of the use case but that sounds like a good one. | |