| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-07 | |||
| 20:20:27 | mriedem | i noticed the local creation part during a review of something unrelated, | |
| 20:20:36 | mriedem | and because of how local delete has bit us with cells, | |
| 20:20:38 | melwitt | ah, okay | |
| 20:20:48 | mriedem | i immediately thought this was also busted in a similar way | |
| 20:21:32 | melwitt | yeah, the set_target_cell is so hidden that it's hard to tell when we need an extra target cell or not | |
| 20:33:31 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient master: Fix cropping the endpoint url https://review.openstack.org/479818 | |
| 20:53:21 | superdan | mriedem1: ah yeah, so we probably don't need that | |
| 20:53:29 | superdan | mriedem1: hence my asking where/how this came hup | |
| 20:53:32 | superdan | up even | |
| 20:55:09 | mriedem1 | sorry | |
| 20:55:26 | mriedem | the local create thing scared me because of local delete issues | |
| 20:55:37 | superdan | hah | |
| 20:55:47 | mriedem | leakypipes: i went through https://review.openstack.org/#/c/476632/ - we can't actually allocate in the scheduler until we've done the changes in the compute to not claim if the allocations are already done, right? | |
| 20:56:02 | mriedem | otheriwse we allocate in scheduler and still claim in compute | |
| 20:56:05 | superdan | mriedem: we already have that right? | |
| 20:56:11 | mriedem | do we? | |
| 20:56:24 | superdan | mriedem: compute just checks the allocations in placement, changing them only if need be | |
| 20:56:35 | mriedem | but i thought the big win was not doing the claim at all | |
| 20:56:38 | mriedem | in the resourc etracker | |
| 20:56:52 | superdan | we can't drop the RT until this is in place | |
| 20:56:56 | mriedem | plus, | |
| 20:57:04 | mriedem | there should be a minimum compute version check somewhere i thought, | |
| 20:57:17 | mriedem | we had the whole back and forth about sending the actual allocations down to the compute over rpc | |
| 20:57:18 | superdan | mriedem: I dunno, ocata computes did the allocation stuff right? | |
| 20:57:21 | mriedem | to tell the compute if it should claim | |
| 20:57:43 | superdan | that's to tell it if it should forego the normal RT claiming right? | |
| 20:57:44 | mriedem | and i thought we settled on not sending hte allocations claimed over rpc, but instead just have the compute check to see if the allocations were already done for it | |
| 20:57:48 | mriedem | and by pass the claim (noop) | |
| 20:58:51 | superdan | yeah | |
| 20:59:16 | superdan | here's the short and curly of it: | |
| 20:59:37 | superdan | there is BBQ hurling its way towards me at about 60MPH, so I stop caring about this when it gets here | |
| 21:00:17 | mriedem | at 2pm? | |
| 21:00:30 | superdan | hell yes.. taylor gets half day fridays in the summer | |
| 21:01:33 | mriedem | so https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-claims.html#other-deployer-impact | |
| 21:01:37 | mriedem | and https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/placement-claims.html#work-items | |
| 21:01:44 | mriedem | "Make compute nodes GET /allocations/<instance_id> for verifying if already created, and if so, don’t POST allocations to Placement service." | |
| 21:01:50 | mriedem | that's what i'm thinking of | |
| 21:02:02 | mriedem | we can sort it out on monday when everyone is actually around | |
| 21:02:07 | mriedem | including his bauzasness | |
| 21:02:30 | superdan | https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L859-L877 | |
| 21:02:52 | superdan | L868 stops if they're equal | |
| 21:03:01 | mriedem | yeah i know about that, | |
| 21:03:39 | superdan | bypassing the existing RT still needs to happen | |
| 21:03:44 | mriedem | but we're still doing all of this other claim checking stuff in the compute that seems unnecessary - although there are going to be things the compute side claim will pick up that we don't in the scheduler, like pci/numa and overhead | |
| 21:03:50 | superdan | yep | |
| 21:04:07 | mriedem | i wasn't sure what we were going to do about the nfv resources | |
| 21:04:27 | mriedem | and i thought in boston for overhead we said, well, you adjust the reserved amount configs to buffer your inventory | |
| 21:04:54 | superdan | we said we'd do the simple thing first, expecting the op to reserve enough, | |
| 21:05:02 | superdan | potentially updating reserved automatically after that yeah | |
| 21:06:40 | mriedem | i'll just go back to my corner with https://review.openstack.org/#/c/471899/ where things make sense | |
| 21:30:37 | Apoorva | Our Cinder CI is failing with following error http://paste.openstack.org/show/614811/. Is this a known issue? | |
| 21:44:21 | sgordon | so i am looking at this thread http://lists.openstack.org/pipermail/openstack/2017-July/thread.html#45139 | |
| 21:44:31 | sgordon | "[Openstack] Live Migration and LibVirt CPU Mode" | |
| 21:44:52 | sgordon | and i could swear there was a legit bug around this at some point but am struggling to pin down where it was discussed/fixed | |
| 21:45:46 | sgordon | specifically "Therefore it appears if a VM XML CPU definition contains "cpu mode='host-model'" the cpu model is ignored and the 2 host CPU models are compared." | |
| 21:45:51 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 21:50:48 | sgordon | ring any bells for anyone? | |
| 21:51:58 | superdan | sgordon: I think maybe kashyap was discussing that with someone at some point? | |
| 21:53:02 | sgordon | superdan, yeah - it definitely sounds familiar i just cant remember the outcome | |
| 21:53:18 | superdan | yeah that's about all I know | |
| 21:56:24 | cburgess | superdan sgordon That sounds about right. What is the specific question? | |
| 21:58:47 | cburgess | if so then... working as intended. | |
| 21:58:53 | sgordon | yeah but host model is not really host model | |
| 21:59:02 | sgordon | it's an approximation of the host model | |
| 21:59:09 | cburgess | Right | |
| 21:59:44 | sgordon | if you go downthread i think they are saying they get the same when using custom and specifying westmere | |
| 22:00:00 | cburgess | Let me keep reading... | |
| 22:02:10 | cburgess | I wonder if he has different versions of libvirt/kvm between the hosts. | |
| 22:02:35 | sgordon | possibly | |
| 22:02:43 | cburgess | "I'm beginning to suspect that because the VM has "cpu mode='host-model'" in its xml CPU definition," | |
| 22:02:44 | sgordon | there is not much/any info about what versions of anything are in use | |
| 22:02:48 | cburgess | As I said.. working as intended. | |
| 22:03:00 | sgordon | yeah - in that email they contradict themselves | |
| 22:03:03 | cburgess | If its using host-model.. you are screwed. | |
| 22:03:05 | cburgess | Period.. | |
| 22:03:10 | sgordon | say it's not working with custom, then say it is | |
| 22:03:18 | sgordon | right | |
| 22:03:27 | cburgess | Right.. | |
| 22:03:37 | cburgess | This message... | |
| 22:03:38 | cburgess | http://lists.openstack.org/pipermail/openstack/2017-July/045145.html | |
| 22:03:41 | sgordon | and there is no way to get out of that without rebooting instances | |
| 22:03:43 | cburgess | basically describes thats in the XML | |
| 22:03:54 | cburgess | and based upon that XML.. what he is seeing is whats expected. | |
| 22:04:01 | cburgess | Correct. | |
| 22:04:27 | cburgess | He could disable the CPU checks but... he runs the risk of the VM crashing on live migration because it sees the flags change. | |
| 22:05:21 | cburgess | I know he doesn't want to reboot but once you are using host-model there is absolutely no safe/guaranteed way to got from new to old. | |
| 22:05:45 | sgordon | right | |
| 22:06:24 | cburgess | So I feel for them.. but there is no solution. They could comment the checks out of nova if they wanted to but even that is a just rolling the device on the VMs crashing on migration. | |
| 22:06:30 | cburgess | Or libvirt just refusing to do it. | |
| 22:07:28 | sgordon | i dont think that helps them anyway | |
| 22:07:36 | sgordon | because it's passed the nova checks | |
| 22:07:41 | sgordon | it's the libvirt checks kicking it out | |
| 22:07:50 | cburgess | Oh yeah.. well.. like I said... | |
| 22:08:16 | sgordon | thanks for being a sounding board, clearly i have friday afternoon brain | |
| 22:08:21 | sgordon | i will try and frame this in an email | |
| 22:10:13 | cburgess | sgordon No worries, we dealt with this very issue a lot in the essex/folsom days. Trying to figure out exacly what CPU type and model info to use to guarnatee the best mix of performance and portability. | |
| 22:12:23 | sgordon | cburgess, yeah - it's basically impossible to set defaults this because any given selection is a tradeoff | |
| 22:12:34 | sgordon | cburgess, depends on the characteristics and requirements of each environment | |
| 22:12:45 | cburgess | sgordon I think the key bit to explains is that all the config values are basically useless once you get down to the libvirt internal code. It will *always* use whats defined in the running VMs XML. | |
| 22:12:58 | sgordon | (i mean obviously we *do* set defaults for this, it's just that they arent going to fit for everyone) | |