| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-25 | |||
| 12:57:27 | artom|gmtplus3 | I'll let sean-k-mooney respond | |
| 13:03:26 | sean-k-mooney | artom|gmtplus3: well i dont know why we would recive plug time event for same host resize of hybrid plug | |
| 13:03:39 | sean-k-mooney | the vif is already plugged and the binding host does not change | |
| 13:03:45 | artom|gmtplus3 | sean-k-mooney, I don't either, but it looks like we do | |
| 13:06:08 | sean-k-mooney | for what its worth the patch i have up passed the same host reszie test in tempest | |
| 13:06:31 | mriedem | mgoddard: johnthetubaguy: i have a few questions in https://bugs.launchpad.net/nova/+bug/1833542 for what you want to see | |
| 13:06:32 | openstack | Launchpad bug 1833542 in OpenStack Compute (nova) "No mechanism to wait for computes to update service version before restarting to remove RPC version cap after upgrade" [Wishlist,Triaged] | |
| 13:06:32 | sean-k-mooney | it was tested by the neutron iptables hybird job | |
| 13:06:50 | mgoddard | mriedem: fire away | |
| 13:06:53 | sean-k-mooney | i have not had time to go through your comment properly and read the logs however | |
| 13:08:13 | artom|gmtplus3 | sean-k-mooney, it would, because I think it just don't wait for any events in case of same host resize | |
| 13:08:51 | sean-k-mooney | right it wont be considerd a plug time event so we wont wait | |
| 13:09:07 | sean-k-mooney | we would wait for plug time events | |
| 13:09:44 | mriedem | mgoddard: they are in the bug report, answer when you have time | |
| 13:09:55 | mriedem | mgoddard: mostly asking about what interface you need | |
| 13:10:00 | artom|gmtplus3 | sean-k-mooney, in fact, I don't think tests would pick it up at all - even migrate revert guest connectivity tests would succeed eventually, assuming everything went well | |
| 13:10:32 | artom|gmtplus3 | There'd just be a few seconds (dozens of seconds?) between instance boot and network connectivity being established | |
| 13:11:25 | mgoddard | mriedem: ah, got it. Have to head out soon but will respond | |
| 13:12:31 | mriedem | mgoddard: feel free to post to the ML for other ops to weigh in if they need something like this | |
| 13:16:45 | bauzas | mriedem: efried: I'm working on https://bugs.launchpad.net/nova/+bug/1793569 | |
| 13:16:47 | openstack | Launchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,Confirmed] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:17:30 | bauzas | mriedem: efried: should we use the reportclient or just calling the placement API directly? | |
| 13:17:51 | efried | bauzas: looking... | |
| 13:17:53 | mriedem | i'm pretty sure the other nova-manage placement commands use the reportclient | |
| 13:17:58 | bauzas | they do, yet | |
| 13:18:02 | bauzas | yes* | |
| 13:18:08 | mriedem | so yeah just use that | |
| 13:18:12 | bauzas | ok | |
| 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 | bauzas | k | |
| 13:20:16 | efried | SchedulerReportClient should really be called PlacementClient or similar | |
| 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 | [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 | |