Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-17
15:08:22 melwitt I think the process has been, if it's a bp then it's totally nacked on stable
15:08:26 bauzas melwitt: mriedem: but honestly, the stable rules don't say 'please don't backport any feature'
15:08:28 bauzas https://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
15:09:03 bauzas apart of https://docs.openstack.org/project-team-guide/stable-branches.html#active-maintenance rule #1
15:09:19 sean-k-mooney mriedem: this was the downstream bug that i was going to fix https://bugzilla.redhat.com/show_bug.cgi?id=1714075 but to be honest i have known about this bevhaior for years and its bugged me so ill be happy to fix it
15:09:19 openstack bugzilla.redhat.com bug 1714075 in openstack-nova "[OSP13][NFV] 8 queues limit is applicable for tap device not for vhostuser port in kernel version 3." [Medium,Assigned] - Assigned to smooney
15:09:27 bauzas but in https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines we say " Proposed backports breaking any of the above guidelines can be discussed as exception requests on the openstack-discuss list (prefix with [stable]) where the stable maintenance core team will have the final say. "
15:09:48 bauzas melwitt: so, see, even with stable, you can still have exceptions
15:09:56 sean-k-mooney mriedem: i was pretty sure i had already filed a bug for vhost-user but i cnat find it in launchpad so ill file a new one as you said
15:10:20 bauzas melwitt: so I don't see a problem with you asking for an exception once you're done with master
15:11:11 mriedem "the backport guidelines don't say anything about new features...oh except this part where it says backports for new features are completely forbidden"
15:11:20 mriedem :/
15:11:43 melwitt bauzas: I don't think that's likely to fly with the stable team :P just mho
15:11:43 mriedem melwitt: just do a wishlist bug, drop the bp, write the patch and we can slit each others throats on backport policy in 3 months?
15:11:58 melwitt mriedem: lol, sounds great
15:12:10 bauzas mriedem: it tells about some possible exceptions :p
15:12:40 mriedem how about someone familiar with the new blueprint process tell me the decoder ring for what i can set for the Direction and Definition fields when approving a specless blueprint?
15:12:44 dansmith If we couldn't backport a tiny feature to mitigate spectre, I can't imagine we're going to get permission to backport something like this
15:12:45 mriedem can i mark both as "approved"?
15:13:38 melwitt I think there's an ML mail about that. /me looks
15:13:57 sean-k-mooney mriedem: i think the intent was to mark the direct as appoved after review around m2
15:14:35 sean-k-mooney but this is a small thing that i expect mel will have ready pretty quickly so i hope its merged well before that point
15:14:48 sean-k-mooney so ya you proably could mark both as approved
15:14:49 melwitt nvm, I guess it doesn't really explain it http://lists.openstack.org/pipermail/openstack-discuss/2019-October/009945.html
15:14:51 bauzas mriedem: https://specs.openstack.org/openstack/nova-specs/readme.html#the-lifecycle-of-a-specification
15:15:13 bauzas mriedem: basically, now set Definition as "approved"
15:15:45 bauzas FWIW, for "Direction", we didn't had a consensus when merging the proposal
15:16:06 bauzas so, leave it blank
15:16:12 dansmith bauzas: you might say there was no.....Direction?
15:16:14 sean-k-mooney bauzas: if the thing is merged before m2 or m3 it really does not matter
15:16:24 bauzas in theory, the PTL should set "Direction" would be used for 'important' BPs
15:16:37 mriedem if only we had a priority field...
15:16:48 melwitt lol ahhhh
15:16:51 bauzas but I disagreed on that since it wasn't explaining the process to define *which* BPs would be blessed
15:17:00 bauzas hence the use of conditional
15:17:13 mriedem Direction is binary btw, approved or not approved,
15:17:17 mriedem like you can be pregnant or not
15:17:44 dansmith kinda like this conversation can make you suicidal or not?
15:18:18 bauzas heh honestly, we shouldn't care now about those fields until someone (say efried_afk) clarifies the use
15:18:34 sean-k-mooney i was goign to ask about the inplace rebuild but im just going to write a unit test and fix my typos instead
15:18:36 bauzas I see those fields as "optional" for further usage :)
15:18:57 bauzas I was more interested honestly in the other side of the change, which is the feature liaison concept
15:31:13 gibi melwitt: my suggestion for the https://blueprints.launchpad.net/nova/+spec/nova-manage-db-purge-task-log . Do the implementation with backportability in mind. Use a bug if you want to avoid the procedural -2 on stable backport. If the bug backport will be nack-ed by the stable team then you still have a backportable fix that a distro can backport
15:31:52 melwitt gibi: makes sense, thanks
15:32:41 gibi melwitt: and I have not technical problems with the proposed change in that bp
15:32:53 gibi I mean I don't have any technical issues
15:33:02 melwitt ack, thanks
15:47:32 openstackgerrit Merged openstack/os-traits master: Add COMPUTE_NODE trait https://review.opendev.org/688969
15:56:06 mriedem gibi: on https://review.opendev.org/#/c/689049/1/nova/scheduler/client/report.py@1844 - i'm adding a new kwarg to handle the logic if the target consumer does not exist,
15:56:19 mriedem thoughts on variable names? i was thinking "target_is_new" or "reverting_allocations"
15:56:26 mriedem what makes more sense to you?
15:56:53 mriedem the former might be more obvious, the latter is maybe too tightly coupled to what is calling the method
16:03:26 efried melwitt: If it matters for backportability, make it a bug.
16:03:42 melwitt efried: thanks, I will bug it
16:03:44 efried All evidence to the contrary, I'm anti-process. I just want to get shit done.
16:04:07 efried so whatever moves the ball
16:04:24 melwitt wfm
16:07:03 bauzas efried: the only problem with any negociation on what's reasonable and what's not depends on the mandate people give you
16:07:41 bauzas efried: and I'm super afraid of us trying to decide priorities based on biaised arguments
16:07:49 efried what do you mean, mandate?
16:07:53 efried and what people?
16:08:11 efried and yes, I agree, it's tough to coordinate priorities
16:08:34 bauzas efried: I think I mixed two things
16:08:40 efried bauzas: but it's a fact that we approve more than we can hope to accomplish
16:09:07 bauzas you were mentioning the stable rules with melwitt's BP, I was thinking of the new spec process with the Direction field
16:09:39 efried and IMO it's better to cut things off, even if it's completely arbitrary (like a hard number, picked at random) than to just meander along and have no idea at the start of the release what's got a chance of merging by the end of the release.
16:09:56 efried that's what's been motivating me from day one.
16:10:02 bauzas efried: you'd probably be surprised if I was telling you I don't see a problem of having more things approved than we can't accomplish
16:10:32 efried I wouldn't say I'm surprised. The fact that nobody seems to mind is why we are where we are.
16:11:03 melwitt as a person trying to get my things done, I'd rather have some chance than no chance, but that's just MHO
16:11:22 bauzas right
16:11:42 bauzas and having some way to help contributors to understand the dynamics improve the situation
16:11:48 bauzas improves*
16:11:51 efried Mine can't be the only downstream that yells at me because "what do you mean it didn't get reviewed? The blueprint was approved!"
16:12:13 sean-k-mooney no but that has always been a thing
16:12:30 efried which is a perfect non-argument for continuing to allow it.
16:12:38 bauzas efried: that's one of the reasons why I don't want our upstream process with specs be an OKR for my management
16:12:50 efried okr?
16:12:57 dansmith efried: there are more reasons for things not getting reviewed than bandwidth or over-committing
16:12:58 bauzas objective key result
16:13:17 bauzas I mean, I don't wanna brag because my spec is approved
16:13:19 efried dansmith: understood and acknowledged in the ML Thread of Doom.
16:13:43 sean-k-mooney well my point was the bottel neck has never been writing the code. it has alwasy been reviewing it. we can reduce the scope for new feature but i know that that leads to less in vestment in openstck
16:13:55 bauzas if I were bragging, that would be because I feel we got a consensus on the design we gonna achieve for the thing I wanna implement
16:14:10 bauzas but certainly not implying that my stuff is done
16:15:07 bauzas anyway, I need to call it a day
16:15:25 bauzas things change, people become parents of kids who grown up and have social activities
16:15:30 bauzas grow*
16:15:52 bauzas and since stupidely kids under 8 can't drive, I need to AWOL
16:16:47 sean-k-mooney bauzas: dont sell your kids short. have you given the opertuity to try. what could possibly go wrong
16:16:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Delete source allocations in move_allocations if target no longer exists https://review.opendev.org/689049
16:20:16 mriedem a wild idea: more cores should do more reviews
16:20:19 mriedem *gasp*
16:20:48 mriedem https://www.stackalytics.com/report/contribution/nova/120
16:20:51 mriedem who is <1 review per day on that list?
16:22:47 efried 1/3 of the core team.
16:22:59 mriedem right,
16:23:11 mriedem so if you're a core below that threshold, stop complaining
16:23:29 efried to be fair, I don't see those cores complaining.
16:23:39 efried Actually, I think I'm the only one complaining.

Earlier   Later