| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 13:32:22 | mriedem | ? | |
| 13:32:41 | mriedem | ah yes https://etherpad.openstack.org/p/pike-final-release-before-em | |
| 13:32:47 | mriedem | https://etherpad.openstack.org/p/nova-stable-pike-em | |
| 13:34:14 | dansmith | mriedem: hmm, that im=None isn't used huh? | |
| 13:34:32 | openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware VMDK detach: get adapter type from instance VM https://review.openstack.org/653738 | |
| 13:36:26 | mriedem | dansmith: been awhile but the logic i think is if we have the api db and get the not found, we should raise b/c that shouldn't happen. if we don't have the api db configured, we assume we're in the cell conductor and we don't need to target the context anyway. | |
| 13:37:14 | mriedem | the latter is the devstack case, the former is like everyone else in real life right now | |
| 13:37:40 | dansmith | mriedem: okay I'm not sure I follow that, but also not sure that's what is here | |
| 13:37:50 | dansmith | not found does not raise | |
| 13:37:56 | gibi | bauzas: I left a question about the GPU weigher in https://review.openstack.org/#/c/650963 | |
| 13:38:17 | mriedem | sorry not the not found, the CantStartEngineError | |
| 13:38:35 | dansmith | mriedem: right, I get that logic, I'm just talking about the line you removed | |
| 13:38:37 | mriedem | if we're in the cell conductor with no api db config, like devstack, reschedules will fail b/c of CantStartEngineError | |
| 13:38:44 | mriedem | that's dead code | |
| 13:38:45 | dansmith | mriedem: the im=None, but I don't know why that was there in the first place | |
| 13:38:57 | mriedem | it's dead, my ide shows it as dead so i removed it most likely | |
| 13:39:24 | dansmith | "my ide made me do it".. jesus, these kids. | |
| 13:40:19 | mriedem | "my text based terminal editor doesn't show me fun stuff like this" jesus these oldies | |
| 13:40:37 | mriedem | <3 | |
| 13:41:08 | dansmith | heh | |
| 13:42:07 | bauzas | gibi: ack, will look | |
| 13:51:27 | gibi | mriedem, dansmith: about the https://review.openstack.org/#/c/652608/4/specs/train/approved/server-move-operations-with-ports-having-resource-request.rst@190 do you have a feeling which one is easier: 1) implement multiple portbinding usage for every server move operation 2) pass around the RequestSpec in the compute RPC API? | |
| 13:52:29 | mriedem | i'm not sure i understand the question | |
| 13:52:49 | mriedem | you need the request spec in methods like unshelve to do the port binding in the networking api methods properly right? | |
| 13:53:27 | mriedem | oh, | |
| 13:53:36 | mriedem | you mean change all move ops to do the port binding stuff that live migration does? | |
| 13:53:39 | gibi | mriedem: cannot set up the portbinding in the conductor for unshelve? | |
| 13:54:04 | mriedem | i'd think you'd still have behavioral changes in the compute if you did that | |
| 13:54:06 | gibi | mriedem: yeah, do multiple portbinding in the conducotr for every move operation then the binding is created in the conductor | |
| 13:54:25 | mriedem | it's really hard for me to say without it being poc'ed first | |
| 13:54:36 | gibi | mriedem: true, we anyhow need a behavior change in the compute either due to the requestspec or due to the multiple portbinding | |
| 13:54:40 | mriedem | for live migration we create the port bindings in the conductor but there were changes in the compute to use those port bindings if they existed | |
| 13:54:54 | gibi | mriedem: yes | |
| 13:55:02 | mriedem | changing the compute rpc api interface is much more straightforward to me | |
| 13:55:38 | gibi | mriedem: OK that is the kind of input I'm looking for as for me both is blackbox now | |
| 13:55:44 | gibi | mriedem: thanks | |
| 13:56:17 | mriedem | if you haven't heard, there is some weird issue sean-k-mooney is working on with the port binding live migratoin stuff too, so until the root cause of that is figured out i'd be nervous about switching everything over | |
| 13:56:50 | gibi | mriedem: yeah I saw that weirdness too | |
| 13:58:51 | efried | Nova meeting real soon in #openstack-meeting | |
| 13:59:53 | kashyap | (Sigh, conflicting call) | |
| 14:00:01 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | |
| 14:00:59 | sean-k-mooney | i still have the other gate jobs disabled in ^ but if its clean ill uncomment them and drop the [WIP] | |
| 14:01:41 | sean-k-mooney | ... i have that emacs adds tabs... | |
| 14:03:16 | efried | just reprogram it | |
| 14:03:21 | efried | how's yer lisp? | |
| 14:04:16 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | |
| 14:10:24 | mdbooth | efried: Sorry, I did not in the end. I had good intentions :/ | |
| 14:10:54 | efried | mdbooth: Okay. Should I keep you associated with it on my radar or no? | |
| 14:11:18 | mriedem | gibi: replied to the rest of your comments in your spec https://review.openstack.org/#/c/652608/ - question inline about why can't we heal the missing port allocatoins during the _heal_instance_info_cache periodic? | |
| 14:11:48 | gibi | mriedem: ack | |
| 14:11:58 | mdbooth | efried: Given how the next 2-3 weeks looks, it would probably be best not to. | |
| 14:12:22 | efried | mdbooth: okay, thanks. | |
| 14:17:22 | mriedem | sean-k-mooney: can you split the 3rd party NFV / HPC / etc CI testing section out of https://etherpad.openstack.org/p/nova-ptg-train into another etherpad, because it's getting really big in the main one | |
| 14:17:26 | mriedem | ~L99 | |
| 14:18:38 | openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | |
| 14:19:44 | sean-k-mooney | mriedem: yes ill do that and update it with a link | |
| 14:20:31 | mriedem | thanks | |
| 14:32:09 | kashyap | mriedem: I was _just_ about to say that; to split out that giant CI JSON bits away from the main Etherpa | |
| 14:49:02 | kashyap | cfriesen: Heya, mind having a gander at this Secure Boot spec: https://review.openstack.org/#/c/506720 | |
| 14:49:58 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add missing libvirt exception during device detach https://review.openstack.org/651642 | |
| 14:50:36 | kashyap | mriedem: Heh, I was referring to this (Hyper-V) commit of yours & Claudiu: http://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=29dab997 | |
| 14:51:38 | kashyap | The stuff I'm adding in the spec is similar, but for the open source hypervisor | |
| 14:52:09 | mriedem | kashyap: don't confuse me as the author there, that was probably due to a bad rebase which changed the author | |
| 14:52:16 | mriedem | i was likely just helping to clean up nits to get it approved | |
| 14:52:33 | kashyap | Yeah, I know Claudiu was driving it | |
| 14:54:21 | mriedem | cdent: if you have hooks to rado, can you ask if we really need this in pike? https://review.openstack.org/#/c/613263/ | |
| 14:54:40 | cdent | i can probalby find him, yeah | |
| 14:55:34 | sean-k-mooney | mriedem: by the way for NewBruce RDO -> OSA bug. they tested my backported fix last night and it worked at least for the test instnace. | |
| 14:56:01 | mriedem | sean-k-mooney: i need to read your commit message to figure out what the problem was | |
| 14:56:16 | mriedem | or we don't know what the problem was, but this works around it | |
| 14:56:33 | mriedem | i'm also doing about 10 other things atm | |
| 14:56:58 | sean-k-mooney | so we know what the problem is and this works fixes it but i still dont know what teh cause is. im going to try and figure out a reporducer | |
| 14:57:31 | elod | mriedem: only that have stable-policy-follows tag | |
| 14:57:37 | cdent | mriedem: i've pinged him, but based on a cursory examination I think your analysis is correct. If we don't hear anything from him, probably safe to kill/ignore | |
| 14:57:50 | sean-k-mooney | mriedem: no worries i just wanted to say im going to be away for a few days due to pulic holidays but ill try to get back to working on it before the ptg | |
| 14:58:04 | mriedem | cdent: cool thanks | |
| 14:58:19 | elod | mriedem: did i miss something? | |
| 14:58:24 | mriedem | i'm glad you dropped the b rather than l in 'public' | |
| 14:58:41 | mriedem | elod: no i'm just trying to organize the nova pike-em work | |
| 14:58:46 | mriedem | using https://etherpad.openstack.org/p/nova-stable-pike-em | |
| 14:59:04 | sean-k-mooney | :) yes so am i | |
| 15:00:22 | elod | mriedem: ok, is see. actually the pads are quite out-of-date, maybe i should update them | |
| 15:00:43 | gibi | mriedem: replied in https://review.openstack.org/#/c/652608/ but I have to disappear now | |
| 15:00:51 | elod | mriedem: i see that you updated nova's etherpad already | |
| 15:04:44 | mriedem | elod: yeah i'm working on onva's | |
| 15:04:46 | mriedem | *nova's | |
| 15:08:07 | mriedem | cdent: i left some more details about why maybe that patch would still be good for vcenter but i'm not sure - maybe only in the 1:M host:node case but i thought we stopped doing that with vcenter back in like kilo or liberty - long before you had to care about it :) | |
| 15:08:20 | mriedem | tl;dr i think we can drop it | |
| 15:14:02 | cdent | mriedem: in addition to all that, from a vio/vmware standpoint, pike doesn't really matter any more | |
| 15:15:10 | mriedem | heh that was my other guess | |
| 15:25:14 | cfriesen | kashyap: it looks like centos 7.6 has modified the OVMF-20180508-3 rpm to no longer contain the file /usr/share/OVMF/OVMF_CODE.fd that nova looks for in nova/virt/libvirt/driver.py. Instead it now seems to be named /usr/share/OVMF/OVMF_CODE.secboot.fd | |
| 15:25:39 | kashyap | cfriesen: I think it is following just RHEL. | |
| 15:25:48 | kashyap | cfriesen: It's a good step: because it keeps things simpler | |
| 15:25:51 | cfriesen | likely...but either way nova has an issue | |
| 15:26:03 | kashyap | cfriesen: Because we hardcode the file | |
| 15:26:04 | kashyap | I know | |
| 15:26:34 | kashyap | That will go away. We will use the convenient formal interfaces provided by libvirt and QEMU | |
| 15:26:34 | cfriesen | is anyone planning on making it a config option or something? | |
| 15:26:37 | cfriesen | ah | |
| 15:26:44 | kashyap | cfriesen: They've _vastly_ simplified it. | |