Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-10
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.
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

Earlier   Later