Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-25
19:17:24 mriedem yes
19:17:31 mriedem which i think i said in the spec review when this came up,
19:17:46 mriedem just stop the instance, shelve it, swap the root volume, and unshelve,
19:17:47 sean-k-mooney ok so you jsut need to shelve it and then unshelve after changing volumes and you can more or less achive the same use case
19:17:52 mriedem but people thought that was too complicated
19:18:11 sean-k-mooney perhaps but ill take complicated over broken any day
19:22:29 mriedem sean-k-mooney: i guess i did think about this https://review.openstack.org/#/c/600628/7/specs/stein/approved/detach-boot-volume.rst@127
19:25:27 sean-k-mooney mriedem ya looks like you did but it never made it into the spec in the end.
19:26:12 sean-k-mooney mriedem: atleast a concreate proposal for what to do in this case was not added to the spec. your comment are obviously there
19:28:30 openstackgerrit sean mooney proposed openstack/os-vif master: modify functional base.py to allow using vscode https://review.openstack.org/638058
19:30:22 mriedem yeah i just don't want to get into a case where someone swaps the root volume on a stopped instance, then they rebuild it with what they thought was the original volume and rebuild blows up saying you can't rebuild a volume-backed instance with a new image, or they pass the image_id of the new root volume and the scheduler kicks it out saying it's not valid for the current host
19:30:40 mriedem s/original volume/original image/
20:04:11 openstackgerrit Merged openstack/nova master: quota: remove QuotaEngine.register_resources() https://review.openstack.org/615613
20:51:04 openstackgerrit Artom Lifshitz proposed openstack/nova master: New objects to transmit NUMA config from dest to source https://review.openstack.org/634827
20:51:04 openstackgerrit Artom Lifshitz proposed openstack/nova master: Introduce live_migration_claim() https://review.openstack.org/635669
20:51:05 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.openstack.org/635229
20:51:05 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for sending NUMAMigrateData to the source https://review.openstack.org/634828
20:51:06 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP needs more tests] Full NUMA live migration support https://review.openstack.org/634606
20:51:06 openstackgerrit Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.openstack.org/634605
20:51:26 artom So that was "sync" push - let's run this in my test env to see what I've broken
20:57:22 dansmith dang
20:57:28 dansmith I was just working my way through them
20:57:41 dansmith now I have to start all over aain
20:57:45 dansmith guess I'll wait for next monay
20:57:52 dansmith also, wtf is up with my keys
20:58:56 sean-k-mooney dansmith: are you on vacation until monday? or just monday is the next time you will be able to review it
20:59:11 sean-k-mooney dansmith: just wondering if you will be around later in the week is all
20:59:54 artom dansmith, I'm sorry, are you asking for "monay"? I thought RH payed you well ;)
21:01:09 dansmith artom: monay monay
21:01:23 artom It's a Smith-man world!
21:01:32 dansmith sean-k-mooney: I'm giving artom a hard time implying that I only review large, late patch series on monday mornings
21:02:20 sean-k-mooney hehe in that case feel free to add my/adrianc's sriov patch set to that list :P
21:02:41 sean-k-mooney but on a serios note artom i deployed v21 on friday
21:02:46 sean-k-mooney *serious
21:03:04 artom v21?
21:03:06 sean-k-mooney am ill redeploy tomorow ish do you think it will change much
21:05:08 sean-k-mooney this was the top patch in the series on friday https://review.openstack.org/#/c/635229/21
21:05:10 artom sean-k-mooney, dunno, lemme run my tests against what I have now, see what breaks
21:05:45 sean-k-mooney it looks like https://review.openstack.org/#/c/634606/30 is not the top patchset in the series
21:06:25 artom sean-k-mooney, that's changed. Claim creating and cleanup needs to happen in the same patch, along with a version bump because we need to check that source and/or dest support claims
21:07:31 sean-k-mooney right but https://review.openstack.org/#/c/634606/30 is now the final patch in the series right
21:07:38 artom So there's 2 service bumps to keep the patches reasonnably sized
21:07:42 artom 1 for the RPC stuff
21:07:54 artom And 1 for the final "we support NUMA LM" switchover
21:08:18 artom sean-k-mooney, correct
21:08:45 artom The overall mechanics haven't really changed, but they way they're presented/ordered and some details have
21:09:01 sean-k-mooney i can put off deploying the it for another few days and just to a code review tomorow and focus on other tasks if that helps. it will take me the better part of a day to run all the test i want too on it so i was going to wait till it sables a bit more
21:10:24 artom sean-k-mooney, your call, really. Ideally any tests that are missing from https://review.rdoproject.org/r/#/c/18832/ would get added there, so that we don't have to manually redo everything everytime there's a new patchset
21:10:32 sean-k-mooney artom: ok what i want to be able to do is send an email to the list and say i test all these senarios with this reviesion and heres what work and didnt
21:10:56 sean-k-mooney there are quite a lot of tests that arent covered
21:11:06 artom For instance, I realized I wasn't saving the new instance numa topology (fixed now), so I should add that to the tests
21:12:01 artom sean-k-mooney, oh I'm sure there are :) So... if you like it, just add them directly, or just write them out in English and I'll code them up
21:12:12 sean-k-mooney i might spend some time writing automated test but i also want to manually run them and verify it.
21:12:17 mriedem efried: jaypipes: i've gone through the next bw provider change in the series https://review.openstack.org/#/c/622421/ - i might be overly harsh on this one
21:13:04 openstackgerrit Merged openstack/nova master: conf: Deprecated 'defer_iptables_apply' https://review.openstack.org/445436
21:20:05 jaypipes mriedem: I'm still trudging through them... sorry for the slowness. :(
21:21:00 mriedem that's fine
21:21:04 mriedem i'm about reviewed out for the day
21:22:42 sean-k-mooney jaypipes: hi am do you want to pushout the os-vif release to tomrow morning. i can send an update to the list with where things are or should i propose a relase with the current master.
21:23:45 sean-k-mooney jaypipes: i would like to get the new release into the gate by tomorrow at the latest but we should be ok to wait anouter few hours e.g. till US moring to tag
21:27:11 jroll dansmith: on https://review.openstack.org/#/c/635006 , this code path is in a periodic. so if we explode, the nova-compute won't crash, just won't expose any resources. that okay with you?
21:28:41 dansmith jroll: I mean, if it's a case that makes sense to not do anything then sure
21:29:34 jroll dansmith: reworded, do you think operators will see that problem if nova-compute keeps running?
21:29:35 jaypipes sean-k-mooney: yes, that would be good if we can delay one more day.
21:29:55 dansmith jroll: I mean, it's the same deal as if they mis-configured with nothing in that list right?
21:30:07 dansmith jroll: obviously it should be error-logged
21:30:14 jroll dansmith: right, I mean if it's unset
21:30:16 sean-k-mooney jaypipes: sure. i just want to have 1-2 days of gate time before the non-client lib freeze.
21:31:06 jaypipes ack
21:31:13 sean-k-mooney jaypipes: ill propose a patch and -w flow it with the current master and ill updated it tommorow once that feature lands. ill update teh list with all this soon
21:31:22 jaypipes ++
21:33:44 dansmith jroll: if we have no other option than to log errors in each periodic, then, I think that's about all we can do
21:33:45 dansmith that said,
21:34:05 dansmith we have a place for the virt driver to run during host init, and you could sanity check config there and explode to stop nova-compute I think
21:34:43 dansmith jroll: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1202
21:35:06 jroll dansmith: ah, good point, I'll do that instead. thanks.
21:42:17 cfriesen mriedem: sean-k-mooney: For the vTPM stuff, do we need to be fully feature-complete to merge anything? Or could we review the currently proposed code and then do a followup commit to make cold migrations work?
21:43:40 sean-k-mooney well we can review the code but how is the feature enabled. e.g. will the ablilty to request a vTPM only be enable with the colde migrate code or will it be enabled in an early patch
21:44:32 sean-k-mooney cfriesen: also how likely is it that the coldmigrate code will be ready in the next 2 weeks?
21:46:12 sean-k-mooney cfriesen: is this the full series https://review.openstack.org/#/q/topic:bp/add-emulated-virtual-tpm+(status:open+OR+status:merged)
21:49:33 sean-k-mooney cfriesen: i think we still plan to merge the bwandwith based schduleing patch without migration support but in the case of vTPM livemigration will work right since the vTPM data is copied by qemu it will jsut be colde migrate that is missing?
21:49:45 cfriesen sean-k-mooney: paul-emile got moved internally, so I get to do it now. I'm ramping up, but I think there's a small piece missing to enable the functionality via image property and a piece missing for cold migration.
21:50:10 cfriesen sean-k-mooney: with our earlier implementation live migration just worked, I'm hoping that'll still be true.
21:52:06 cfriesen sean-k-mooney: crap, you're right. there's a bit missing to actually enable it.
21:52:21 cfriesen minor detail. :)
21:52:38 melwitt it's true we're planning to merge bw based scheduling without migration support but we're able to reject it via 403 error (I think is the plan that was landed on?) to be enabled later
21:52:52 sean-k-mooney right so i havent looked at this properly since looking at the spec.
21:53:47 sean-k-mooney cfriesen: so your in luck i have a dev env that i was usign to test artoms numa livemigration stuff that a knew enought version of qemu and libvirt
21:54:00 sean-k-mooney cfriesen: i can try and test this tommorw
21:54:29 melwitt would the vTPM stuff be able to do similar? we'd have to get some consensus about what to do, if so
21:54:42 cfriesen sean-k-mooney: okay, I'll try and get you something usable.
21:55:50 sean-k-mooney melwitt: we might be able to
21:56:00 cfriesen melwitt: currently the code automatically advertises vTPM support if qemu/libvirrt is new enough, but we could add a config option to disable that.
21:56:16 sean-k-mooney melwitt: we can certenly put a check in the conductor to reject the migration if we dont have the support
21:56:34 cfriesen yeah, we could do the conductor change too
21:57:01 sean-k-mooney cfriesen: the cold migration support should be fairly stright forward right
21:57:13 sean-k-mooney cfriesen: you just need to coppy the backing file for the vtpm?
21:57:24 melwitt yeah... config option for the support isn't something appealing
21:57:27 cfriesen sean-k-mooney: pretty much, yeah.
21:57:34 melwitt it wouldn't be able to reject before conductor? not in the API?

Earlier   Later