| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-11 | |||
| 10:51:11 | stephenfin | Final two patches for nova-net removal | |
| 10:52:36 | stephenfin | bauzas: and if you're doing that, there's another dead easy one here https://review.opendev.org/#/c/686997/ | |
| 10:52:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Move qemu-img info calls into privsep https://review.opendev.org/706897 | |
| 10:52:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Pass request context to extend_volume https://review.opendev.org/706899 | |
| 10:52:52 | openstackgerrit | Lee Yarwood proposed openstack/nova master: images: Allow the output format of qemu-img info to be controlled https://review.opendev.org/706898 | |
| 10:52:53 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Correctly resize encrypted LUKSv1 volumes https://review.opendev.org/706900 | |
| 10:55:40 | lyarwood | sean-k-mooney: ^ removed run_as_root and made it clear that the new func is privileged | |
| 10:56:56 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM - Test TEMPEST_EXTEND_ATTACHED_ENCRYPTED_VOLUME https://review.opendev.org/707593 | |
| 10:58:22 | bauzas | stephenfin: will try | |
| 11:11:06 | openstackgerrit | Brin Zhang proposed openstack/nova master: Add new default roles in os-instance-actions policies https://review.opendev.org/706470 | |
| 11:56:42 | sean-k-mooney | lyarwood: yep reviewing your series now | |
| 11:56:59 | sean-k-mooney | and ya its clearer what you are doing | |
| 12:02:14 | lyarwood | sean-k-mooney: ack thanks | |
| 12:11:26 | lyarwood | stephenfin: ^ when you have time later could you hit https://review.opendev.org/#/q/topic:bug/1861071 again, I'll rebase the followups once this lands now to avoid extra churn in the gate. | |
| 12:12:02 | stephenfin | sure. ping me again if I don't have it done by EOD :) | |
| 12:12:23 | lyarwood | sure thing | |
| 12:12:33 | lyarwood | and thanks obviously :) | |
| 12:19:27 | sean-k-mooney | lyarwood: i think i reviewed them all | |
| 12:19:46 | sean-k-mooney | it looks like the chain is broken into 3 seriese so they shoudl all be rebased back into one | |
| 12:20:30 | sean-k-mooney | or at least be rebased so they are update with the bottom 4 patches | |
| 12:30:23 | lyarwood | sean-k-mooney: yup, I'll rebase the rest later today, just switching to something else for a whil.e | |
| 12:46:39 | brinzhang | johnthetubaguy: https://review.opendev.org/#/c/706470/ I used your suggestion, that looks like ok for me, I was update that you can review again if you have time ^^ | |
| 12:48:20 | brinzhang | gmann: you can review this patch, and move the problem from your list I asked before | |
| 13:06:38 | luyao | gibi: are you around? | |
| 13:07:10 | openstackgerrit | Brin Zhang proposed openstack/nova master: Granular GET os-instance-actions API policies https://review.opendev.org/711791 | |
| 13:07:14 | gibi | luyao: hi! | |
| 13:08:07 | luyao | gibi: Would you like review the vpmem live migration support? I need someone help me confirm if the implementations is OK. :D | |
| 13:08:30 | luyao | https://review.opendev.org/#/q/topic:support-live-migration-with-virtual-persistent-memory+(status:open+OR+status:merged) | |
| 13:08:59 | gibi | luyao: sure. I can try. I have to finish the review of the cyborg integration first but then I can look at your series | |
| 13:11:42 | luyao | gibi: Thank you. looking forward for your comments. FYI. I don't add enough testcases now, if the implementation is acceptable, I'll do that. | |
| 13:12:12 | gibi | luyao: OK, I will keep that in mind | |
| 13:12:42 | brinzhang | luyao: I will tyr to check your patch tomorrow ^^ | |
| 13:13:12 | luyao | brinzhang: Thanks, welcome. :D | |
| 13:13:37 | brinzhang | luyao: I already add that to me review list, and will do later | |
| 13:14:40 | brinzhang | We would like this feature | |
| 13:16:13 | luyao | brinzhang: Great. | |
| 13:26:17 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: [Community goal] Update contributor documentation https://review.opendev.org/712420 | |
| 13:27:20 | gibi | stephenfin: ussuri community goal doc change ^^ | |
| 13:27:30 | gibi | stephenfin: I feel you will have comments about it | |
| 13:53:13 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Pass allocations to virt drivers when reverting resize https://review.opendev.org/712118 | |
| 14:16:55 | dansmith | gibi: thoughts on the vmware deprecation patch? I'm glad it got some attention raised, but we've been a long time without vmware ci and despite some response, I feel like we probably need a deadline or something to make sure something happens | |
| 14:17:50 | dansmith | I'm not even sure when the last time the vmware ci commented on a nova change, but I feel like it's been a *long* time | |
| 14:23:58 | sean-k-mooney | dansmith: we could merge the patch propose a revert and hold it until m3. if the ci is running by m3 we merge the revert if not then leave it | |
| 14:24:31 | dansmith | yep, we could also convert this to just a quality warning, merge that now, and hold the deprecation warning on the ci | |
| 14:24:35 | dansmith | which i think is what we did for xen | |
| 14:25:47 | gmann | brinzhang: i will check after coffee. | |
| 14:26:10 | brinzhang | gmann: cool, thanks | |
| 14:30:22 | mriedem | we merged the deprecation warning for xen in train, it wasn't contingent | |
| 14:33:36 | dansmith | okay when I was looking for examples, I found a "merge quality warning" for one of the drivers before a deprecation | |
| 14:33:46 | gibi | dansmith: we can merge a deprecation warning without causing extra problem to hemna and undeprecate if vmware ci magicly shows up | |
| 14:33:47 | mriedem | looks like dan's patch has at least gotten the necessary attention, | |
| 14:33:53 | mriedem | whether that holds or not i guess we'll see | |
| 14:34:15 | dansmith | gibi: ack, well, that's what I've got up, so maybe go vote on that :) | |
| 14:34:16 | gibi | the real break happens if we delete something | |
| 14:34:25 | gibi | dansmith: will do | |
| 14:34:32 | mriedem | yeah the people -1ing the change are saying "please don't delete it" | |
| 14:34:35 | mriedem | which isn't what the patch does | |
| 14:34:52 | dansmith | there has still been no progress in finding a maintainer for" | |
| 14:34:52 | dansmith | mriedem: I quote you: " After three months since the quality warning change merged [1] | |
| 14:34:55 | mriedem | they can -1 the patch to remove the driver in a later release if it gets to that point | |
| 14:35:19 | dansmith | https://github.com/openstack/nova/commit/af280ffe3098b84123eae218989ea056e9935bf1 | |
| 14:35:47 | mriedem | good thing i was so verbose in my commit messages :) | |
| 14:35:47 | dansmith | but I'd rather go straight to deprecation, | |
| 14:36:06 | dansmith | and then we can avoid removing it if CI shows up, and un-deprecate if it looks like CI will stick around | |
| 14:36:18 | mriedem | i think there is more than enough ammo for vmware deprecation based on repeated attempts in the ML to figure out what's going on with CI over the last several years, | |
| 14:36:58 | dansmith | agree, and like I said, I'd be kinda surprised if it really works in U after all the provider stuff | |
| 14:37:06 | dansmith | working in queens I totally believe | |
| 14:37:58 | jkulik | fyi, we (SAP) reached out to VMware to get a statement on their upstream approach. they weren't ready for one, yet. | |
| 14:38:05 | mriedem | i forget her name but i was sending emails about the lack of CI back when the old project manager was involved | |
| 14:38:10 | dansmith | IMHO, to keep it we need more than just CI too.. we need support for devstack problems, like the one referenced on the mailing list and general confidence that it's working for more than just trivial CI configurations | |
| 14:38:42 | mriedem | jkulik: as far as i know vmware hasn't had an "upstream" team in awhile | |
| 14:38:49 | mriedem | cdent was the last closest person to that for nova at least | |
| 14:39:01 | dansmith | and honestly, it has always been a fight to keep them involved, which is pretty exhausting | |
| 14:39:33 | mriedem | i'm sure that team would say it was exhausting dealing with us as well :) | |
| 14:39:45 | mriedem | "what do you mean my bug fix needs tests?!" | |
| 14:41:39 | jkulik | as far as I heard: yes, they found it exhausting. | |
| 14:41:48 | mriedem | heh | |
| 14:41:57 | dansmith | yeah I have no doubt | |
| 14:42:03 | mriedem | i mean, quality control, who needs it | |
| 14:42:04 | mriedem | psh | |
| 14:42:17 | jkulik | main problem seems to be, that they have their own product based on openstack which works fine for them | |
| 14:42:36 | mriedem | VIO | |
| 14:42:39 | mriedem | right? | |
| 14:42:40 | jkulik | yes | |
| 14:42:45 | mriedem | sure, with patches | |
| 14:42:46 | dansmith | and that's cool, but we don't need to keep a broken driver in our tree, especially with people asking on the ML why it doesn't work | |
| 14:42:53 | mriedem | so you buy that thing and you're stuck with them for support b/c of the patches | |
| 14:43:06 | jkulik | sure, they need to make money off it | |
| 14:43:12 | jkulik | otherwise everybody could just install openstack ;) | |
| 14:43:40 | sean-k-mooney | jkulik: our they could enforce an upstream first poicy for all freatres and backports | |
| 14:43:47 | sean-k-mooney | *or | |
| 14:43:57 | jkulik | which they obviously still make money from, because you'd still have VMware hypervisors and stuff | |
| 14:44:17 | jkulik | tbh, upstream first is hard. | |
| 14:44:50 | sean-k-mooney | it can be but its generally worth it. i thnik the quality of the final solution is typically better | |
| 14:45:24 | sean-k-mooney | but it is a higher barrier to entry for enableing a feature | |
| 14:45:26 | jkulik | I agree. But some things you can't upstream and once you're down that road, you're not that willing to upstream the rest. | |
| 14:45:29 | mriedem | depends on where you want to invest time and money, up front or on the backside dealing with maintaining a fork | |
| 14:46:28 | dansmith | jkulik: we're not arguing that they shouldn't have a downstream.. we're arguing that if they want their base in the upstream, there's a minimum bar and we're not going to do their maintenance for free, that's all | |
| 14:46:29 | mriedem | and getting the team culture in place for people that aren't used to having their code reviewed | |
| 14:46:29 | dansmith | we all make money from openstack one way or the other, nobody here doesn't recognize that | |