| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-27 | |||
| 15:35:07 | sean-k-mooney | available, claimed for an instnace but not used yet and allocated | |
| 15:35:17 | sean-k-mooney | that is stored in teh db drictly in a table not in memory | |
| 15:35:40 | artom | sean-k-mooney, so can the resource tracker already call down to the pci tracker to udpate those? | |
| 15:35:41 | sean-k-mooney | which means if we restart the compute agent that info is not actully lost | |
| 15:35:52 | sean-k-mooney | yes | |
| 15:36:33 | artom | sean-k-mooney, so what's wrong with using that exisiting plumbing? | |
| 15:36:45 | sean-k-mooney | but thats kind of missign the point that i dont really think how we do claimis is a good thing. i know othere wanted to move to a model weher we rely more on plament allocation and directl claims or resouce that are not tempory in memory | |
| 15:36:57 | artom | sean-k-mooney, Placement, sure | |
| 15:37:11 | artom | But let's be honest, NUMA in placement is never happening :P | |
| 15:37:24 | sean-k-mooney | we basically have two source of info here the live migration claim and the migrate_data | |
| 15:37:40 | artom | sean-k-mooney, the migrate data is just the info for the source to update the XML | |
| 15:37:43 | sean-k-mooney | well actully we might eventually have to make that deciesion | |
| 15:37:51 | artom | The claim is for resources consumed | |
| 15:38:05 | sean-k-mooney | there are feature that have been waitn 4+year for numa in placment | |
| 15:38:23 | sean-k-mooney | im not really sure we can justify blocking them to much longer but ill try to get it done next cycle | |
| 15:38:38 | sean-k-mooney | after wallaby however we really need to consier if we will ever do int plamcent | |
| 15:39:03 | sean-k-mooney | we did not need placment ot solve the races we have with numa | |
| 15:39:14 | sean-k-mooney | we just need to not use claims the way they are right now | |
| 15:39:25 | sean-k-mooney | that is one of my main issue with them | |
| 15:39:42 | sean-k-mooney | because the calims are done locally on the compute node it cause the numa races | |
| 15:39:46 | artom | sean-k-mooney, plus, we *already have* PCI stuff in the rt's _move_claim() | |
| 15:40:03 | sean-k-mooney | for what | |
| 15:40:13 | artom | Moves :) Cold migrations | |
| 15:40:13 | sean-k-mooney | oh you put in a hack i remmeber | |
| 15:40:20 | sean-k-mooney | ya for cold migation | |
| 15:40:26 | sean-k-mooney | but also the hack for live | |
| 15:40:35 | sean-k-mooney | where we dont set them or something | |
| 15:41:54 | sean-k-mooney | this https://github.com/openstack/nova/blob/f521f4dbace0e35bedd089369da6f6969da5ca32/nova/compute/resource_tracker.py#L303-L314 | |
| 15:42:11 | artom | gibi, so https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L223 is the live migration claim creation method, that creates the migration context with the old and new NUMA topologies by calling down to _move_claim() | |
| 15:42:53 | artom | gibi, and yeah, sean-k-mooney found my TODO about converging the 2 (NUMA and SRIOV live migration) | |
| 15:43:39 | artom | gibi, the live migration claim is created on the destination at https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L7670 | |
| 15:43:40 | sean-k-mooney | right which i objected too at the time and still do unless we remove the migration_data object | |
| 15:43:56 | sean-k-mooney | and and a couple of other things | |
| 15:44:14 | sean-k-mooney | like moving claims for spawn and other vent to the conductor | |
| 15:44:25 | sean-k-mooney | or ideally earlier | |
| 15:44:28 | artom | gibi, and then we eventually save the dest stuff (like numa topology) here: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L8587 | |
| 15:45:13 | sean-k-mooney | artom: if its not clear as far as i am concerned the main reason we have races with numa is due to claims beign done on the compute node. that is what placment and numa in plamcnet was ment to solve | |
| 15:46:24 | sean-k-mooney | or we could have fixed it years ago if claims were dont in the scuderler of conductor | |
| 15:46:39 | sean-k-mooney | gibi: https://github.com/openstack/nova/blob/f521f4dbace0e35bedd089369da6f6969da5ca32/nova/compute/resource_tracker.py#L328 | |
| 15:46:59 | sean-k-mooney | gibi: you need to use the new_numa_topology for the migration context | |
| 15:47:13 | artom | sean-k-mooney, it's not so much *where* they're done, it's that scheduling and claiming happened in 2 steps | |
| 15:47:30 | sean-k-mooney | artom: yes which is where they are done | |
| 15:47:32 | artom | sean-k-mooney, but yeah, claiming in the scheduler would have fixed that, because we could have made schedule + claim atomic | |
| 15:47:42 | sean-k-mooney | yes | |
| 15:47:53 | sean-k-mooney | which is what i argured for befor placment was created | |
| 15:48:06 | artom | Yeah, I could get behind that | |
| 15:48:13 | artom | But it's moot at this point | |
| 15:48:19 | artom | For better or worse | |
| 15:48:33 | mriedem | search is busted in the docs https://docs.openstack.org/nova/latest/search.html?q=cross_az_attach - click on one of those | |
| 15:48:55 | sean-k-mooney | oh it is | |
| 15:48:58 | sean-k-mooney | did we move things | |
| 15:49:11 | gibi | sean-k-mooney, artom: thanks I think I see it now | |
| 15:49:12 | sean-k-mooney | availability-zonesundefined | |
| 15:49:17 | artom | Where did the 'undefined' in that URL come from? | |
| 15:49:26 | artom | gibi, that's actually impressive that you do :) | |
| 15:49:28 | sean-k-mooney | so we are not substituing somthing | |
| 15:49:43 | gibi | artom: I see from where I need to use the topology | |
| 15:50:12 | gibi | artom: honeslty I don't have the brainpower to deeploy follow the argument about claims vs pci_tracker | |
| 15:50:13 | sean-k-mooney | migration_contex.new_toplogy | |
| 15:50:18 | mriedem | https://bugs.launchpad.net/nova/+bug/1893238 | |
| 15:50:18 | openstack | Launchpad bug 1893238 in OpenStack Compute (nova) "nova document search result links not working" [Undecided,New] | |
| 15:50:54 | sean-k-mooney | ha we must have chagne some of the shinx setting | |
| 15:51:49 | gibi | ohh, nova meeting starts in 9 minutes in #openstack-meeting-3 | |
| 15:53:00 | bauzas | this meeting time kills me :( | |
| 15:53:33 | gibi | bauzas: how can I help? | |
| 15:53:45 | bauzas | nothing really, I'll attend | |
| 15:53:57 | bauzas | but please, be short :) | |
| 15:54:09 | gibi | I will try | |
| 15:58:54 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: post live migration: don't call Neutron needlessly https://review.opendev.org/747451 | |
| 16:00:20 | stephenfin | artom: got a flake8 issue on https://review.opendev.org/#/c/747451/ | |
| 16:00:38 | artom | gdi | |
| 16:01:50 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: trivial: Remove useless comment https://review.opendev.org/748475 | |
| 16:02:06 | artom | stephenfin, in the meantime, here's that useless comment removal ^^ | |
| 16:04:01 | stephenfin | +2 | |
| 16:04:57 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: post live migration: don't call Neutron needlessly https://review.opendev.org/747451 | |
| 16:50:14 | artom | lyarwood, melwitt, wanna take a gander at https://review.opendev.org/#/c/747451/? | |
| 16:51:08 | lyarwood | artom: I can try | |
| 16:51:16 | artom | lyarwood, cheers! | |
| 16:53:28 | gibi | gmann: sorry I totally forget you a second time too | |
| 16:53:36 | gibi | gmann: /o\ | |
| 16:53:56 | gibi | gmann: is there anything important from API side? | |
| 16:56:21 | gmann | gibi: ah yeah me too :). just json to yaml migration, anyways let me get oslo tooling in for that and then we can talk on nova patch - https://review.opendev.org/#/q/topic:bp/policy-json-to-yaml+(status:open+OR+status:merged) | |
| 16:57:22 | gibi | gmann: seems like a fairly easy nova change | |
| 16:58:01 | gibi | gmann: if the oslo change lands before the non-client library freeze then we can try to land the nova change before m3 | |
| 16:58:25 | gmann | yeah. i hope at least with upgrade checks, changing the default value would not break operators but dansmith or johnthetubaguy can corret me | |
| 16:58:48 | gmann | gibi: yeah that is the plan. i think we can merge the olso change by tomorrow | |
| 16:59:06 | gibi | cool, let's get back to this tomorrow or next week | |
| 16:59:12 | gibi | I have to drop now | |
| 16:59:14 | gmann | yup | |
| 16:59:51 | gibi | o/ | |
| 17:00:23 | dansmith | gmann: json still works, right? | |
| 17:00:57 | gmann | dansmith: yeah it will work but default value of policy_file will change. https://review.opendev.org/#/c/748059/1/nova/policy.py | |
| 17:01:02 | dansmith | yaml is the default for the generation, right? I wouldn't think any problem on upgrade that wouldn't happen if we overwrote their file with fresh jsson anyway | |
| 17:01:08 | dansmith | oh | |
| 17:01:24 | gmann | i mean is anyone has policy.json then it has to be converted to policy,yaml | |
| 17:01:44 | dansmith | wait, they *have* to convert to yaml? | |
| 17:03:00 | gmann | yeah because of extension name change in default value. json formatted still work though | |
| 17:03:16 | dansmith | you mean if they take the default | |
| 17:03:18 | dansmith | file name | |
| 17:03:21 | gmann | yes | |