Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-09-26
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
16:17:29 donnyd qqmber: maybe the neutron channel would have more info on ways to t/s
16:17:56 donnyd or openstack-operators
16:18:03 qqmber ok, thanks!
17:49:07 melwitt mriedem: fyi I'm looking into https://bugs.launchpad.net/nova/+bug/1845243
17:49:07 openstack Launchpad bug 1845243 in OpenStack Compute (nova) stein "Nested 'path' query param in console URL breaks serialproxy" [High,Confirmed]
17:52:21 mriedem ack, cool
19:32:01 openstackgerrit Dustin Cowles proposed openstack/nova-specs master: Spec: Use OpenStack SDK in Nova (Ussuri) https://review.opendev.org/685154
20:49:05 openstackgerrit Merged openstack/nova-specs master: Spec: Use OpenStack SDK in Nova (Ussuri) https://review.opendev.org/685154
20:50:57 efried mriedem: wanna update https://etherpad.openstack.org/p/nova-train-release-todo to track RC2 candidates?
20:51:43 mriedem meaning? https://bugs.launchpad.net/nova/+bugs?field.tag=train-rc-potential
20:53:07 efried maybe just s/RC1/RC2/ on L13, but I dunno, swhy I'm asking
20:53:43 mriedem i'll let you drive
21:34:41 openstackgerrit Matt Riedemann proposed openstack/nova master: Migrate old style volume attachments on nova-compute startup https://review.opendev.org/549130
21:37:23 melwitt mriedem: commented on https://bugs.launchpad.net/nova/+bug/1845243 and would like a sanity check on the fix approach. dansmith too since he was involved in the discussion of the original change. cc efried
21:37:23 openstack Launchpad bug 1845243 in OpenStack Compute (nova) stein "Nested 'path' query param in console URL breaks serialproxy" [High,Confirmed]
21:41:26 mriedem commented
21:43:09 melwitt mriedem: thanks. I think it will be simple. kicking myself for not realizing the 'path' thing was novnc specialness
21:43:28 melwitt consoles: 2 me: 0
21:43:37 mriedem i wouldn't feel too bad about it

Earlier   Later