Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-20
09:39:09 kaisers *dang* missed out on the hotkey
09:40:00 kaisers stephenfin: Hi! Updated both CLs based on yesterdays feedback :)
09:40:10 stephenfin ack
09:48:42 kashyap gibi: The Zuul is -2 here because the parent patch is not merged yet? -- https://review.openstack.org/#/c/637152/
09:51:53 stephenfin kaisers: +2 on https://review.openstack.org/#/c/554195/ *but* I do have some comments that I'd really like to see addressed, if you have time. They're not blockers though
09:55:59 kaisers stephenfin: can be solved, np
09:57:54 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.69 https://review.openstack.org/637234
09:58:30 openstackgerrit Lajos Katona proposed openstack/python-novaclient master: Add support for microversion v2.70 https://review.openstack.org/637234
09:58:45 stephenfin kaisers: Cool. Also +2 on https://review.openstack.org/#/c/522245/ with two nice-to-have but not blocking nits
10:05:51 stephenfin Hmm, no gibi. How odd
10:06:14 stephenfin bauzas: You're next in line. Could you push this trivial follow up patch through? https://review.openstack.org/#/c/636967
10:06:52 stephenfin bauzas: Next in line for reviews and not for the throne, I'm afraid. They'd never accept a Frenchman for that
10:07:04 stephenfin ...unless the alternative was Boris Johnson, maybe
10:07:41 bauzas stephenfin: sorry I don't remember which trivial patch to push ? ;)
10:08:32 bauzas and well, for the throne, we had some history here about kings...
10:09:14 stephenfin My policy on trivial patches is pro having it and pro pushing it
10:09:50 kashyap stephenfin: Re-thinking is a bug really necessary here?: https://review.openstack.org/#/c/637578/1/nova/virt/libvirt/driver.py
10:10:05 kashyap s/Re-thinking/Re-thinking,/
10:10:14 bauzas stephenfin: ah sorry, I misunderstood the "this"
10:10:20 bauzas stephenfin: but sure, yeah
10:11:00 stephenfin kashyap: How so?
10:11:22 kashyap stephenfin: This line: https://review.openstack.org/#/c/637578/1/nova/virt/libvirt/driver.py@4961
10:11:41 kashyap stephenfin: Where you guessed a bug might be useful
10:12:15 stephenfin kashyap: I was referring to https://review.openstack.org/#/c/637578/1/nova/virt/libvirt/driver.py@4957
10:12:36 kashyap Correct, I posted the wrong line
10:12:41 stephenfin Where we create a PTY device for non-QEMU/KVM, non-parallels hypervisors
10:13:12 bauzas stephenfin: I just +1d because I have a question
10:13:17 bauzas (even for a nit :p )
10:13:37 kashyap stephenfin: Right, but the non-{QEMU/KVM, -Parellels} get a PTY device anyway.
10:14:15 stephenfin kashyap: Not previously though, right? Previously the 'if CONF.serial_console.enabled:' line in '_create_pty_device' would have stopped that happening
10:14:23 kashyap You want to capture that the existing code didn't create a serial device?
10:14:54 kashyap stephenfin: Previously too, according the existing table; and I checked with an s390x maintainer, too, FWIW
10:15:22 stephenfin kashyap: Assuming _that_ is the incorrect behavior, yes
10:15:53 kashyap Heh, what a maze; I'll see about what to file once I re-read the old code again.
10:15:55 stephenfin kashyap: To be completely clear, I don't know if it should have one or not. I'm going on Georg's comments
10:16:16 kashyap stephenfin: Georg says it's OK to not file one.
10:16:19 stephenfin What are the non-QEMU/KVM, non-Parallels libvirt drivers we support
10:16:21 stephenfin *?
10:16:26 kashyap stephenfin: zKVM
10:16:47 kashyap More accurately called "z/VM" I guess
10:17:55 stephenfin bauzas: Replied, but the answer is here https://review.openstack.org/#/c/636627/1/nova/conf/base.py@29
10:17:56 kashyap stephenfin: It is z/VM (ignore the zKVM bit)
10:18:52 stephenfin kashyap: I can get onboard with that, but I do think that we should have a test and call out the change in behavior in the commit message if there is no bug
10:19:21 stephenfin Otherwise we've got a change in behavior with no indication to future reviewers of the patch as to why that change happened
10:19:23 kashyap stephenfin: Yeah, that sounds reasonable.
10:19:58 kashyap I'm all for capturing the intention of a change as clearly as we can :-)
10:33:47 gibi bauzas: could you look at pike backport please? https://review.openstack.org/#/c/603044 the original fix was merged on master when during the Queens cycle
10:34:01 bauzas gibi: ack
10:34:32 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Reject resize requests when the source host is down https://review.openstack.org/623489
10:35:08 gibi bauzas: thanks
10:35:10 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Reject resize requests when the source host is down https://review.openstack.org/623489
10:35:42 lyarwood mdbooth_: ^ dropped the ignore_forced_down stuff, lets see if anyone raises the LM use case I was talking about.
10:37:34 bauzas gibi: I have multiple concerns with the backport
10:38:35 gibi bauzas: the new config options?
10:41:16 bauzas gibi: lemme review a bit more before
10:45:10 mdbooth lyarwood: Yeah, that LM use case just sounds wrong to me. The other thing is that if a service is forced_down, anything which does a service check on it will return that it's down. That just seems really fragile to me, hence I wanted a functional test.
10:45:19 mdbooth ... if we were going to rely on it, that is.
10:55:38 lyarwood mdbooth: ack yeah that's fine and agreed it's odd that LM would even work with things forced_down tbh
10:57:48 bauzas gibi: commented now
11:00:41 gibi bauzas: thanks
11:01:52 bauzas gibi: i could have proposed my own revision, but given it's a new backport contributor, I prefer him to amend himself and correctly expain the diffs
11:01:59 gibi if the author doesn't fix what you asked then I can fixup that patch
11:02:22 bauzas gibi: ok cool, just keep an eye then
11:02:26 gibi bauzas: agree with your strategy
11:02:33 gibi bauzas: I will check back in a week
12:38:37 Sundar Hi gibi, please ping me if you are around
12:44:51 gibi Sundar: hi!
12:45:01 gibi Sundar: I also tried to talk to you in my morning
12:45:48 gibi Sundar: I saw that you updated the bottom of the bandwidth patch series
12:45:59 gibi Sundar: but I guess you used an old version of my patches
12:48:33 openstackgerrit Silvan Kaiser proposed openstack/nova master: Exec systemd-run without --user flag in Quobyte driver https://review.openstack.org/554195
12:51:06 Sundar gibi: The patch series was rebased by Eric. It does seem like an older version. Sorry if it impacts your work.
12:51:44 gibi Sundar: I restored the latest content of my patches with an extra rebase couple of hours ago
12:51:48 Sundar gibi: I suppose the patch got updated after the rebase
12:51:53 gibi Sundar: so at the moment my patches are up-to-date
12:52:17 gibi Sundar: most probably I updated my patches after the last rebase of your patches
12:52:38 gibi Sundar: and when your patches was pushed up it changed my patche back to an old version
12:55:10 Sundar gibi: Any suggestions for keeping both in sync?
12:55:34 Sundar gibi: I mean, apart from manual rebasing periodically
12:57:20 Sundar gibi: Apologies again for using an older version
12:58:20 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
12:59:32 gibi Sundar: unfortunately if I push up a new version of the patches you are based on then you have to rebase yours top of my new version
13:01:48 kaisers stephenfin: ping :)
13:02:05 Sundar gibi: Got it. Could I ask you to review https://review.openstack.org/#/q/status:open+project:openstack/nova+bp/nova-cyborg-interaction? Your comments would be welcome!
13:03:13 gibi Sundar: I've added to my review queue
13:04:42 Sundar gibi: Thank you. :) The only change I made to your patch (which has already been merged) is in https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L75, where I got it to return ident.
13:11:58 gibi Sundar: but now I don't see that change in your series
13:13:54 kashyap Hmm, seems like 'tox-py27' seem to randomly fail due to:
13:13:55 kashyap sqlalchemy.exc.InterfaceError: (pymysql.err.InterfaceError) (0, '') (Background on this error at: http://sqlalche.me/e/rvf5)
13:14:49 jaypipes am I the only person that thinks the phrase "tripleo standalone install" is an oxymoron?
13:16:08 kashyap jaypipes: Heh, I guess that depends on what they mean by "standalone install"
13:16:23 Sundar gibi: I will take a look
13:16:29 kashyap jaypipes: /me himself has never hands-on installed TripleO, though ...
13:25:08 openstackgerrit zhaixiaojun proposed openstack/nova master: When the flavor id is invalid, the message does not match the regular expression, missing the numbers from 0-9. https://review.openstack.org/638150
13:29:53 jangutter kashyap, jaypipes: don't get me wrong, I love tripleo. It's also one of the most scarily self-referential things I've ever come across.
13:30:56 mdbooth sean-k-mooney: Through what's almost certainly a bug, but one which goes down a rabbit hole I'm not interested in right now, I've ended up with a port bound on a compute host which neutron doesn't think it's bound on, causing LM failure. What's the best way to kick it so I can get on with my day?
13:31:28 jangutter jaypipes: I presume you're referring to tripleo-quickstart?
13:32:38 openstackgerrit Matt Riedemann proposed openstack/nova master: Check hosts have no instances for AZ rename https://review.openstack.org/509206
13:35:44 sean-k-mooney mdbooth: define bound. you could try a hard reboot but neutron is the souce of truth in this matter
13:35:55 jaypipes jangutter: no, I'm referring to larsks's phrase "tripleo standalone install" in a recent ML post

Earlier   Later