| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-25 | |||
| 13:20:57 | mriedem | only the sdk | |
| 13:21:28 | mriedem | keep in mind that if this is something you think your customers on older branches might want, you're best to not introduce a bunch of new dependencies here | |
| 13:21:51 | mriedem | unrelated, doesn't suse and red hat have docs writers that could verify the install guide issue mentioned here https://bugs.launchpad.net/nova/+bug/1833650 ? | |
| 13:21:52 | openstack | Launchpad bug 1833650 in OpenStack Compute (nova) "Populate nova databases failed with mysql access denied" [Undecided,New] - Assigned to Chason Chan (chen-xing) | |
| 13:21:56 | efried | [3] https://review.opendev.org/#/c/656023/ | |
| 13:21:56 | efried | [2] https://review.opendev.org/#/c/643664/ | |
| 13:21:56 | efried | [1] https://review.opendev.org/#/c/662881/ | |
| 13:21:56 | efried | Note that as soon as this [1] is approved, we can merge this [2] and this [3], and then we'll be using openstacksdk for placement -- but still via the SchedulerReportClient. | |
| 13:26:42 | yonglihe | mriedem, Hi, good morning. | |
| 13:27:35 | mriedem | alex_xu: john hou has a major problem with your patch :) https://review.opendev.org/#/c/667061/ | |
| 13:27:40 | mriedem | so major in fact he -1ed without a comment | |
| 13:27:46 | mriedem | yonglihe: hi | |
| 13:28:16 | artom|gmtplus3 | mriedem, I suspect ours only have ooo-related deployment docs | |
| 13:28:41 | lyarwood | yup was just about to say, manual steps would be out of scope for them. Should be something we (devel) can help with however. | |
| 13:30:34 | lyarwood | I've asked our deployment folks to take a look | |
| 13:31:58 | mriedem | i thought i heard at one of the last face to face things that red hat had a docs writer working on cinder upstream so that's where i got the idea | |
| 13:32:19 | mriedem | smcginnis might have just been making it all up | |
| 13:33:00 | smcginnis | Lies, all lies. | |
| 13:33:43 | smcginnis | mriedem: There was someone at the Vancouver Forum that said he was new there and had a whole team that was going to be switching focus to be more upstream on docs. Never saw anything come of that though. | |
| 13:34:06 | mriedem | ok that's about the level of expectation i'd have... | |
| 13:34:08 | openstackgerrit | Merged openstack/nova master: doc: Fix nova-manage cell_v2 list_cells output https://review.opendev.org/666995 | |
| 13:35:06 | lyarwood | yeah I think there is a push to upstream more of their stuff but even then, if we don't support it downstream I can't see them working on it upstream. | |
| 13:35:31 | lyarwood | stephenfin knows more about the docs team tbh | |
| 13:35:39 | mriedem | red hat doesn't support installing nova on control nodes? | |
| 13:35:46 | lyarwood | not manually no | |
| 13:35:49 | artom|gmtplus3 | Docs is... touchy? IIUC the argument for *not* upstreaming docs more is that docs is part of the added value that a RH sub brings | |
| 13:35:52 | mriedem | oh gotcha | |
| 13:36:01 | artom|gmtplus3 | But yeah, stephenfin's your man | |
| 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 | |