Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-16
18:03:51 spatel also i don't think kvm support that
18:20:18 donnyd Was there still interest in the NUMA for fortnebula?
18:20:49 donnyd LOL... interest in NUMA topologies
18:21:35 donnyd I have things to a more stable state with decent performance, so now I can move forward
18:25:31 openstackgerrit Mauricio Tavares proposed openstack/nova master: Increases the level of detail provided by the debug messages in pci_passthrough_filter.py. https://review.opendev.org/671106
18:30:41 efried artom, sean-k-mooney: ---^ ?
18:39:58 artom donnyd, yes please, I would like 1 the NUMA ;)
18:40:24 donnyd LOL +2
18:40:27 artom For serious though, yeah, flavors with >= 2 NUMA nodes would be awesome
18:40:34 donnyd you get 2 numas artom
18:41:26 donnyd I am not deep in the zuul or nodepool code, so how does the test work. Can you ask for a specific flavor?
18:41:53 donnyd I need a way to stay compatible with the other jobs
18:41:59 artom efried, I don't even know where to start with that. I guess look at the logic before drowning them with the formatting and whitespace nits?
18:42:24 artom donnyd, that's not my strong suite, I'm afraid
18:42:55 efried artom: I was pointing at donnyd, not at Mauricio's patch
18:43:06 artom efried, oh, hah
18:43:38 efried my ---^ was an attempt to go around the corner
18:44:16 artom donnyd, sean-k-mooney would most likely know, though I hate to pile even more things on this plate
18:44:31 artom Or ask in -infra? Is that good advice?
18:46:39 donnyd 2:44 PM <clarkb> there isnt
18:46:39 donnyd 2:44 PM <clarkb> we can do provider specific flavors but generally avoid that to handle cloud outages
19:04:21 donnyd artom: I will have to learn how to setup NUMA aware flavors, (unless someone knows off the top of their head) and it looks like we have a path forward
19:05:59 artom donnyd, it's kinda tedious, but not super hard: https://docs.openstack.org/nova/latest/user/flavors.html
19:06:05 artom Scroll down to CPU topology
19:06:24 artom Sorry, NUMA topology
19:06:34 donnyd Ok, I will take a look
19:07:08 artom Actually both
19:07:58 artom hw:cpu_ controls the guest topology, hw:numa_ controls how it maps onto host hardware
19:11:30 openstackgerrit Merged openstack/nova master: Use Adapter global_request_id kwarg https://review.opendev.org/670907
19:58:44 prometheanfire is one of the use cases for nova to run 1-3 compute nodes in 3-4 DCs across the world? (via host aggregates and AZs)
19:59:02 openstackgerrit Eric Fried proposed openstack/nova master: Nova object changes for forbidden aggregates request filter https://review.opendev.org/671072
19:59:02 openstackgerrit Eric Fried proposed openstack/nova master: DB API changes to get non-matching aggregates from metadata https://review.opendev.org/671074
19:59:03 openstackgerrit Eric Fried proposed openstack/nova master: Add a new request filter to forbidden aggregates https://review.opendev.org/671075
19:59:03 openstackgerrit Eric Fried proposed openstack/nova master: Enable request filter forbidden_aggregates https://review.opendev.org/667952
20:00:10 efried prometheanfire: What's this in reference to?
20:00:53 prometheanfire sometihng I may be doing soon
20:01:09 prometheanfire cross continental rabbit could be fun
20:01:34 prometheanfire just not sure if it's an intended (supported) use case for nova
20:03:34 openstackgerrit Merged openstack/nova master: vif: Remove 'plug_vhostuser', 'unplug_vhostuser' https://review.opendev.org/670588
20:06:09 efried ohh, okay. So you're asking if you can make a setup like that?
20:06:22 efried prometheanfire: in a single cell?
20:06:39 efried Cause I would imagine you can surely do a multi-cell that way
20:06:50 efried donnyd: do you know about this?
20:07:19 prometheanfire ya, could do it multi-cell I suppose, single cell may be nice management wise though
20:07:48 efried prometheanfire: isn't that how zuul is set up?
20:07:59 prometheanfire the main question I have is if I'll need to run non-compute stuff at each location or not (I'd rather it just be nova-compute and neutron agent type stuff)
20:08:00 donnyd well if you look at any of the big clouds out there, it would appear they try to stay away from this type of thing
20:08:01 efried running a nodepool across a dozen different locations
20:08:46 donnyd Control plane / internal stuff usually stays on the same l2//3 networks
20:08:54 efried You might have to run a cell conductor at each site. I would think your db performance would be crap if you didn't.
20:09:03 donnyd But I am not entirely sure what the ask is
20:09:56 prometheanfire how to best build a cloud that spans multiple DCs, but it still small beans (a couple hosts per location)
20:10:32 donnyd What is the plan for N/S E/W traffic... that has been my big hurdle in the past...
20:10:44 artom prometheanfire, ooooo, are you being edgy? It's all the rage these days ;
20:10:45 artom ;)
20:10:51 donnyd wanted to host my control plane in someone elses cloud, and then just have hypervisors and storage here
20:11:00 prometheanfire artom: kinda, but not quite that scale
20:12:11 prometheanfire donnyd: as far as traffic, we'll have site to sites, non-dedicated. the E/W should be minimal traffic wise (between DCs at least)
20:15:52 donnyd I don't see any reason why it cannot be done if you already have S2S connections to secure traffic.. Gonna spend quite a lot of time having fun with rabbit...
20:16:10 prometheanfire yep, I dread rabbit
20:17:46 donnyd and def be using DVR
20:18:41 prometheanfire I'm not sure we'd use more than linuxbridge and maybe gre (or just vlan)
20:18:53 prometheanfire kiss
20:20:19 donnyd The way its supposed to work is the same l2 between l3 agent and the vm
20:20:46 prometheanfire yep
20:20:51 prometheanfire that's possible
20:21:45 donnyd you would want to use DVR because the L3 agent will be over a wan connection, and all your broadcast traffic would also be doing the same
20:22:12 prometheanfire ya, that'd be rough
20:22:31 prometheanfire at least this isn't 4 years ago, dvr is better now I hear
20:23:16 prometheanfire https://wiki.openstack.org/wiki/Neutron/DVR still mentions the road to juno :D
20:23:30 prometheanfire first result when googling for 'neutron dvr'
20:25:59 donnyd I am not surprised
20:26:22 donnyd juno was only a couple releases back
20:28:20 prometheanfire feels like
20:28:31 prometheanfire 9 releases?
20:47:09 openstackgerrit Merged openstack/nova master: vif: Stop using getattr for VIF lookups https://review.opendev.org/666630
21:47:56 openstackgerrit melanie witt proposed openstack/nova master: nova-manage db archive_deleted_rows is not multi-cell aware https://review.opendev.org/507486
22:26:26 Nick_A we have snapshots set to qcow2 in nova.conf. I noticed they take 2x disk usage until uploaded to glance. Is it trying to convert qcow2 > qcow2 or something?
#openstack-nova - 2019-07-17
02:23:10 openstackgerrit Yongli He proposed openstack/nova master: Clean up orphan instances virt driver https://review.opendev.org/648912
02:23:11 openstackgerrit Yongli He proposed openstack/nova master: clean up orphan instances https://review.opendev.org/627765
03:20:40 openstackgerrit Takashi NATSUME proposed openstack/python-novaclient master: Deprecate the '--config-drive' option https://review.opendev.org/653683
03:34:35 openstackgerrit huanhongda proposed openstack/nova master: Fix for auth during live-migration (2) https://review.opendev.org/669867
04:15:55 openstackgerrit Merged openstack/nova master: vif: Resolve a TODO and update another https://review.opendev.org/666631
07:00:41 openstackgerrit huanhongda proposed openstack/nova master: Fix for auth during live-migration (2) https://review.opendev.org/669867
08:11:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: allow getting resource request of every bound ports of an instance https://review.opendev.org/655110
08:13:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Pass network API to the conducor's MigrationTask https://review.opendev.org/655111
08:15:37 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add request_spec to server move RPC calls https://review.opendev.org/655721
08:17:24 openstackgerrit Balazs Gibizer proposed openstack/nova master: re-calculate provider mapping during migration https://review.opendev.org/655112
08:19:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: update allocation in binding profile during migrate https://review.opendev.org/656422
08:21:06 openstackgerrit Balazs Gibizer proposed openstack/nova master: Extend NeutronFixture to handle migrations https://review.opendev.org/655114
08:23:02 openstackgerrit Balazs Gibizer proposed openstack/nova master: prepare func test env for moving servers with bandwidth https://review.opendev.org/655109
08:24:53 openstackgerrit Balazs Gibizer proposed openstack/nova master: func test for migrate server with ports having resource request https://review.opendev.org/655113
09:27:18 openstackgerrit Alex Xu proposed openstack/nova master: Add the virt driver interface for claim and unclaim the devices https://review.opendev.org/670782
09:27:19 openstackgerrit Alex Xu proposed openstack/nova master: Moves the allocation retrieving early https://review.opendev.org/670783
09:27:19 openstackgerrit Alex Xu proposed openstack/nova master: Calling the virt driver's claim/unclaim_for_instance in resource tracker https://review.opendev.org/670784
09:27:20 openstackgerrit Alex Xu proposed openstack/nova master: [WIP] Populate the existing mediated devices in the libvirt device manager https://review.opendev.org/670787
09:27:20 openstackgerrit Alex Xu proposed openstack/nova master: [WIP] Using the claim/unclaim_for_instance for mdevs https://review.opendev.org/671222
09:29:24 openstackgerrit Boris Bobrov proposed openstack/nova master: Provide HW_CPU_X86_AMD_SEV trait when SEV is supported https://review.opendev.org/638680
09:29:25 openstackgerrit Boris Bobrov proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
09:29:25 openstackgerrit Boris Bobrov proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334

Earlier   Later