| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-25 | |||
| 13:36:43 | mriedem | yeah that's fine, i'm just looking for someone with time to validate the bug and the fix but it seems correct | |
| 13:37:01 | yonglihe | need another +2 to move forward https://review.opendev.org/#/c/658716/ | |
| 13:37:23 | mriedem | yonglihe: if you're asking me for ^ that's not really my area | |
| 13:37:29 | sean-k-mooney | mriedem: redhat requires OSP to be installed via osp director(triplo) for it to be supported form OSP13 (queens) on | |
| 13:37:34 | efried | yonglihe: I was hoping johnthetubaguy would be able to look at that one. | |
| 13:37:45 | mriedem | efried: yonglihe: and i was hoping sean would ack or nack it | |
| 13:38:17 | efried | mriedem_afk: The delta since sean-k-mooney's last +1 is negligible, I'm assuming he's still +1. | |
| 13:38:31 | yonglihe | mriedem: that's ok. Sean already given a +1. we discussed that and got concern resolved. | |
| 13:38:41 | sean-k-mooney | efried: on which ? | |
| 13:38:52 | efried | https://review.opendev.org/#/c/658716/ | |
| 13:38:56 | sean-k-mooney | oh the show numa stuff | |
| 13:39:43 | yonglihe | sean-k-mooney: i do got your +1, and alex's comment, while i address that. i got +2 from alex. | |
| 13:39:49 | sean-k-mooney | ya it still has one nit but im fine with it | |
| 13:40:08 | artom|gmtplus3 | yonglihe, efried, it's missing the Train history bit | |
| 13:40:15 | artom|gmtplus3 | (I realize this is the epitome of late nitpicking) | |
| 13:40:25 | sean-k-mooney | "pagesize_kb": 4096, shoudl still be 4 if they inteded it to be the defaul 4k pages | |
| 13:40:40 | artom|gmtplus3 | (It's jut that I thought it looked familiar, and scrolled down to history immediately) | |
| 13:41:12 | yonglihe | sean-k-mooney: your are right. i can fix it. | |
| 13:41:24 | sean-k-mooney | i dont think its worth anothr respin | |
| 13:41:52 | sean-k-mooney | it can be fixed but alex has +2'd and its not really that important | |
| 13:42:01 | sean-k-mooney | provide we do it correctly in the code | |
| 13:42:08 | yonglihe | artom: it's reopen from S to D, so lost some history. | |
| 13:42:23 | yonglihe | S to T | |
| 13:42:29 | sean-k-mooney | so im happy to leave that as an implemenatin detail and assume you ment 4MB pages for the spec :) | |
| 13:42:36 | artom|gmtplus3 | yonglihe, yeah, no need to respin just for that, you have a +2 already | |
| 13:42:54 | efried | Normally I would probably feel fine proxying sean-k-mooney's vote as a +2, but that would be three Intels on paper, so I'd rather wait for another core. | |
| 13:44:04 | yonglihe | sean-k-mooney: sure. efried: yeah, i also think so. | |
| 13:45:09 | sean-k-mooney | johnthetubaguy: you previously were ok with https://review.opendev.org/#/c/658716/5 feel like being the final +2+w ? | |
| 13:46:10 | yonglihe | another patch 'clean up orphan instances' , https://review.opendev.org/#/c/627765/. From S to T, not got enough core force ever, is that patch so mass or mess ? It's lots of detail stuff, though. | |
| 13:47:36 | Conqueror | Hello everybody, I want to move VM from one project to another. How can I do that? I was googling and found the using nova-image download and nova-image create commands.. But, there should be an easier way to do this... | |
| 13:47:52 | dansmith | sean-k-mooney: I'll take a look at this | |
| 13:48:27 | sean-k-mooney | dansmith: you will love it amost as much as jay would | |
| 13:49:37 | dansmith | Conqueror: there's not | |
| 13:49:53 | dansmith | Conqueror: you can try this, but it's just a POC. Worked at some point, but buyer beware: https://github.com/kk7ds/oschown | |
| 13:50:41 | sean-k-mooney | oh speaking of ^ we were ment to propose moving that to openstack/oschown at somepoint | |
| 13:50:53 | yonglihe | dansmith, sean-k-mooney: thanks. | |
| 13:51:16 | sean-k-mooney | and then moving each module into the indeivgual projects and importing it via stevador | |
| 13:51:54 | sean-k-mooney | i wonder if we ever opensed a bug/blueprint or somthing to track that so we dont have the same converstaion next time | |
| 13:57:27 | Conqueror | dansmith, wow this looks very good :) | |
| 13:57:37 | dansmith | Conqueror: trust me, it's not :) | |
| 13:57:49 | Conqueror | dansmith, :D | |
| 14:08:59 | efried | dansmith: on a resize, does the 'flavor' arg to migrate_disk_and_power_off represent the new size? | |
| 14:09:23 | efried | ...and the old size can be had via instance.flavor? | |
| 14:18:21 | openstackgerrit | Merged openstack/nova-specs master: add spec "show-server-numa-topology" https://review.opendev.org/658716 | |
| 14:19:16 | dansmith | efried: argument, probably, but I'd have to look.. efried instance has an old_flavor and new_flavor property during resize | |
| 14:19:53 | efried | dansmith: Based on what the libvirt driver is doing with it, it looks like instance.flavor is the old one and flavor is the new one. | |
| 14:19:54 | efried | thanks | |
| 14:20:23 | dansmith | efried: instance.flavor doesn't change until it changes I think, but old_flavor and new_flavor should be set | |
| 14:20:36 | efried | cool | |
| 14:20:48 | mriedem | migrate_disk_and_power_off happens in resize_instance on the source, right? | |
| 14:20:53 | efried | yes | |
| 14:20:59 | mriedem | pretty sure that code flips the instance.flavor to new_flavor before calling the driver | |
| 14:21:12 | mriedem | i have this code mostly memorized by now | |
| 14:21:22 | dansmith | I thought it was after poweroff | |
| 14:21:42 | efried | I don't actually need to know the details right now; just wanted to make sure both flavors are available in some form to the virt driver at the early stage of the resize. See ML. | |
| 14:21:58 | mriedem | oh i was thinking of this https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4686 | |
| 14:22:08 | mriedem | we do'nt update the instance.flavor to the new flavor until finish_resize on the dest | |
| 14:22:19 | dansmith | yeah, that's what I thought | |
| 14:22:29 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4550 | |
| 14:22:33 | mriedem | instance_type in that case is the new flavor | |
| 14:22:36 | mriedem | instance.flavor is still the old flavor | |
| 14:22:55 | efried | tldr: ironic could theoretically implement a super-restricted same-node-only 'resize' to twiddle tunables in their deploy template. | |
| 14:22:58 | mriedem | and instance.new_flavor is set before that https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4338 | |
| 14:23:43 | mriedem | well you don't even need the flavor to determine if it's the same host | |
| 14:23:53 | mriedem | we pass in the dest host, so you'd just check if dest_host == CONF.host | |
| 14:24:11 | mriedem | that doesn't tell you it's the same node... | |
| 14:24:47 | efried | okay, but they also need to be able to make sure that nothing has changed outside the limited subset of allowable changes | |
| 14:24:51 | efried | swhy they would need the flavors | |
| 14:25:41 | efried | but yeah, also some way to know it's same-node. Maybe that part wouldn't be wrong to do in the cond/api | |
| 14:25:45 | mriedem | so...gonna plumb this all up through the api and everything just to eventually have the ironic driver check if the only thing changing in the new flavor is the deploy template and fail if not? | |
| 14:26:00 | efried | well, except the plumbing is already there, no? | |
| 14:26:13 | efried | basically all they have to do is implement two virt driver methods to make it work the dumb way | |
| 14:26:15 | mriedem | i wouldn't assume so | |
| 14:26:17 | efried | and yeah, late fail | |
| 14:26:31 | efried | but that's no different than e.g. libvirt failing if you try to downsize the eph disk | |
| 14:26:44 | mriedem | the api / controller is pretty opinionated that during a move operation the host:node relationship is 1:1 b/c we don't support moving baremetal instances | |
| 14:27:01 | mriedem | and you've got the CONF.allow_resize_to_same_host issues | |
| 14:27:22 | mnaser | eh, it looks like there is no nested virt trait eh? | |
| 14:27:43 | mriedem | which reminds me of https://bugs.launchpad.net/nova/+bug/1819216 but that's for cold migration | |
| 14:27:44 | openstack | Launchpad bug 1819216 in OpenStack Compute (nova) "in devstack, "nova migrate <uuid>" will try to migrate to the same host (and then fail)" [Medium,Triaged] | |
| 14:27:52 | efried | mnaser: wha? | |
| 14:28:15 | mnaser | not all of our hypervisors have been updated to have nested virt enabled (its disabled by default on rhel based hosts) | |
| 14:28:26 | mnaser | so i was hoping to create a flavor for a user so they always got a machine that had nested virt | |
| 14:28:35 | mnaser | (rather than building a host aggregate and trying to keep it sync'd) | |
| 14:30:30 | mriedem | does HW_CPU_X86_VMX only show up on your nested virt enabled hosts? | |
| 14:30:44 | efried | sorry, this isn't going to be very helpful, but what does "nested virt" mean? | |
| 14:31:00 | mnaser | efried: oh sorry, it means enabling an option in kvm to expose the vmx flag to the virtual machine | |
| 14:31:11 | mnaser | so that it can start up kvm accelerated vms (instead of qemu emulated ones) | |
| 14:31:13 | kashyap | efried: It means you're running on "turtles all the way down" | |
| 14:31:30 | kashyap | It's only a part troll; as the original nested virt paper was titled that way | |
| 14:31:34 | mnaser | HW_CPU_X86_VMX will probably always be exposed on the host i assume (though libvirt can give you the answer if its enabled or not) | |
| 14:31:37 | dansmith | efried: it means... if random() % 10 < 4, segfault() | |
| 14:31:43 | kashyap | https://www.usenix.org/legacy/events/osdi10/tech/slides/ben-yehuda.pdf | |
| 14:31:47 | mnaser | lolol | |
| 14:32:04 | kashyap | Sorry, here's the paper: "The Turtles Project": https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Ben-Yehuda.pdf | |
| 14:32:06 | artom|gmtplus3 | mnaser, are flavors with more than 1 NUMA node also in the pipeline? | |
| 14:32:12 | mnaser | it's actually been pretty stable in kata's ci (in our nested virt hosts) and doing nested virt on newer kernels is pretty well | |
| 14:32:18 | mnaser | artom|gmtplus3: in this case, no | |
| 14:32:36 | mnaser | but we've looked into it in the past :> | |
| 14:32:54 | mnaser | but yeah, im gonna guess HW_CPU_X86_VMX is probably exposed in all kvm hosts | |