Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-05
17:41:42 artom stephenfin, and it'll prevent post-copy live migration
17:41:53 sean-k-mooney that too on x86
17:41:53 stephenfin artom: how so?
17:41:57 artom See our downstream IRC chat with danpb
17:42:10 artom stephenfin, excellent question ask Dan! ;)
17:42:24 sean-k-mooney stephenfin: we could chagne it in the futre we are just suggeting skipping it for now to keep tings simple
17:42:42 artom Yep, I'd rather keep things simple for now
17:42:53 stephenfin change what now?
17:43:11 stephenfin oh, allow changing from 2M to 1G and vice versa
17:43:35 stephenfin Yeah, I wasn't suggesting we'd want to allow that for any reason other than to make it easier
17:43:44 stephenfin So if it turns out to be harder, nvm. YAGNI
17:44:24 sean-k-mooney stephenfin: well i would personally have defaulted to allowing it but if it has edgaces the lets not and maybe reasses if it chagnes
17:44:50 artom Oh, you aren't going to need it
17:45:21 sean-k-mooney stephenfin: i have personally seen a vm migrated for kernel vhost with 4k pages to ovs-dpdk with 2mb hugepages to hardware offlaoded ovs with 1G pages all via qemu
17:46:27 sean-k-mooney so qemu can do it but its to complex for what we need for numa migrations at least in v1
17:47:36 openstackgerrit Merged openstack/nova master: Duplicate os-vif datapath offload metadata https://review.openstack.org/634218
17:51:05 dansmith mriedem: I'm trying to power through this cells-down api patch
17:51:20 dansmith mriedem: I assume you realize this could be broken down into smaller patches but just figure it's not worth it?
17:51:51 dansmith the pop-all-tenants-unless-cell-down-support-then-pop-it-elsewhere thing has me thinking there's probably a lot that is easy to miss in here
17:58:09 sean-k-mooney quick dumb question. there are several image metadata keys listed in https://github.com/openstack/nova/blob/f7252b586b4b9f5a098fedfa27715b8f7e662af6/nova/notifications/objects/image.py#L187-L254 that are not document in teh glance metadefs. i should file the bug for fixing that agaisn glance right. do i need to also add nova to the bug or is glance enought
17:59:08 artom sean-k-mooney, isn't glance metadata freeform?
17:59:18 artom Ie, set any key:value you want?
17:59:47 sean-k-mooney there is a registry where all valide key:values are ment to be listed
17:59:56 sean-k-mooney https://github.com/openstack/glance/tree/master/etc/metadefs
18:00:17 sean-k-mooney it also define the flavor and volume metadata keys and how the relate
18:00:42 sean-k-mooney e.g. hw:mem_page_size in flavor is the same as hw_mem_page_size in image
18:00:59 sean-k-mooney horizon uses that to generate its ui for setting the metadata
18:01:29 artom sean-k-mooney, huh, OK, cuz I was looking at the image api-ref not long ago and got the impression you can set pretty much anything you want
18:01:48 artom Yeah: https://developer.openstack.org/api-ref/image/v2/index.html?expanded=create-image-detail#images
18:01:57 artom "Additionally, you may include additional properties specified as key:value pairs, where the value must be a string data type. Keys are limited to 255 chars in length. Available key names may be limited by the cloud’s property protection configuration."
18:02:12 artom Obviously not everything has a meaning
18:02:35 artom But you could create/update an image with kitty:yesplease if you wanted
18:02:45 sean-k-mooney artom: you can but it like os traits
18:03:13 sean-k-mooney for "standard" keys with defiend values you are not ment to extend them
18:03:59 artom Aha
18:09:39 openstackgerrit Merged openstack/nova stable/pike: Ensure rbd auth fallback uses matching credentials https://review.openstack.org/627011
18:41:51 artom sean-k-mooney, I just realized overwriting the page size in the embedded flavor has consequences on cold migration
18:41:57 artom (Among other things, I image)
18:42:18 artom So previously you'd be able to cold migrate to a different host with a different page size (as long it was still `large`)
18:42:26 artom If we overwrite, a rebuild will be required
18:43:46 openstackgerrit Jim Rollenhagen proposed openstack/nova master: ironic: partition compute services by conductor group https://review.openstack.org/635006
18:54:58 sean-k-mooney artom: right which is why it should proably be passed in the migration object
18:55:00 mriedem dansmith: yeah i noticed a few things that could be split out
18:55:11 mriedem and yeah the all_tenants stuff worries me a bit
18:55:26 mriedem since all_tenants is just a confusing mess generally to begin with
18:56:05 dansmith yeah
18:56:11 mriedem i haven't been back to it since my last deluge
18:56:30 dansmith okay she changed a bunch of stuff and uploaded this morning, modulo one noted issue
18:57:02 sean-k-mooney as i said in the ether pad/before there is no reason the new object that carries the numa mapping form the dst to the source cant be used to carry info form teh souce to dest. we are modifying the migration object to hold the new object anyway so might as well use it of the page size too
18:57:39 sean-k-mooney artom: ^ assumeing we cant just get teh value for the instance_numa_toplogy object and use that in the numa topology filter already
18:58:16 sean-k-mooney anyway im going to cook dinner ill be back in an hour or two
18:58:21 artom sean-k-mooney, bon appetit
18:58:58 mriedem dansmith: i also didn't check to see if there was a functional test that stresses the all_tenants stuff with a down cell
18:59:01 mriedem but that'd be good
18:59:31 mriedem create a server in cell A with project A, create a server in cell B with project B, take down cell B and then list servers for all tenants
18:59:44 artom And actually it may be what's happening already in NUMATopologyFilter
20:15:49 openstackgerrit Jim Rollenhagen proposed openstack/nova master: ironic: partition compute services by conductor group https://review.openstack.org/635006
20:26:18 sean-k-mooney stephenfin: mriedem care to +w https://review.openstack.org/#/c/626381/ ?
20:34:07 mriedem done
20:34:17 mriedem sean-k-mooney: are you going to work on backports?
20:34:49 sean-k-mooney for which patch
20:34:56 mriedem https://review.openstack.org/#/c/626381/
20:35:15 sean-k-mooney sure i can back port that
20:35:56 sean-k-mooney am are there upstream backports for https://review.openstack.org/#/c/614167/20
20:36:17 sean-k-mooney i will start backporting that and https://review.openstack.org/#/c/591607/25 too if not
20:37:21 sean-k-mooney haveing said that you mentioned that backporting https://review.openstack.org/#/q/topic:bug/1751923+(status:open+OR+status:merged) was contovertioal?
20:45:15 mriedem i would personally prefer to let ^ simmer a bit before we go backport crazy on it
20:45:19 mriedem because it's very non-trivial
20:45:41 mriedem is a data migration and a change in behavior in how that periodic works in the compute service
20:45:45 sean-k-mooney ok ill leave it a couple of weeks and see if anything happens
20:46:42 sean-k-mooney actully ya downstream we tend not to backport data migrations
20:47:11 sean-k-mooney ill have to think how feasible it is. ill backport my own patch then in the interim
21:13:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method https://review.openstack.org/633293
21:13:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.openstack.org/634832
21:13:01 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtDestTask https://review.openstack.org/627890
21:13:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.openstack.org/627891
21:34:29 mriedem dansmith: i left some ideas on how to split up the down cell patch
21:35:41 mriedem https://www.youtube.com/watch?v=urhJ81E-Bog
21:35:52 dansmith mriedem: okay, honestly I dunno how much I should harp on it, it's just.. really big
21:36:21 mriedem https://review.openstack.org/#/q/topic:bp/cross-cell-resize+(status:open+OR+status:merged) i'm obviously cool with splitting things up...
21:37:18 dansmith mriedem: you should bug me to look at some of those tomorrow
21:37:35 mriedem the first three are easy
21:37:43 mriedem i've got a -2 toward the bottom
21:37:52 dansmith mriedem: you should bug me to look at three of those tomorrow
21:38:01 mriedem ok
23:17:47 openstackgerrit Merged openstack/nova master: PCI: do not force remove allocated devices https://review.openstack.org/626381
23:27:07 openstackgerrit sean mooney proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
23:27:07 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
23:27:08 openstackgerrit sean mooney proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
23:27:08 openstackgerrit sean mooney proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
23:27:09 openstackgerrit sean mooney proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
23:27:09 openstackgerrit sean mooney proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
23:29:37 openstackgerrit sean mooney proposed openstack/nova stable/rocky: PCI: do not force remove allocated devices https://review.openstack.org/635071
23:29:55 openstackgerrit sean mooney proposed openstack/nova stable/queens: PCI: do not force remove allocated devices https://review.openstack.org/635072
23:38:31 openstackgerrit sean mooney proposed openstack/nova stable/pike: PCI: do not force remove allocated devices https://review.openstack.org/635074
23:38:56 openstackgerrit sean mooney proposed openstack/nova stable/ocata: PCI: do not force remove allocated devices https://review.openstack.org/635075
#openstack-nova - 2019-02-06
00:28:55 artom What takes precedence again? Flavor extra specs or image props?
00:30:09 sean-k-mooney that depends we generally now raise an exception if there is a conflict but original flavor took prescedence over image properties
00:31:15 sean-k-mooney im not sure we we have converted all conficts into exections currently but stephenfin did that for several of them
00:31:42 artom How are you still working o_O!

Earlier   Later