Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-20
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
13:36:25 sean-k-mooney mdbooth: we recently merged a fix to prevent the network info cache form getting out of sync so that should fix nova db periodicaly
13:36:35 mdbooth sean-k-mooney: I suspect it's an agent issue. Bind fails on the destination. I just deleted the instance, though, so I'm guessing the mess is still there but as long as it doesn't affect me I don't care right now :)
13:36:44 jangutter jaypipes: that sounds like a standalone networked computer in my mind.
13:36:57 jaypipes I'm actually not sure what was meant.
13:37:33 mdbooth It was a failed LM. LM failed because ssh keys weren't configured. Haven't looked , but presumably we created ports on the dest prior to LM, then didn't clean them up properly when it failed.
13:37:55 mdbooth So second attempt to LM fails because port is already bound.
13:38:17 jangutter jaypipes: reading the mail, I think this is "standalone" vs "integrating with an external ... " etc.
13:38:53 larsks jaypipes: standalone tripleo: https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.html
13:39:20 larsks Single node tripleo deployment installed using the 'openstack tripleo deploy' command.
13:39:39 jangutter larsks: aaah, "standalone" vs "ha".
13:39:46 jaypipes interesting.
13:39:56 larsks jangutter: not exactly. "standalone" vs "multinode"
13:40:19 jaypipes probably better to call it "all-in-one" or "single-node", but ok
13:40:29 larsks Eh, I didn't name it :). But yes.
13:40:33 jaypipes :)
13:40:49 jaypipes larsks: k, thx for the heads up. looks like this is relatively new functionality.
13:41:25 larsks I think so. I believe it stems from wanting to handle underlcoud deployment the same way as overcloud deployment.
13:41:54 jaypipes it's all a little too inception-y for me.
13:42:05 jaypipes turtles all the way down ;)

Earlier   Later