| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-27 | |||
| 10:25:13 | sean-k-mooney | we are making a copy of all the values and construction an new list | |
| 10:25:21 | bauzas | stephenfin: i want snow | |
| 10:25:25 | aspiers | stephenfin: you can have any blue, as long as it's black | |
| 10:25:30 | sean-k-mooney | bauzas: but anyway do like the new version in general | |
| 10:25:35 | stephenfin | bauzas: You can't handle the snow. | |
| 10:25:44 | bauzas | testtools.matchers._impl.MismatchError: [1, 2, 3, 4] != [1, 2, 4, 3] | |
| 10:25:44 | sean-k-mooney | bauzas: its closer to what i had originally planned for the funciton | |
| 10:25:48 | bauzas | this ^ | |
| 10:25:51 | aspiers | right | |
| 10:25:53 | sean-k-mooney | ya i saw that | |
| 10:25:57 | sean-k-mooney | i was going to fix it | |
| 10:25:58 | cdent | These conversations make me laugh. We're talking about trying to maintain py2 code when real people won't see it for many months, they are all still long time behind now. | |
| 10:26:02 | sean-k-mooney | im relying on dict order | |
| 10:26:09 | sean-k-mooney | wich is only a py36+ thing | |
| 10:26:12 | sean-k-mooney | ill fix that | |
| 10:26:31 | aspiers | sean-k-mooney: you want me to submit my typo/pep8 fixes? | |
| 10:26:39 | stephenfin | bauzas: Oh, here's another one you'll probably want to look at https://review.opendev.org/#/c/674894/ | |
| 10:26:48 | cdent | We should be on at least py3.7 everywhere, because by the time the majority of people are using the code... | |
| 10:26:48 | sean-k-mooney | aspiers: you can if you like. | |
| 10:26:49 | stephenfin | I think you know that code from the vGPU work | |
| 10:27:05 | stephenfin | cdent: only ~ two months to go | |
| 10:27:11 | stephenfin | tick-tock tick-tock | |
| 10:27:18 | cdent | :fist bump: | |
| 10:27:24 | cdent | or :something: | |
| 10:27:58 | bauzas | stephenfin: looking | |
| 10:27:59 | stephenfin | and when we do, I'm doing this _everywhere_ https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/integrate-mypy-type-checking | |
| 10:28:04 | stephenfin | starting with oslo | |
| 10:28:09 | sean-k-mooney | bauzas: i can move the _project_traits function out of the class too. | |
| 10:28:27 | bauzas | sean-k-mooney: honestly, that really depends on what you want | |
| 10:28:37 | bauzas | sean-k-mooney: I'm not particularly opinionated | |
| 10:28:41 | sean-k-mooney | i want it to be a staticmethod | |
| 10:28:47 | bauzas | sean-k-mooney: but I feel we should just make it simplier | |
| 10:29:32 | bauzas | sean-k-mooney: what's fun is that you explain that this method is absolutely unrelated to the driver, but you call it by its libvirt class name :) | |
| 10:29:34 | sean-k-mooney | if we can make it simpler without reducing functionality the sure. have you looked at the folow up patches | |
| 10:29:54 | sean-k-mooney | bauzas: no i want to call it with self | |
| 10:30:22 | bauzas | sean-k-mooney: no I haven't looked at othre patches yet | |
| 10:30:39 | openstackgerrit | Adam Spiers proposed openstack/nova master: Libvirt: report storage bus traits https://review.opendev.org/666914 | |
| 10:30:42 | aspiers | sean-k-mooney: ^^^ | |
| 10:30:43 | sean-k-mooney | @staticmothod is intened to allow you to associate free functions with a class so that they are callable like methods | |
| 10:31:17 | aspiers | sean-k-mooney: also, might be just me, but I would personally prefer test_flatten_iterable to be split into multiple smaller test cases | |
| 10:31:34 | sean-k-mooney | am i could to that | |
| 10:31:36 | aspiers | sean-k-mooney: currently when an assertion fails, you can't immediately see which one failed | |
| 10:31:55 | sean-k-mooney | i built it iteritivly so it was simpler to built up with more test cases | |
| 10:31:59 | aspiers | also giving each a separate method name would add some clarity to exactly what is being tested | |
| 10:32:05 | aspiers | sure | |
| 10:32:22 | sean-k-mooney | i kind of grouped them intentionally expceting that comment :) | |
| 10:32:30 | sean-k-mooney | so ill split it in the next version | |
| 10:32:39 | bauzas | sean-k-mooney: have you clicked on my link ? :) | |
| 10:32:53 | sean-k-mooney | yes | |
| 10:33:34 | sean-k-mooney | that is not my usecase and it is not a good argument | |
| 10:33:49 | sean-k-mooney | i want to be able to call it via self not via the class name | |
| 10:34:05 | sean-k-mooney | i can call it via the class name if im in a non instance/class method | |
| 10:34:20 | sean-k-mooney | but i an instnace method i wanted to call it via self | |
| 10:35:38 | aspiers | sean-k-mooney: cool thanks | |
| 10:36:01 | bauzas | sean-k-mooney: just make it a classmethod the,n | |
| 10:36:33 | bauzas | anyway, I need to eat | |
| 10:36:47 | sean-k-mooney | it does not need to use any class method or variables. | |
| 10:40:41 | sean-k-mooney | anyway i dont really want to argue about this. static method would be the correct decorator to use but maybe instead of sayign what i actully mean i should write the dumbest version that works... | |
| 10:41:45 | openstackgerrit | Chris Dent proposed openstack/nova master: Add a "Caveats" section to the eventlet profiling docs https://review.opendev.org/676672 | |
| 10:49:09 | sean-k-mooney | bauzas: by the way do you think flatten_iterable shoudl yield the values as it does now or the item tuples. i started with the tuples but it was making the code more complex. i feel like a sperate flatten_mapping would be better if we need it in the future | |
| 10:49:33 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110 | |
| 10:51:54 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111 | |
| 10:54:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add request_spec to server move RPC calls https://review.opendev.org/655721 | |
| 10:56:32 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112 | |
| 10:58:53 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422 | |
| 11:01:16 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114 | |
| 11:03:35 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109 | |
| 11:05:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request https://review.opendev.org/655113 | |
| 11:08:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware https://review.opendev.org/676138 | |
| 11:10:35 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth https://review.opendev.org/676140 | |
| 11:10:57 | openstackgerrit | Merged openstack/nova master: [Trivial]Remove unused helper get_vm_ref_from_name https://review.opendev.org/678444 | |
| 11:12:55 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth https://review.opendev.org/676972 | |
| 11:15:20 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth https://review.opendev.org/676980 | |
| 11:17:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497 | |
| 11:17:54 | sean-k-mooney | gibi: does ^ work with sriov livemigrtaion or just cold migration | |
| 11:18:33 | gibi | sean-k-mooney: just cold so far | |
| 11:18:51 | gibi | sean-k-mooney: I still have to work on live migrate, evacuate, and shelve offload | |
| 11:18:54 | sean-k-mooney | ok do you have live migration support ingeneral | |
| 11:18:58 | sean-k-mooney | ah ok | |
| 11:19:12 | sean-k-mooney | i dont think you will have to do anything spcial for sriov in that regard | |
| 11:19:16 | gibi | sean-k-mooney: I expect resize to work out of the box but I have to add functinal coverage for it | |
| 11:19:29 | sean-k-mooney | if you get generic live migration working then it should work for sriov too | |
| 11:20:13 | gibi | sean-k-mooney: the selection of pci devices needs to be driven the same way for live migration as it is now done for cold migration | |
| 11:20:27 | gibi | sean-k-mooney: but besides that I don't expect any sriov specific thing | |
| 11:20:39 | sean-k-mooney | we handel that differently for sriov | |
| 11:20:44 | sean-k-mooney | we do not use move claims | |
| 11:21:02 | sean-k-mooney | so i hope you are not assuming we do | |
| 11:21:18 | sean-k-mooney | ill take a look at the patch in either case | |
| 11:22:21 | gibi | sean-k-mooney: how does live migration selects the pci device on the target host? | |
| 11:23:12 | sean-k-mooney | we claim the in the pci resouce tracker in check_can_live_migrate_at_dest | |
| 11:23:12 | gibi | sean-k-mooney: if it uses the InstancePCIRequest then I think my strategy will work | |
| 11:23:52 | sean-k-mooney | we create new instancePCIRequest object i think | |
| 11:24:12 | gibi | sean-k-mooney: OK, then I need to patch those requests with https://review.opendev.org/#/c/676980/6/nova/compute/manager.py@2141 | |
| 11:25:14 | sean-k-mooney | then we store the pci addresse of the new vif objects in the migrate_data | |
| 11:25:28 | sean-k-mooney | oh the provider_mappings | |
| 11:25:32 | sean-k-mooney | ya proably | |
| 11:25:54 | sean-k-mooney | did you see my comment by the way regarding the lenght of that parmater/variable | |
| 11:26:26 | gibi | sean-k-mooney: I'm going through the series today so I will | |
| 11:27:01 | sean-k-mooney | basically request_group_resource_providers_mapping -> provider_mappings | |
| 11:27:48 | aspiers | sean-k-mooney: shall I rebase the other 2 patches on top so that they have a chance of passing pep8 at least? | |