| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 16:10:24 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Use SATA bus for cdrom devices when using q35 machine type https://review.opendev.org/663011 | |
| 16:10:24 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Run tempest-full-py3 with q35 machine type https://review.opendev.org/662887 | |
| 16:10:27 | lyarwood | mdbooth / kashyap / artom ; ^ finally got through all of the tests, it's pretty horrific so if someone has a better way I'm all ears :) | |
| 16:11:48 | mdbooth | lyarwood: Looking now. | |
| 16:12:05 | mdbooth | Ouch, test_driver.py! | |
| 16:13:38 | artom | lyarwood, we'd want to backport this, right? | |
| 16:13:58 | lyarwood | yup | |
| 16:14:00 | artom | The thing is, it's hard to know if another approach would have less collateral damage without actually trying it | |
| 16:14:22 | artom | Because backporting this in its current form will be a pain, I suspect | |
| 16:14:35 | mdbooth | artom: I don't think we need to backport further than Stein though, right? | |
| 16:14:51 | artom | mdbooth, true | |
| 16:14:52 | lyarwood | it's actually clean at the moment | |
| 16:14:56 | lyarwood | to stable/stein | |
| 16:14:58 | artom | Whoa... | |
| 16:15:03 | lyarwood | somehow | |
| 16:15:11 | mdbooth | Quick, land it! | |
| 16:15:14 | lyarwood | haha | |
| 16:18:23 | artom | My brain's kinda foggy, but yeah, if it backports clean, I suppose it's OK | |
| 16:18:31 | artom | Don't really see a way around it | |
| 16:18:53 | lyarwood | kk, I'll sort out the missing tests now | |
| 16:21:15 | mriedem | yaawang: you said you had to go to bed :) | |
| 16:22:01 | mriedem | efried: sean-k-mooney: dansmith: gibi: more replies in the nova/cinder spec https://review.opendev.org/#/c/603955/ with my top two concerns listed when i left my latest comment (the latter is an implementation detail so not a huge deal), | |
| 16:22:23 | yaawang | mriedem: haha :) | |
| 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 | mriedem | but if this has already been debated for 2 years i don't want to wade into that pool | |
| 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: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 | mriedem | yeah i know | |
| 16:28:17 | sean-k-mooney | but ya technically | |
| 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 | dansmith | I really haven't read the spec in a while so I should probably keep my mouth shut, | |
| 16:34:08 | mriedem | it's not really what i'm talking about though | |
| 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: WIP: add scope check, see tests catch the change https://review.opendev.org/657823 | |