| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-07 | |||
| 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) | |
| 22:13:17 | cburgess | sgordon Exactly. So we have to play around with a sane "default" for our product and then enable customers to change it for their deployment based upon their needs. | |
| 22:13:53 | cburgess | Though to be fair most use our default since its designed around maximum portability and most of customers can't have downtime for their pets. :( | |
| 22:16:45 | sgordon | yeah the other aspect of course is someone may not notice when doing a greenfield deployment | |
| 22:16:54 | sgordon | the problem comes when they expand later and add a new generation of hosts | |
| 22:18:00 | cburgess | Yup. we didn't notice it until our first client did a server refresh after about a year. | |
| 23:12:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle uuids in os-hypervisors API https://review.openstack.org/471899 | |
| 23:12:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use uuid for id in os-services API https://review.openstack.org/464280 | |
| 23:19:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle uuids in os-hypervisors API https://review.openstack.org/471899 | |
| 23:24:25 | mriedem | mgagne: you overwrote my changes and re-introduced a bug https://review.openstack.org/#/c/454322/29..31 :) | |
| 23:24:31 | mriedem | i'll just push my version again | |
| 23:26:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add ability to signal and perform online volume size change https://review.openstack.org/454322 | |
| 23:35:13 | mriedem | fixed, now i just need to flesh out the tests and docs for the os-instance-actions details changes in there, probably over the weekend | |
| 23:35:27 | mriedem | the tempest/devstack test stack had a clean run last night though, which is awesome | |
| #openstack-nova - 2017-07-08 | |||
| 00:22:19 | openstackgerrit | John Griffith proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285 | |
| 11:34:49 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/477091 | |
| 15:09:37 | openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.49 - Virt device tagged attach https://review.openstack.org/480392 | |