| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-27 | |||
| 14:26:56 | bauzas | sean-k-mooney: hold my beer | |
| 14:29:12 | bauzas | sean-k-mooney: I personnally like to consider being able to join a free ISP with a specific AS if my ISP sucks | |
| 14:29:26 | bauzas | which won't be possible if I go with starlink | |
| 14:29:44 | bauzas | that, and the fact I don't like how this will pollute space | |
| 14:30:21 | sean-k-mooney | also you dont want to have to wait till 2021 or later when it actully start going live | |
| 14:30:58 | bauzas | honestly, I could just pay a local mobile provider and run a LTE connection with 100 gigs fair use | |
| 14:31:50 | bauzas | sean-k-mooney: well, about 2021, I become almost sure that starlink would be operational before I get optic fiber at home | |
| 14:34:47 | sean-k-mooney | ya if im at my mother house i get 150 down and about 80 up on my phone while her landline broadband only get 4 down and .25-.6 up on a good day | |
| 14:35:23 | sean-k-mooney | i have suggested just bying a pone pluging it in and paying the 30 euro a month for unlimited broadband with thearhing allowed | |
| 14:35:34 | sean-k-mooney | it would be a 1TB fair usge limit | |
| 14:37:38 | lyarwood | https://paste.centos.org/view/39276981 <- can anyone think why I could be getting this error in a func test on stable/train using integrated_helpers._IntegratedTestBase and starting two compute services ? | |
| 14:37:45 | lyarwood | ComputeHostNotFound: Compute host 2 could not be found. | |
| 14:37:52 | lyarwood | everything seems to start correctly | |
| 14:38:48 | lyarwood | for context I'm backporting https://review.opendev.org/#/q/Ib9dbc792dc918e7ea45915e2c1dbd96be82ef562 | |
| 14:41:34 | aarents | stephenfin: not sure to get this one: https://review.opendev.org/#/c/747957/4/nova/tests/unit/compute/test_compute.py@10296 (I replied) | |
| 14:50:21 | stephenfin | aarents: Fair point. Ignore that comment :) | |
| 14:50:27 | stephenfin | (replied also) | |
| 14:56:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Make PCI claim NUMA aware during live migration https://review.opendev.org/748453 | |
| 14:57:04 | aarents | stephenfin: oky thks, I will fixup the others | |
| 14:57:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: [WIP] Support SRIOV interface attach and detach https://review.opendev.org/740995 | |
| 14:59:09 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: tracing the PCI allocation code path https://review.opendev.org/748454 | |
| 15:01:02 | gibi | sean-k-mooney: added some logs ^^ to see why the pci device goes to allocated immediately in your env | |
| 15:01:17 | gibi | I mean why it doesn't go to allocated | |
| 15:12:19 | sean-k-mooney | gibi: so i still dont think we should make sriov use claims for what its worth | |
| 15:12:45 | sean-k-mooney | im hoping eventully claims wil go away and we will use migrate data like we do with sriov migration | |
| 15:13:08 | sean-k-mooney | oh sorry this is something esle | |
| 15:13:24 | sean-k-mooney | ya ok i see what you have changed | |
| 15:13:54 | sean-k-mooney | gibi: i was getting confused with the TODO to converge numa migration and sriov migration to claim devices in a common way | |
| 15:14:20 | sean-k-mooney | https://review.opendev.org/#/c/748453/1/nova/compute/resource_tracker.py is adress the comment i left about not passign the numa toplogy | |
| 15:24:02 | sean-k-mooney | artom: this is better then we do today where we dont pass the numa toplogy but its still wrogn correct^ | |
| 15:24:17 | sean-k-mooney | https://review.opendev.org/#/c/748453/1 | |
| 15:25:26 | gibi | sean-k-mooney: do you mean we pass the wrong topology during live migration? | |
| 15:25:41 | sean-k-mooney | it depend on where that is being called | |
| 15:25:56 | artom | gibi, I think sean-k-mooney means adding PCI devices to the _live_migration_claim()... | |
| 15:26:08 | sean-k-mooney | artom: well i want to delete that | |
| 15:26:24 | artom | sean-k-mooney, delete... the _live_migration_claim()? | |
| 15:26:25 | sean-k-mooney | but currently its done in check_can_live_migrate_destination | |
| 15:26:35 | sean-k-mooney | artom: i want to remove claims eventually | |
| 15:26:43 | artom | In favor of what? | |
| 15:26:53 | artom | They're like the basis of all of NUMA live migraiton | |
| 15:27:01 | sean-k-mooney | yep i know | |
| 15:27:09 | artom | And I mean... they work. | |
| 15:27:19 | sean-k-mooney | in favor of doing it the way we do for sriov live migration | |
| 15:27:29 | artom | ... why? | |
| 15:27:30 | sean-k-mooney | anyway different topic for a different day | |
| 15:27:36 | gibi | :) | |
| 15:27:46 | sean-k-mooney | port_id_to_pci = self._claim_pci_for_instance_vifs(ctxt, instance) | |
| 15:27:58 | artom | Like yeah, they're hard to grok initially, but they do a bunch of useful things | |
| 15:28:01 | sean-k-mooney | we do that in check_can_live_migrate_destination | |
| 15:28:04 | artom | And they're battle-tested | |
| 15:29:13 | sean-k-mooney | im not sure which numa toplogy is stored in the instance at that point | |
| 15:29:14 | artom | I mean not really for another day, because gibi's patch has to chose 1 or the other... | |
| 15:29:19 | sean-k-mooney | is it the souce numa toplogy or the dest | |
| 15:29:33 | artom | sean-k-mooney, the source, until we apply_move_claim() | |
| 15:29:50 | sean-k-mooney | ok so then that is the wrong numa toplogy for 2 reasons | |
| 15:29:57 | sean-k-mooney | first the souce and dest can differ | |
| 15:30:04 | gibi | I have access to the MoveClaim but that also seems to returning the numa topology stored on the instnace | |
| 15:30:12 | sean-k-mooney | and second if the dest numa toplogy has not been caulated with the numa reuqirement it also wrong | |
| 15:30:43 | sean-k-mooney | we shoudl be geting the toplogy info form the migate_data object right | |
| 15:30:59 | gibi | sean-k-mooney: I did not found it there | |
| 15:31:00 | artom | sean-k-mooney, the whole point of using claims was to calculate the dest numa topology, and store the old and new until we apply the claim... | |
| 15:31:32 | sean-k-mooney | artom: right but sriov migration merged a few months before any for the numa migration stuff did | |
| 15:31:34 | gibi | artom let me know where is the dest numa topology stored and I will modify my patch | |
| 15:31:47 | sean-k-mooney | and it was expictly not using move claims | |
| 15:32:09 | artom | sean-k-mooney, I know, we discussed that during review | |
| 15:32:43 | sean-k-mooney | yes i wanted to move to a case where we claimd resouce in the db and passed the info via migrate data and start using that of all move operations | |
| 15:32:59 | artom | That's what claims do :) | |
| 15:33:04 | sean-k-mooney | badly | |
| 15:33:12 | artom | Why? | |
| 15:33:28 | sean-k-mooney | for one they dont actully store them in the db | |
| 15:33:49 | sean-k-mooney | the are in memroy we are not claiming indivutal resouce on the numa toplogy blob for example | |
| 15:33:52 | artom | Store what? The resource usage? Yes they do, the update the resource tracker, and the migration is consuming the resources | |
| 15:33:54 | sean-k-mooney | the host one | |
| 15:34:25 | sean-k-mooney | claims basically are boolean this is free or it might be used | |
| 15:34:35 | sean-k-mooney | with pci devces we have a tristate | |
| 15:34:37 | artom | Yeah, the eventually call down to rt._update() or w/e it's called | |
| 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 | |