| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-27 | |||
| 13:51:18 | gibi | I have no problem with Ikea stuff, my kichen is from there | |
| 13:51:26 | bauzas | you know that you frequented too much Ikea when you're able to name furniture by their Ikea names | |
| 13:52:31 | bauzas | gibi: worth saying, the Markus chair is very decent for the price | |
| 13:52:58 | bauzas | this saves my butt 5 times a week, 10 hours per day | |
| 13:53:24 | gibi | thanks for the suggestion | |
| 13:54:29 | gibi | do you happen to have one of those Ikea Skarsta desk? | |
| 13:54:43 | bauzas | nope but I know them | |
| 13:55:08 | gibi | is it worth the price tag? | |
| 13:55:14 | bauzas | looks like, yes | |
| 13:55:21 | bauzas | some coworkers have them | |
| 13:56:55 | gibi | cool, thanks. | |
| 13:57:15 | bauzas | (I personnally have the Linnmon desk, cheap but large) | |
| 13:59:39 | bauzas | gibi: still homeoffice, I guess ? | |
| 13:59:57 | gibi | yes. It seems this year I don't have to go back to the office if I don't want to | |
| 14:02:49 | bauzas | this seems reasonable | |
| 14:07:03 | artom | lyarwood, https://review.opendev.org/#/c/720769/5 -0.5 I guess? | |
| 14:07:14 | artom | I left it voteless, take it or leave it :P | |
| 14:09:35 | artom | OK, on second thought, -1. Comment left. | |
| 14:11:21 | lyarwood | artom: that's dead until W btw | |
| 14:19:09 | stephenfin | aarents: Comment on https://review.opendev.org/#/c/747957/ | |
| 14:20:03 | stephenfin | bauzas: Is https://review.opendev.org/#/c/748271/ sufficient to resolve your concerns with https://review.opendev.org/#/c/747744/ ? | |
| 14:20:46 | bauzas | stephenfin: thanks, yes it is | |
| 14:20:59 | stephenfin | hurray | |
| 14:21:36 | stephenfin | Great. Can rebase and remove the duplication from the vTPM series then (y) | |
| 14:23:00 | aarents | stephenfin: thks | |
| 14:25:26 | sean-k-mooney | bauzas i have a few metere of optic cable left over from when they installed mine i can proably post it to you:P eventurlly you can collect enough and run it yourslef probalem solved right | |
| 14:26:20 | sean-k-mooney | bauzas: starlink is ment to be roling out early next year too | |
| 14:26:37 | sean-k-mooney | if the price is right that might be an option | |
| 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 | |