| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-10 | |||
| 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. | |
| 14:49:00 | gmann | stephenfin: 1 comment, for case where there is no 'filter_tenant_id' in host's aggregate then that host we can return for project admin | |
| 14:49:48 | stephenfin | oh, that makes things more useful | |
| 14:50:06 | stephenfin | isn't that a lot of information to expose though? | |
| 14:51:11 | stephenfin | Maybe not. They'll just see the summary view so ID, hostname, state, and status | |
| 14:51:14 | gibi | that would basically mean that all project admin in a non tenant separated cloud see every compute | |
| 14:51:38 | gmann | yeah | |
| 14:51:43 | gibi | do we allow project admins to boot on all the computes in that case directly? | |
| 14:52:30 | gibi | I mean what exactly this means? | |
| 14:52:30 | gibi | 15:38 < gmann> stephenfin: but if we drop we again go back to the problem of using | |
| 14:52:30 | gmann | all you mean all or only host's computes with no 'filter_tenant_id' | |
| 14:52:33 | gibi | PROJECT_AMDIN for POST /server API on specific host | |
| 14:53:10 | gibi | does the above mean that we want to allow project admins to boot on specific compute host? | |
| 14:53:22 | stephenfin | I'm looking and we already do | |
| 14:53:24 | gmann | if it pass the filter_tenant_id filter (host match with filter_tenant_id or there is host with no filter_tenant_id) then that compute canbe allowed and rest 403 | |
| 14:53:51 | gibi | hm, that feels powerful | |
| 14:54:00 | stephenfin | but gmann's comment there says we should change that to system admin | |
| 14:54:03 | gibi | especially in a non tenant separated cloud | |
| 14:54:48 | gmann | stephenfin: no, i mean system reader get everything, and project admin only go with those filter_tenant_id filters | |
| 14:55:21 | stephenfin | isn't that what I've done? | |
| 14:55:22 | gmann | may be we have to check if context is scoped to system or project | |
| 14:55:50 | gmann | this one? https://review.opendev.org/c/openstack/nova/+/765798/5..6/nova/api/openstack/compute/hypervisors.py#197 | |
| 14:56:01 | gmann | and you will keep default policy as SYSTEM_READER? | |
| 14:57:02 | stephenfin | oh, are you talking about the context I use in my call to 'objects.Aggregate.get_by_metadata'? | |
| 14:58:02 | stephenfin | I'm changing the 'os_compute_api:os-hypervisors:list' policy to project admin or system reader | |
| 14:58:32 | stephenfin | but you'll note that check doesn't pass a context argument | |
| 14:58:45 | stephenfin | so it will never pass for a project admin, right? | |
| 14:59:03 | stephenfin | while it will pass for a system admin or system reader | |