| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-25 | |||
| 13:18:28 | efried | bauzas: agree | |
| 13:19:08 | bauzas | I was about to do this, but I wonder whether the placement folks would prefer to just use other clients | |
| 13:19:57 | efried | bauzas: All nova code should go through SchedulerReportClient to talk to Placement. | |
| 13:20:16 | efried | SchedulerReportClient should really be called PlacementClient or similar | |
| 13:20:16 | bauzas | k | |
| 13:20:46 | mriedem | right...nova doesn't have any other placement client | |
| 13:20:51 | mriedem | nor is there a python-placementclient | |
| 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 | 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:21:56 | efried | [1] https://review.opendev.org/#/c/662881/ | |
| 13:21:56 | efried | [2] https://review.opendev.org/#/c/643664/ | |
| 13:21:56 | efried | [3] https://review.opendev.org/#/c/656023/ | |
| 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 | |