Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-06-04
16:22:29 sean-k-mooney mriedem: *nova/cyborg
16:22:37 mriedem but in general how much debate has already happened about the API change to *always* have nova manage ARQ creation/lifecycle management vs just having the API accept a pre-created ARQ id like SR-IOV ports?
16:22:43 mriedem sean-k-mooney: heh yeah
16:23:32 mriedem my ideal would be to have version 1 only accept pre-created ARQ ids and attach them rather than version 1 be nova as sole orchestrator
16:23:46 sean-k-mooney mriedem: i dont know how much that has been debated in the current iteration. at present the spec has nova always create the ARQ
16:23:46 mriedem but if this has already been debated for 2 years i don't want to wade into that pool
16:23:57 sean-k-mooney because the request it via the flavor
16:24:13 sean-k-mooney but treating it like a netorn port also makes sense to me
16:24:30 mriedem the user wouldn't have to request it via the flavor if they just passed an ARQ id right?
16:24:37 sean-k-mooney eventrually i think we will want somethign like "openstack server create --device ..."
16:24:43 kashyap efried: Hi, I'm okay restoring. But maybe at this point, a small PoC would already be better, if yaawang wants to tackle.
16:24:46 dansmith mriedem: pretty sure every discussion we've had I've argued for the "make them be pre-created first"
16:25:06 efried kashyap: Okay, let's do that. <== yaawang
16:25:18 mriedem dansmith: yeah...because over the years we've pushed back on nova orchestrating external resources, but this starts out with the total opposite end
16:25:21 kashyap lyarwood: That diffstat...
16:25:28 dansmith mriedem: I haven't really tracked the spec of late, but we had a three phase approach at the previous denver ptg, to not have nova do the creation in the first pass
16:25:45 dansmith mriedem: yeah, well, that definitely sounds like not what I had suggested
16:25:56 sean-k-mooney mriedem: well that is because in the second denver ptg we layed out a 3 phase aproch
16:26:05 sean-k-mooney first staticaly request via flavor
16:26:09 mriedem the thing that really concerns me is there is talk about hot plug support in the future where the compute API would grow support for passing the device profile directly which i'm against,
16:26:18 mriedem rather than just pre-create the ARQ and hand it to nova to attach
16:26:29 sean-k-mooney seacond extend nova api to support precreated ports third i forget
16:26:43 mriedem sean-k-mooney: so the opposite of what dansmith just said :)
16:26:45 sean-k-mooney or third was suppoort hot attach/detach
16:26:50 kashyap efried: FWIW, I'd strongly prefer if they write a _clear_ functional test (even if manual) to clearly show the truth.
16:27:09 sean-k-mooney mriedem: yes the opisite fo what dan just sain
16:27:13 kashyap Because ... "to show truth is to automatically persuade."
16:27:16 dansmith sean-k-mooney: well, maybe we're confusing things
16:27:23 dansmith mriedem: ^
16:27:25 mriedem sean-k-mooney: do we know why that changed?
16:27:32 kashyap (s/write/wrote/)
16:27:35 dansmith because the thing sean-k-mooney is describing is what I'm talking about
16:27:40 sean-k-mooney perhaps the reason its this way si to not require modificaiton of the nova api
16:27:50 mriedem sean-k-mooney: that's what Sundar said in the spec as well,
16:27:54 mriedem it's still a compute API change,
16:27:57 mriedem it's just not a schema change
16:28:07 mriedem trojan horsing the device profile through the flavor is still an api change
16:28:13 sean-k-mooney well its actully jsut a flavor extraspec
16:28:17 sean-k-mooney but ya technically
16:28:17 mriedem yeah i know
16:28:27 bauzas folks, fwiw I wasn't able to do spec reviews today, but I'll do it tomorrow
16:28:32 mriedem but there is still a lot of stuff in the api/conductor that needs to change to create the arq
16:28:45 mriedem and wire the request spec up for scheduling
16:29:04 sean-k-mooney mriedem: yes alot of that would be reused in precreated case
16:29:10 sean-k-mooney at least passing it to the schduler
16:29:35 dansmith mriedem: yeah reading your comments, I think what's being described _is_ what we discussed at the previous denver ptg
16:29:53 dansmith which *was* to have nova do the creation, but just based on some static profile listed in the flavor,
16:30:15 dansmith taking the nova api interaction part out
16:30:30 dansmith but that's akin to an attachment for cinder, which I think makes sense here
16:30:41 dansmith or a binding for neutron
16:30:56 mriedem well, you mean nova creating a volume or a port right?
16:31:02 mriedem on behalf of the user
16:31:09 dansmith no
16:31:34 dansmith because the complex configuration bits are wrapped up in the profile, right?
16:31:47 sean-k-mooney kind of
16:32:15 dansmith it's not a direct correlation, but nova currently does its own attaching of ports and volumes to a host once it knows where it's going, even if the complex volume or port was created, configured, etc by the user
16:32:20 dansmith that's the analog I think I'm making here
16:32:30 sean-k-mooney the profile is just a string in the nova flavor extra spec and wehn we ask cyborg for the detail of the profile it gives us back a set of resource requests and traits
16:32:44 dansmith right
16:32:59 sean-k-mooney and later when we bind the arq to a specifc host cyborge say "heres a pci device"
16:33:10 sean-k-mooney and we generagte the correct xml to pass it to the guest
16:33:36 dansmith right, which to me is equivalent to a host binding or cinder attachment
16:34:03 mriedem sure i get that,
16:34:08 mriedem it's not really what i'm talking about though
16:34:08 dansmith I really haven't read the spec in a while so I should probably keep my mouth shut,
16:34:19 mriedem nova has to do the binding either way,
16:34:36 sean-k-mooney yes but the profile is more like a neutron network in that we told you i want an arq of this type "or a port on this network" and nova is creating an new arq instance like it create a neutron port
16:34:42 openstackgerrit Sylvain Bauza proposed openstack/nova master: Pass allocations to virt drivers when resizing https://review.opendev.org/589085
16:34:45 mriedem i was just concerned about nova being responsible for creating the arq resource always rather than passing a pre-created arq id and just using that (which is already linked to a device profile)
16:34:49 sean-k-mooney i then binds that arq the same way it bind the prot
16:35:08 mriedem sean-k-mooney: right that's what i'm getting at,
16:35:35 mriedem and i worry that will get more complicated down the road (like SR-IOV ports) which requires the compute API to grow complexity to handle new types of devices
16:35:56 dansmith I think the benefit of not letting them pass an ARQ in first is that it delays our commitment to the api user until after this kinda actually works
16:35:58 sean-k-mooney mriedem: so in a way yes we are proxing the creation of the arq but we chose to do that to reduce the change in the api.
16:36:00 mriedem whereas for sriov ports we just said, nope, use the neutron api first if you want those
16:36:12 openstackgerrit John Garbutt proposed openstack/nova master: Add functional test for admin_actions https://review.opendev.org/657698
16:36:13 openstackgerrit John Garbutt proposed openstack/nova master: Ensure we pass a target in admin actions https://review.opendev.org/663095
16:36:13 openstackgerrit John Garbutt proposed openstack/nova master: WIP: add scope check, see tests catch the change https://review.opendev.org/657823
16:36:53 sean-k-mooney dansmith: ya i think that was the basis of your original argument for this approch in the ptg session
16:37:06 mriedem sean-k-mooney: dansmith: ok, ack, i'll yield on that, and had said in my review that i'm sure this has been debated and discussed before and i'm just catching up on that, so don't want to block on it
16:37:10 sean-k-mooney e.g. to defer the api change until this actully works
16:37:18 dansmith sean-k-mooney: yep
16:37:39 mriedem based on all that the spec is probably mostly ready to go after Sundar cleans it up a bit
16:38:28 sean-k-mooney long term i think have a --device option on the server create commandline and the appropriate api change makes the most sense and allow the precreation of ports
16:40:43 mdbooth lyarwood: Done.
16:40:58 mriedem ok thanks, linked to this discussion for Sundar and once he cleans up i'll probably +2 the spec
16:49:19 mriedem dansmith: if there is one spec you review on this, the 3rd formal spec review sprint of the train release, it should be *my* spec for pre-filtering disabled computes https://review.opendev.org/#/c/657884/ :)
16:49:39 dansmith orly?
16:50:12 mriedem mostly b/c i have a quandary in there
16:53:44 openstackgerrit Merged openstack/nova stable/stein: Workaround missing RequestSpec.instance_group.uuid https://review.opendev.org/662894
16:54:08 sean-k-mooney mriedem: oh i thought your disabled nodes prefilter spec was already merged
17:11:43 openstackgerrit John Garbutt proposed openstack/nova master: WIP: add scope check, see tests catch the change https://review.opendev.org/657823
17:14:08 dansmith mriedem: I'm super confused about this
17:14:17 dansmith this spec seems to confuse disabledness and down-ness
17:14:20 dansmith I'm commenting
17:17:59 openstackgerrit Stephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize https://review.opendev.org/662522
17:18:00 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Add '_setup_compute_services' helper https://review.opendev.org/663102
17:21:20 spatel Folks, i am getting this error qemu-kvm: -object memory-backend-ram,id=ram-node0,size=12884901888,host-nodes=0,policy=bind: cannot set up guest memory 'ram-node0': Cannot allocate memory
17:21:56 spatel I have 32G memory and hugemem is 25G
17:22:11 spatel i am trying to build VM with 24G and its throwing this error

Earlier   Later