Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-26
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...
16:17:26 mriedem not really a nova development question either way

Earlier   Later