Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-26
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 :" [Medium,In progress] https://launchpad.net/bugs/1845291 - Assigned to Balazs Gibizer (balazs-gibizer)
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."
15:57:40 mriedem efried: gibi: remember i did use call_count recently for something like https://review.opendev.org/#/c/684545/3/nova/tests/functional/regressions/test_bug_1845291.py@40 and it was a big hullabaloo
15:57:45 mriedem artom got all stinky about it
15:58:36 gibi efried:yes, your sentence sounds better than mine
15:58:44 openstackgerrit Eric Fried proposed openstack/nova master: Functional reproduction for bug 1845291 https://review.opendev.org/684545
15:58:44 openstack bug 1845291 in OpenStack Compute (nova) "migration is not recheduled if the server originally booted with --availability-zone :" [Medium,In progress] https://launchpad.net/bugs/1845291 - Assigned to Balazs Gibizer (balazs-gibizer)
15:59:17 openstackgerrit Eric Fried proposed openstack/nova master: Reset forced_destination before migration at a proper time https://review.opendev.org/684546
15:59:32 efried gibi: okay, tweaked a little bit and approved. Thanks.
15:59:48 gibi efried: thanks
16:00:04 gibi mriedem: sorry I did not remember. How did you managed to do a conditional in the fake based on the call count?
16:00:19 mriedem i'm trying to find it
16:00:37 mriedem https://review.opendev.org/#/c/682140/1/nova/tests/functional/test_servers.py@6817

Earlier   Later