| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-26 | |||
| 14:53:17 | donnyd | or even 12 month | |
| 14:53:23 | mriedem | blech | |
| 14:53:33 | mriedem | we'll just wait until the last minute to cram even less stuff in :) | |
| 14:53:55 | mriedem | and, | |
| 14:54:06 | mriedem | it will be double the shit that someone has to consumer and grok from the release notes when they do | |
| 14:54:12 | mriedem | *consume | |
| 14:54:48 | donnyd | how is that different from say an ubuntu or centos release though? | |
| 14:55:19 | donnyd | centos/rhel | |
| 14:56:08 | donnyd | Also thank you for replying | |
| 14:56:28 | mriedem | i can't say how those distro dev cycles are different, | |
| 14:56:33 | mriedem | but i imagine there much more strictly controlled | |
| 14:56:36 | mriedem | *they're | |
| 14:57:18 | mriedem | and when rhel i'm paying a support license so i expect more rigor before the thing is released than just "here it is, here are the release notes, have fun" | |
| 14:57:21 | mriedem | *with rhel | |
| 14:57:23 | mriedem | man i can't type today | |
| 14:58:22 | mriedem | i'm also not sure how moving from 6 to 12 months cycles would go over with someone like vexxhost that does actually do proper CI/CD and doesn't wait 18 months before upgrading | |
| 14:58:39 | mriedem | kashyap: sure, whatever - "pay for play" | |
| 14:59:05 | kashyap | I need to first load up on the topic being discussed. (I've got the -discuss list open, with Donny's email) | |
| 15:00:56 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Handle legacy request spec dict in ComputeTaskManager._cold_migrate https://review.opendev.org/684407 | |
| 15:01:54 | kashyap | donnyd: That's indeed a barrel of worms; it was discussed to nauseating levels. See this epic thread from 2015: | |
| 15:02:05 | kashyap | donnyd: "Re-evaluating the suitability of the 6 month release cycle" -- https://openstack.nimeyo.com/34284/openstack-dev-evaluating-suitability-month-release-cycle | |
| 15:02:17 | kashyap | donnyd: Before you click that, go fill up your giant mug of tea, I say. | |
| 15:02:20 | donnyd | mriedem: but vexxhost could surely make use of more often . releases | |
| 15:02:34 | kashyap | It's a long and worthwhile read. (Especially "looking back") | |
| 15:03:10 | donnyd | well to be fair... that was 4 years ago | |
| 15:03:36 | kashyap | donnyd: To get the tl;dr of suggestion, see "The modest proposal" | |
| 15:03:42 | kashyap | [quote] | |
| 15:03:43 | kashyap | Based on these observations I would suggest that OpenStack aim to | |
| 15:03:44 | kashyap | switch to a development cycle that is exactly 2 months long. | |
| 15:03:44 | kashyap | ie do 6 releases a year. | |
| 15:03:44 | kashyap | This will have a number of consequences which I'd expect to be | |
| 15:03:46 | kashyap | beneficial to the project on balance. | |
| 15:03:48 | kashyap | [/quote] | |
| 15:04:29 | kashyap | donnyd: 4 years ago, but many things wrote there apply perfectly well today. | |
| 15:06:19 | donnyd | but 4 years ago our community was probably 2x the size it is now wasn't it? (i wasn't here, so i can't actually quantify that) | |
| 15:06:32 | mriedem | lyarwood: we have a few open stable/stein changes that we could get in before the next release but i think the biggest ticket one ends at https://review.opendev.org/#/c/684407/ since that resolves an upgrade issue introduced in stien | |
| 15:06:35 | mriedem | dansmith: ^ | |
| 15:07:03 | mriedem | donnyd: yes much bigger and much more diverse | |
| 15:07:04 | kashyap | donnyd: It _was_ larger; but shortening the cycle length applies even today. | |
| 15:07:27 | kashyap | donnyd: It reduces the: "hey, our distro is gonna be based on X upstream release, we _must_ shove our feature upstream in time!" | |
| 15:07:41 | kashyap | s/distro/"long-term OpenStack distro"/ | |
| 15:07:54 | kashyap | (Among other things) | |
| 15:08:24 | donnyd | for the record.. I am happy either way | |
| 15:13:22 | kashyap | donnyd: Nod; but yes, as both of you said, it's the "human nature" element. And "planning is guessing". Go a "six-month plan"? Call it a "six-month guess". | |
| 15:13:25 | kashyap | (https://m.signalvnoise.com/planning-is-guessing/) | |
| 15:14:51 | donnyd | right... "everyone has a plan until they get punched in the mouth" | |
| 15:14:57 | donnyd | - mike tyson | |
| 15:15:48 | donnyd | so wouldn't the message there be create smaller plans?? | |
| 15:16:19 | openstackgerrit | Walter A. Boring IV (hemna) proposed openstack/nova stable/pike: WIP: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008 | |
| 15:17:29 | mriedem | donnyd: i think that's efried's plan for ussuri | |
| 15:17:44 | mriedem | i.e. only approve blueprints for things that were previously approved and not yet complete | |
| 15:18:08 | kashyap | donnyd: Yeah, smaller plans are fine - focus more on the unsexy, "boring" stability (don't-fall-apart-if-you-sneeze) and less of "features" | |
| 15:18:43 | kashyap | s/fine/preferred/ (ha, see what I did there :D) | |
| 15:21:58 | kashyap | donnyd: Fun fact I just learnt: Tyson actually _lost_ that match, after that quote (which he targeted at his oponnent, when a journalist asked "if you're worried about his plan") :D | |
| 15:22:00 | donnyd | Well the cycle time would just be broken up differently.. I wouldn't think the major release cycle time would be able to be shortened... if anything lengthened .... So the idea is kinda like slow train fast train | |
| 15:22:05 | kashyap | (So the plan _did_ work :D) | |
| 15:22:29 | donnyd | kashyap: LOL | |
| 15:23:14 | kashyap | donnyd: So, yeah, moral: "punchy quotes don't cook rice [or sustain punches / win matches]" | |
| 15:23:25 | donnyd | So if someone wanted to ride the fast train, they would just use the minor release cycle and those who want that "LTSish" release could just use majors | |
| 15:25:34 | donnyd | I am still reading the thread from 2015 | |
| 15:38:49 | efried | gibi: you still around? | |
| 15:38:58 | gibi | efried: yes | |
| 15:39:35 | efried | gibi: would you mind injecting some more description into the commit message and test comments/docstring for https://review.opendev.org/#/c/684545/ ? | |
| 15:39:54 | efried | As it is I have to go read the bug report to understand what's going on. | |
| 15:40:32 | gibi | efried: you mean describe the bug a bit more in the commit message and the docstring? | |
| 15:41:05 | efried | Yeah. Actually the commit message is probably fine; I just misread it. But in the test case, an up-front docstring/comment describing what we're testing for would be nice. | |
| 15:41:15 | gibi | efried: sure | |
| 15:41:44 | efried | you could do it in a fup if you prefer, I can send both of these. | |
| 15:42:06 | gibi | efried: let me add that info quickly to the func reproduce patch | |
| 15:42:10 | gibi | before I leave | |
| 15:45:52 | efried | gibi: is there a typo in the test name? (just posted comments) | |
| 15:46:10 | dansmith | mriedem: on this: https://review.opendev.org/#/c/684407/3 | |
| 15:46:30 | dansmith | mriedem: is that really necessary for stein, which should all be sending a later compute rpc version | |
| 15:46:33 | dansmith | ? | |
| 15:47:30 | dansmith | okay, so there's some conductor interplay there, I guess, but.. the point in backporting to stein is for what, to make stein better handle upgrade scenarios when running split rocky/stein ? | |
| 15:47:32 | mriedem | i'm not sure what you mean. | |
| 15:47:37 | mriedem | yes | |
| 15:47:43 | mriedem | if you're computes are pinned to rocky it's a failure | |
| 15:47:46 | mriedem | *your | |
| 15:48:00 | mriedem | on resize/cold migrate reschedule i mean | |
| 15:48:27 | mriedem | compute will pass a request spec legacy dict back up to conductor which won't handle it as a dict and blow up trying to set the flavor attribute | |
| 15:49:21 | gibi | efried: ack | |
| 15:49:37 | dansmith | mriedem: but case #2 in your commit message wouldn't affect rocky/stein because it requires pinning to 5.0 which is older than even rocky, right? | |
| 15:50:24 | dansmith | I mean, it could if people had their rpcs pinned to pike, but in reality, that's probably not a likely case | |
| 15:54:02 | mriedem | no, | |
| 15:54:05 | mriedem | 5.0 is rocky | |
| 15:54:19 | mriedem | 5.1 was i think the only compute rpc api bump in stein | |
| 15:54:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Functional reproduction for bug 1845291 https://review.opendev.org/684545 | |
| 15:54:29 | openstack | bug 1845291 in OpenStack Compute (nova) "migration is not recheduled if the server originally booted with --availability-zone |
|
| 15:54:29 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reset forced_destination before migration at a proper time https://review.opendev.org/684546 | |
| 15:54:47 | mriedem | https://opendev.org/openstack/nova/src/tag/19.0.0/nova/compute/rpcapi.py#L365 | |
| 15:55:05 | gibi | efried: respun https://review.opendev.org/#/c/684545 | |
| 15:55:13 | efried | ... | |
| 15:55:15 | mriedem | if conductor is pinned less than 1.13, conductor's compute task manager won't even get a request spec | |
| 15:55:16 | dansmith | mriedem: oh, you're right, I read the "Version 5.0 is .... Pike compat" in the comment | |
| 15:55:32 | dansmith | yeah, but conductor pinning isn't really a useful thing | |
| 15:55:38 | dansmith | which is why you say "technically.." I think | |
| 15:55:56 | mriedem | and because it's so f'ing old | |
| 15:56:21 | dansmith | but fair enough, I just had it in my head that 5.0 was much older, but I since we didn't bump for any reason in rocky, that makes sense now | |
| 15:56:52 | efried | gibi: would it be accurate to say "Ensure that re-schedule is possible on migration even if the server is originally booted with forced host." | |