| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-04 | |||
| 13:20:06 | sean-k-mooney | yonglihe: that will driver dependent but i think it makes sense to have a call to the driver to retrun the set of possible ophean instances and then for the compute manager to ask the driver to reap them. | |
| 13:20:12 | sean-k-mooney | sure ill add it to the review | |
| 13:22:45 | mriedem | lyarwood: bauzas: dansmith: can we get these stein backports in so i can do a release? https://review.opendev.org/#/q/topic:bug/1830747+status:open+branch:stable/stein | |
| 13:23:10 | bauzas | mriedem: ack I can take a look | |
| 13:23:18 | yonglihe | sean-k-mooney: driver specific is spitted out, there is 2 patches on set. find the orphan seems like logic belong to compute but checking the metadata is definitely driver's scope. | |
| 13:25:50 | sean-k-mooney | yonglihe: well i woudl expect the driver to be the thing that check what intances are running on the host and provide a kwarg to allow filtering to just vms it created. | |
| 13:26:29 | sean-k-mooney | but i wouuld expect the compute manager to be the thinkg that calls that and descided if it should reap or not based on the policy set in the config | |
| 13:27:04 | sean-k-mooney | well i guess its a periodic task but the point is i would expect the fucntion exectued by the periodic task to be driver independent | |
| 13:27:24 | dansmith | mriedem: yes | |
| 13:29:28 | lyarwood | thanks dansmith | |
| 13:32:53 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Noop CantStartEngineError in targets_cell if API DB not configured https://review.opendev.org/663030 | |
| 13:34:45 | yonglihe | sean-k-mooney: anyway there is a new API need added to driver layer. and i agree it should decouple with driver in some way. now it's not the way you prefer. but it's driver's choice to implement or not. | |
| 13:41:29 | yaawang | johnthetubaguy: Hi, I've replied your suggestion, is it correct? https://review.opendev.org/#/c/651681 | |
| 13:45:52 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-next archive using --before https://review.opendev.org/661002 | |
| 13:47:16 | openstackgerrit | Merged openstack/nova-specs master: Amend count-quota-usage-from-placement to reflect implementation https://review.opendev.org/662130 | |
| 13:47:22 | johnthetubaguy | yaawang: opps, your question points out I explained my idea badly, I will reply in the review soon | |
| 14:03:46 | yaawang | johnthetubaguy: Thanks, I'll look it tomorrow because my timezone is UCT+8 :) | |
| 14:04:12 | johnthetubaguy | yaawang: no problem, have a good evening/night! | |
| 14:07:00 | sean-k-mooney | gibi: mriedem forgot to push my comments but the reason the vgpu spec only provides soft affitnity curenly is that dansmith ask to reduce the scope to that case so yes part of it need to be updated but in v1 and v2 it proposed multiple affintiy polices | |
| 14:07:30 | sean-k-mooney | gibi: mriedem which is why the oringal use case refer to enforcing numa affinity | |
| 14:12:08 | mriedem | sean-k-mooney: ok -1 to clean that up then to avoid confusion | |
| 14:47:22 | openstackgerrit | Merged openstack/nova stable/stein: Add regression recreate test for bug 1830747 https://review.opendev.org/662574 | |
| 14:47:27 | openstack | bug 1830747 in OpenStack Compute (nova) stein "Error 500 trying to migrate an instance after wrong request_spec" [High,In progress] https://launchpad.net/bugs/1830747 - Assigned to Matt Riedemann (mriedem) | |
| 14:52:49 | openstackgerrit | Merged openstack/python-novaclient master: Bump openstackdocstheme to 1.30.0 https://review.opendev.org/662905 | |
| 16:09:30 | yaawang | johnthetubaguy: Thanks for your commet. | |
| 16:10:15 | efried | kashyap: you and yaawang have been talking about cpu model list. Would you be okay if we restored the spec and let yaawang take over convincing the world it has legs? | |
| 16:10:22 | yaawang | mriedem_away: Could you take a look at this spec, please. https://review.opendev.org/#/c/651681 | |
| 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 | |