Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-09
10:14:32 efried thanks gibi
10:14:52 gibi efried: I also need to backport that to pike for my downstream world
10:15:08 efried everybody wins
10:15:43 gibi yepp
10:38:35 SonPham hi . how to boot to instance with this conf
10:52:16 openstackgerrit sean mooney proposed openstack/nova master: [DNM] cpu pinning testing https://review.opendev.org/681807
10:55:17 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Add functional test for resize crash compute restart revert https://review.opendev.org/687532
10:56:41 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Functional reproduce for bug 1833581 https://review.opendev.org/687534
10:56:41 openstack bug 1833581 in OpenStack Compute (nova) train "instance stuck in BUILD state if nova-compute is restarted" [Low,In progress] https://launchpad.net/bugs/1833581 - Assigned to Balazs Gibizer (balazs-gibizer)
10:56:41 openstackgerrit Balazs Gibizer proposed openstack/nova stable/stein: Error out interrupted builds https://review.opendev.org/687535
10:57:02 gibi eandersson: stable/stein ^^ rocky coming up next
11:41:15 efried mriedem: mock.patch.stopall() has unanticipated knock-on effects. For example, fixtures.MockPatch uses... mock.patch. So any fixtures.MockPatch'd mock, anywhere in the test setup, goes away as well.
11:42:33 sean-k-mooney efried: well that is kind of expect in one way but i guest the other uses may not have been considered
11:43:07 sean-k-mooney e.g. we do expect it to stop _all_ patches using that pattern
11:43:26 efried according to the docs, it only stops patches started with mock.patch.start()
11:43:29 sean-k-mooney efried: is it causeing other code to run that should not
11:43:40 sean-k-mooney sure
11:43:50 efried it was in my local change
11:43:58 sean-k-mooney so decorators should not be affected
11:44:00 efried where I'm adding a fixtures.MockPatch waaaay down in the test setup
11:44:03 sean-k-mooney or with context manager
11:44:39 efried I got around it by changing to MonkeyPatch, which doesn't use mock.patch.start(), but my point is, that's a terrible side effect.
11:45:55 sean-k-mooney efried: you could also jsut save the patche object as self.whatever and then do self.whatever.stop()
11:46:07 sean-k-mooney rather then stopall right
11:49:48 efried sean-k-mooney: theoretically, but I think in this case the patches are buried and difficult to get at.
11:50:08 efried see test_bug_1781286
11:57:04 sean-k-mooney the test_bug_1781286 on your local branch or https://review.opendev.org/#/c/686017/4/nova/tests/functional/regressions/test_bug_1781286.py
11:58:49 sean-k-mooney in anycase i better go prepare a few thing before going to the bank. in an hour
13:15:36 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: cleanup evacuated instances not on hypervisor https://review.opendev.org/687550
13:48:23 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Add functional test for resize crash compute restart revert https://review.opendev.org/687563
13:49:42 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Functional reproduce for bug 1833581 https://review.opendev.org/687564
13:49:42 openstack bug 1833581 in OpenStack Compute (nova) train "instance stuck in BUILD state if nova-compute is restarted" [Low,In progress] https://launchpad.net/bugs/1833581 - Assigned to Balazs Gibizer (balazs-gibizer)
13:49:42 openstackgerrit Balazs Gibizer proposed openstack/nova stable/rocky: Error out interrupted builds https://review.opendev.org/687565
13:58:43 dansmith mriedem: yeah that seems more efficient than waiting until we get to the compute to find out we're effed anyway right?
14:02:05 mriedem dansmith: we weren't waiting until the compute
14:02:18 mriedem that cinder.check_availability_zone method is called from the api's _validate_bdm method,
14:02:27 mriedem for the pre-existing volume bfv case,
14:02:32 dansmith your other solution wasn't?
14:02:33 mriedem it's also called from compute when we create a volume
14:02:36 mriedem correct
14:02:49 mriedem it's confusing b/c the method is used in both the api and compute but for different source bdms
14:02:54 dansmith oh, it was deep in the cinder code
14:02:55 dansmith right
14:02:58 mriedem yeah
14:03:03 mriedem the new patch is much more straightforward imo
14:03:12 mriedem since it avoids that tightly coupled plumbing
14:03:24 dansmith yep, well, that's what I was looking for
14:03:45 mriedem ack, it's also the alternative i tihnk i thought of on the original patch a long time ago but hadn't yet worked up a patch to see it in action
14:03:54 mriedem the functional recreate tests helped to make sure it was all working
14:03:58 mriedem i'm just fixing unit tests now
14:04:20 mriedem if you have suggestions on the patch, like if you're annoyed at the size with the docstrings and stuff, i could split that stuff out
14:05:59 dansmith not particularly.. I just kinda skimmed it but seems good
14:10:27 openstackgerrit Kashyap Chamarthy proposed openstack/nova stable/queens: libvirt: Rework 'EBUSY' (SIGKILL) error handling code path https://review.opendev.org/668111
14:10:42 gibi eandersson: rocky backport is up https://review.opendev.org/#/c/687565/ It is not a clean one
14:11:23 kashyap mriedem: You've in the past asked about the above stable/queens backport; I've got multiple bug reports for it, downstream, FWIW. I think it's worth it for Queens, too; Cc: lyarwood
14:12:09 kashyap (I fixed the legit test failure you pointed out.)
14:14:30 mriedem gibi: -1 on the bottom of your stein series of backports
14:14:44 mriedem missing a fix for a bug in the functional test i added which you fixed in train
14:15:40 gibi mriedem: thanks for checking. This is not at all a clean backport series unfortunately
14:15:48 mriedem kashyap: i'm not sure i want to be involved in that, it feels very rhel specific and especially with the rhel focus/pressure on queens stuff
14:15:54 mriedem kashyap: maybe if dansmith blesses it first
14:16:03 mriedem gibi: yeah i'm not surprised
14:16:13 kashyap mriedem: I knew you might say something like that :-) There's no "pressure" per se - as you can see the timeline of the backport
14:16:59 kashyap mriedem: I'd apprecaite if you were more charitable in your interpretation of intentions. I take "upstream first" damn seriously.
14:17:03 openstackgerrit Eric Fried proposed openstack/nova master: Stop using NoAuthMiddleware in tests https://review.opendev.org/687416
14:17:41 efried mriedem: That might be ready to go ^
14:19:26 mriedem kashyap: sorry?
14:19:53 kashyap mriedem: Nothing; my tired brain maybe read too much into what you said.
14:20:01 mriedem i'm not the only stable core so i'd appreciate if you didn't lay it on me
14:20:28 kashyap Sure. I explicitly pinged you because you had a question - otherwise, like any good citizen I'd ask it to the channel.
14:23:42 kashyap mriedem: Also, it is not "RHEL-specific" (whatever you mean by that)
14:25:00 dansmith mriedem: doesn't seem terrible to me. anyone running queens that is tracking later libvirt would care about this (like metacloud used to be famous for)
14:25:36 dansmith realistically today we're probably the ones that most care
14:25:59 dansmith we'll backport it internally of course, but it's cleaner for the accounting if it's in upstream queens
14:26:20 dansmith unless we mark a maximum version of libvirt that is acceptable for a given release, then this just seems like maintenance to me
14:27:50 mriedem maybe my mistake is originally reading it as "if you've got libvirt 4.7.0+ in queens do x" which is true but not probably for the reason i thought, which was like opt into some new behavior, and i thought "who is going to be running that new a version of libvirt except rhelosp customers"
14:28:34 mriedem so the point is if you're running libvirt 4.7.0+ let it do the retry/timeout stuff rather than nova, otherwise you get what - a super long timeout (or too short?) retry/timeout loop?
14:29:15 dansmith mriedem: right, but also apparently it changes the timeout counter for older versions, which should have been a different patch
14:29:30 dansmith so in that sense, it improves things for the more normal-for-queens versions too (supposedly)
14:29:57 dansmith tbh, it needed a refactor to make that clearer because it took me a while to realize it wasn't doing something much dumber
14:30:19 dansmith it looked to me like it was increasing the timout for 4.7 and actually removing that code for the older versions, but it's the opposite
14:30:29 dansmith but, have to kick that to the original reviewers
14:30:38 mriedem so wait longer for older libvirt versions, for newer libvirt let it handle it (assuming libvirt 4.7.0+ wait doesn't have bugs...)
14:30:40 dansmith (whoever that was, not me)
14:30:44 dansmith yes
14:37:45 bauzas gibi: http://paste.openstack.org/show/782109/ at line 17 and below looks weirdo
14:42:37 kashyap dansmith: Yes, your view is correct in: "largely maintenance".
14:42:44 kashyap mriedem: Your "so the point" is indeed correct
14:44:55 gibi bauzas: what do you mean by weirdo?
14:45:10 kashyap dansmith: Maintenance, and also improves things for normal-for-Queens version, too. FWIW, I've seen several occurences of it upstream and on IRC, too.
14:45:49 bauzas gibi: because I don't understand why it's not getting the compute node
14:45:54 dansmith kashyap: I think I said that, almost word-for-word :)
14:46:01 bauzas gibi: at least for the first RP
14:46:13 kashyap dansmith: I _was_ reinforcing your point, if it wasn't obvious :-)
14:46:20 bauzas (for the others, well it should find the root RP)
14:46:29 bauzas anyway, will try to find the problem
14:46:32 gibi bauzas: could this be some noise from the scatter gather? trying to get the compute from cell0?
14:47:16 kashyap dansmith: So in your copious free time, ACK / NACK / etc :-) (Also on refactor - that whole _method_ needs refactoring, you saw how long & convoluted that already is)
14:47:17 bauzas I don't think because I used the method not verifying the cell0
14:47:25 bauzas gibi: anyway, thanks

Earlier   Later