Earlier  
Posted Nick Remark
#openstack-nova - 2019-08-23
15:57:51 sean-k-mooney mriedem: im going to step away for an hour or so to have breakfast/lunch but i plan to adress your comments on https://review.opendev.org/#/c/669738/ when i get back since they have been waiting a while.
15:58:49 mriedem breakfast/lunch?
15:58:59 mriedem it's 5pm
15:59:00 sean-k-mooney lyarwood: mriedem if we can land https://review.opendev.org/#/c/678098/ on stable stine that would make mnaser happy
15:59:37 sean-k-mooney yes.. i normally eat once to twice a day. usually i try to grab something at around 3
15:59:48 sean-k-mooney and then around 8
16:00:28 sean-k-mooney or i jsut have one big meal around 6 and then snack on fruit/nuts/small things
16:02:48 mriedem i just got the image of you as the giant in jack and the beanstalk crushing human bones to make your bread
16:02:50 mriedem "small things"
16:04:12 dansmith artom: I looked at the top two patches with plans to prescribe an ordering and squash/split instructions, but I think it probably just needs to be fully squashed
16:04:53 artom dansmith, yeah? I was hoping to avoid that, as it makes reviewing difficult
16:04:56 dansmith I know
16:05:10 dansmith I kept calling out lines as "this could be separate" and then removed those comments
16:05:26 artom But you're most likely right (duh!), as a whole bunch of things need to happen in one chunk
16:06:17 dansmith yup, any ordering that I could come up with was dependent on a patch ahead of everything that was like "add a bunch of single-line unrelated changes to various places" followed by a bigger one that hooked them all up
16:06:21 dansmith and it just doesn't make sense
16:06:47 dansmith I kept having to jump back and forth between those two patches to work that out and ultimately fail, which means reviewing isn't really improved
16:06:54 dansmith fewer lines, but not in a meaningful way, so...
16:07:11 artom Well, at least the commit message is already in bullet points
16:07:31 dansmith usually that's a bad sign, but in this case, I don't really see a useful way around
16:07:45 dansmith mriedem might disagree, but hopefully not
16:08:01 dansmith he likes to disagree with me periodically to make himself look smart though
16:08:33 dansmith or to assert his smartness, maybe I should say
16:08:46 artom Oh, nice save
16:08:51 dansmith heh
16:10:45 mriedem https://www.youtube.com/watch?v=YLP1_jwT9_M
16:11:12 dansmith heh
16:11:50 dansmith https://www.youtube.com/watch?v=oGfkPCZYfFw
16:12:35 artom Have we finally devolved to communicating via only YouTube videos?
16:12:55 dansmith trying to speak mriedem's language
16:12:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422
16:12:56 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
16:14:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Docs and functional test for max_local_block_devices https://review.opendev.org/678268
16:15:16 openstackgerrit Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109
16:16:39 dougsz One other question (sorry!). If I upgrade one cell of many, run online_data_migrations in that cell only, set upgrade_levels to auto (or N-1 level) to pin RPC version, will there be a performance penalty in that cell, until all cells move to the latest RPC version?
16:17:05 dansmith dougsz: you need to move the upgrade pin only once all the cells are updated
16:17:19 dansmith otherwise the conductors will start speaking newer versions to the old cells
16:17:29 dansmith also,
16:17:31 dougsz so auto is not good enough?
16:18:00 dansmith if you use auto, then it will always get the minimum support version, you don't need to tweak it before and after
16:18:11 dansmith online-data-migrations is unrelated to the rpc pin version fwiw
16:19:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: Func test for migrate server with ports having resource request https://review.opendev.org/655113
16:19:54 openstackgerrit Balazs Gibizer proposed openstack/nova master: Make _rever_allocation nested allocation aware https://review.opendev.org/676138
16:20:42 dougsz ok, thanks, that makes sense, i can upgrade a single cell and take my time checking that it doesn't catch fire before upgrading the others
16:21:00 dansmith theoretically yes
16:21:06 dougsz :)
16:21:10 dansmith I believe cern does this
16:23:13 openstackgerrit Merged openstack/nova master: trivial: Rename exception argument https://review.opendev.org/671795
16:23:22 openstackgerrit Merged openstack/nova master: Remove 'hardware.get_host_numa_usage_from_instance' https://review.opendev.org/671797
16:23:35 openstackgerrit Merged openstack/nova master: Remove 'hardware.host_topology_and_format_from_host' https://review.opendev.org/671798
16:23:45 openstackgerrit Merged openstack/nova master: Remove 'hardware.instance_topology_from_instance' https://review.opendev.org/671799
16:23:57 openstackgerrit Merged openstack/nova master: Rework 'hardware.numa_usage_from_instances' https://review.opendev.org/672565
16:24:49 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support reverting migration / resize with bandwidth https://review.opendev.org/676140
16:27:10 openstackgerrit Balazs Gibizer proposed openstack/nova master: Func test for migrate re-schedule with bandwidth https://review.opendev.org/676972
16:29:10 stephenfin Nice. Delighted to get rid of all those awful functions ^
16:29:22 stephenfin This is all going swimmingly
16:29:32 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support migrating SRIOV port with bandwidth https://review.opendev.org/676980
16:31:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow migrating server with port resource request https://review.opendev.org/671497
16:36:06 artom dansmith, about the is_trackable_migration removal...
16:36:24 dansmith yar
16:36:30 artom We obviously need to get rid of it, because we want the resource tracker to track NUMA live migrations and update resource usage accordingly
16:37:13 artom But we're removing it entirely, not just for NUMA live migrations.
16:37:22 dansmith isn't this just for reporting purposes?
16:37:33 artom Well, resource usage as well
16:37:35 dansmith I've mostly dumped this out of my brain because placement,
16:37:44 artom NUMATopologyFilter still uses it
16:37:47 dansmith but does the scheduler actually use some of this information anymore?
16:37:51 dansmith right, okay, the legacy things
16:38:27 artom So because we'll be tracking all live migrations, we need to do claims for all live migrations, not just NUMA ones
16:38:35 artom (which is what's currently in the patch series)
16:38:39 dansmith so right now we don't report this for live migrations, nor do we claim, so the numa filter will send us things we don't have room for, and we also won't do claims to check that it was wrong, right?
16:38:55 artom Yep
16:39:14 dansmith okay, but non-numa-affected live migrations are already protected and don't need anything else right?
16:39:21 dansmith because we're depending on placement for the non-numa resources
16:39:32 artom Yeah, that should be fine
16:39:40 artom I was more worried about things like PCI
16:40:05 artom Though I guess we don't support live migrations for those at all, so it the claim fails, it'll just be a plus
16:40:11 dansmith no live migration with pci devices yeah?
16:40:12 dansmith right
16:40:16 dansmith so to continue my thought above,
16:40:21 artom Though that's completely untested
16:40:30 dansmith I think you can save that change until the very end,
16:40:56 dansmith because once we're claiming, we're doing better than we are today, and then we can start reporting them, which is another incremental improvement to make the scheduler make better decisions
16:41:24 artom The very end == the massive squashed patch, right?
16:41:35 dansmith well, wherever
16:41:38 dansmith just saing,
16:41:53 dansmith it doesn't need to be synchronous with the change to claim I think
16:42:29 artom Oh, right, that's a given. I've addressed all that feedback, now working on squashing
16:42:43 dansmith okay
16:42:59 dansmith seems like it might be a good candidate for being its own patch though.. right?
16:44:23 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'hw:cpu_policy', 'hw:mem_page_size' extra specs from API samples https://review.opendev.org/675338
16:44:24 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement https://review.opendev.org/671792
16:44:24 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available' https://review.opendev.org/672693
16:44:25 openstackgerrit Stephen Finucane proposed openstack/nova master: trivial: Rewrap definitions of 'NUMACell' https://review.opendev.org/674395
16:44:25 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs https://review.opendev.org/671800
16:44:26 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Rename 'fields' import to 'obj_fields' https://review.opendev.org/674103
16:44:26 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait https://review.opendev.org/675571
16:44:27 openstackgerrit Stephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta https://review.opendev.org/671801
16:44:27 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Fold in argument to '_update_provider_tree_for_vgpu' https://review.opendev.org/676729
16:44:28 openstackgerrit Stephen Finucane proposed openstack/nova master: Add reshaper for PCPU https://review.opendev.org/674895

Earlier   Later