Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-26
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
16:03:48 openstackgerrit Merged openstack/nova-specs master: Amend "Configure max number of volumes to attach" spec https://review.opendev.org/682136
16:04:08 gibi mriedem: thanks. now I remember. it is ugly scoping in any case
16:04:16 mriedem hey,
16:04:21 mriedem one man's trash is another man's treasure
16:06:36 gibi mriedem: to be correct I don't like either of the solutions due to the scoping trick. nothing personal :)
16:07:21 qqmber Hi.. I'm usong Rocky and for the first time I didn't assign a floating IP to an instance... I enter thru another instance (that has floating IP). When I run "yum upgrade" it takes forever and I see a lot of hangs and timeouts... could be related to not having a floating IP assigned? (even I see it has a floating IP anyways)
16:08:26 qqmber I see stuff like this: Sep 26 16:04:43 es-3 dbus[579]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
16:10:51 donnyd floating ips are at the most basic just an inbound NAT done at the network node. Outbound traffic should follow the same flow with or without a floating ip
16:11:23 donnyd I would also ask in neutron
16:12:32 donnyd qqmber: also i would be looking at a dns issue
16:13:16 donnyd try something like ping -4 google.com and then ping -4 172.217.13.238
16:13:32 donnyd if the second command has no issue or delay... you have a dns problem
16:13:42 donnyd likely i should say
16:14:40 qqmber donnyd: I'm running the same (yum upgrade) on two instances.. both in the same host.. one with floating IP, one without.. the one without floating IP has the hanging problem... weird...

Earlier   Later