Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-07
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
15:17:26 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.50 - List/Show all server migration types https://review.openstack.org/430839
15:17:35 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Microversion 2.50 - Enable cold migration with target host https://review.openstack.org/406707
16:15:15 openstackgerrit John Griffith proposed openstack/nova master: Implement new attach Cinder flow https://review.openstack.org/330285
#openstack-nova - 2017-07-09
23:42:48 openstackgerrit Matt Riedemann proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322
23:52:48 openstackgerrit Matt Riedemann proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322
23:59:22 openstackgerrit Matt Riedemann proposed openstack/nova master: Add ability to signal and perform online volume size change https://review.openstack.org/454322

Earlier   Later