| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-05 | |||
| 17:36:44 | artom | Just as a separate thing | |
| 17:36:45 | sean-k-mooney | yes | |
| 17:37:13 | artom | I'll propose that and it'll solve all evarything | |
| 17:37:48 | artom | Maybe lunch first tho | |
| 17:38:54 | sean-k-mooney | updating the embed flavor could work but today we dont know the pagesize untill we hit the compute node | |
| 17:39:06 | sean-k-mooney | so it would have to be updated there | |
| 17:39:52 | artom | Don't see why it can't be done, objects are remotable for precisely this kind of thing | |
| 17:40:29 | stephenfin | why is 1GB -> 2MB a bad thing? | |
| 17:40:37 | sean-k-mooney | artom: well im more thingink we shoudl not update it unless the instance actully boots so that retry dont break | |
| 17:40:41 | stephenfin | If they want 1GB, they can specifically request it, no? | |
| 17:40:48 | sean-k-mooney | stephenfin: they can | |
| 17:41:01 | artom | sean-k-mooney, yeah, it'd be way at the end of the boot code path | |
| 17:41:11 | stephenfin | So they don't care and want just "huge pages", so give em whatever is available? | |
| 17:41:12 | artom | I'll take a closer look to find the best place/way | |
| 17:41:14 | sean-k-mooney | stephenfin: apparently while on x86 cahnging pagesize even form 4k is fine | |
| 17:41:27 | sean-k-mooney | stephenfin: on arm or other achiteture its not supported | |
| 17:41:37 | stephenfin | You mean via QEMU? | |
| 17:41:40 | sean-k-mooney | yes | |
| 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 | |