Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-01
00:48:46 bnemec And this bug is blocking the promotion jobs. :-)
00:49:25 bnemec andreykurilin: I have to get going. I'll pick this back up tomorrow though.
00:52:11 andreykurilin bnemec: give me a sec, I'll resubmit a patch
00:53:12 andreykurilin bnemec: I submitted a new patch-set with hack for old release
00:54:02 openstackgerrit Ildiko Vancsa proposed openstack/nova: Implement new attach/detach Cinder flow https://review.openstack.org/330285
00:54:06 openstackgerrit Ildiko Vancsa proposed openstack/nova: Remove check_attach https://review.openstack.org/335358
01:38:51 openstack Launchpad bug 1660761 in kolla-ansible "VM stuck in scheduling" [Critical,Confirmed] - Assigned to Michał Jastrzębski (inc007)
01:38:51 inc0 hello guys, we (kolla) started to experience issues with nova - https://bugs.launchpad.net/kolla-ansible/+bug/1660761
01:39:15 inc0 cells v2 landed? I assume there is new step durng deployment process right?
01:39:47 inc0 and we *have to* configure cells now?
01:41:43 diana_clarke inc0: yes, cells v2 setup is required as of ocata
01:42:31 inc0 http://docs.openstack.org/developer/nova/cells.html#cells-v2 this is correct doc right?
01:42:57 diana_clarke inc0: I'm just pulling up some links for you (sorry if that sounded short/terse a moment ago).
01:43:21 diana_clarke inc0: yup, that a good one to read
01:43:24 diana_clarke inc0: https://review.openstack.org/#/c/426864/5/releasenotes/notes/ocata_prelude-cfa8793d07f963e7.yaml
01:43:26 inc0 diana_clarke, it did not:) it sounded nothing but helpful:)
01:43:53 inc0 thank you, I'll get to writing deployment code for that
01:45:00 diana_clarke inc0: http://docs.openstack.org/developer/nova/man/nova-manage.html#nova-cells-v2
01:45:57 inc0 thanks, I'll check if other deployment tools got that in their deploy as well
01:46:13 inc0 this will have to be part of upgrade task too I assume?
01:46:43 diana_clarke inc0: Finally, I find the codesearch tool for "cells_v2" helpful to see how others have done it: http://codesearch.openstack.org/?q=cell_v2&i=nope&files=&repos=
01:47:31 diana_clarke inc0: yup, upgrade too
01:48:02 inc0 once I'll write code for it, I'll leave links here too so you could double check
01:48:10 inc0 thank you very much
01:49:24 diana_clarke inc0: Good luck! I'm still learning the ins and outs of it, but I can try to answer any questions you have.
03:07:10 mriedem yay new gate bugs http://logs.openstack.org/91/426991/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f218227/logs/screen-n-api.txt.gz#_2017-02-01_01_25_02_367
03:15:49 mriedem melwitt: dansmith: for debugging pleasure tomorrow, looks like we have a race after moving instance creation to conductor causing this failure
03:15:51 openstack Launchpad bug 1660878 in OpenStack Compute (nova) "test_reboot_deleted_server fails with 409 "Cannot 'reboot' instance while it is in vm_state building"" [High,Confirmed]
03:15:51 mriedem https://bugs.launchpad.net/nova/+bug/1660878
03:16:18 mriedem the test creates a server, then deletes it and waits for the 404, then tries to reboot it and expects a 404 but gets a 409 because it's now building
03:16:37 mriedem so my guess is we get a 404 when the build request is gone but before the instance is created, something like that
03:18:07 openstackgerrit Oliver Walsh proposed openstack/nova: DNM - TripleO CI test https://review.openstack.org/427536
03:35:07 dansmith mriedem: that's not supposed to happen because of the way we do the create of the instance and build request
03:35:19 dansmith but okay, let's look tomorrow
03:35:33 mriedem i'm going to put up a change with a bunch of debug logging
03:35:47 mriedem since the delete and get paths in the api are pretty hairy
03:58:48 smcginnis Since this afternoon I'm getting stacking failures with "No host found for cellv1" errors.
03:59:00 smcginnis Is there something I need to do to get this to work right?
04:00:21 mriedem smcginnis: latest devstack?
04:00:26 mriedem any special localrc?
04:00:34 smcginnis mriedem: Freshly cloned.
04:00:42 smcginnis mriedem: Nothing special in local.conf.
04:00:53 mriedem got a paste of the rough failure log?
04:01:52 mriedem are you sure that's the same error message? because i'm not finding that
04:02:16 smcginnis mriedem: local.conf file: http://paste.openstack.org/show/597124/
04:02:53 smcginnis mriedem: Shoot, looks like I'll have to try to stack again to get the exact text.
04:02:55 openstackgerrit Matt Riedemann proposed openstack/nova: WIP: Add debug logging for delete/query race bug https://review.openstack.org/427544
04:03:26 mriedem smcginnis: http://lists.openstack.org/pipermail/openstack-dev/2017-January/111295.html ?
04:03:32 mriedem you don't have placement-api in ENABLED_SERVICES
04:03:58 smcginnis mriedem: Mmmm, nope, I don't.
04:04:17 smcginnis mriedem: Guess I should have read that one.
04:04:28 mriedem dansmith: melwitt: just fyi for the morning https://review.openstack.org/#/c/427544/
04:04:39 mriedem this isn't a super high failure rate so i might have some rechecking to do
04:04:43 mriedem but it's high enough
04:04:50 mriedem 164 hits since 1/27
04:07:00 melwitt mriedem: thanks. I'm looking at it now. nothing jumping out at me yet
04:07:31 mriedem the mess of conditionals all over create/delete/get in api and conductor makes me think something can slip in here
04:07:41 mriedem and we're probably doing a pass or some other assumption in one of them
04:07:54 mriedem like,
04:07:58 mriedem well,
04:08:06 mriedem nvm
04:08:52 mriedem i was thinking, before the api casts to conductor to create the instance in the cell, the build request could be deleted, and then we create the instance from stale build request info, but then in conductor when we go to delete the build request, it should fail with a 404 and then we should cleanup the instance too
04:09:24 mriedem however, i wonder if the GET request is hitting right in between the time that the instance is created and the time that we try to delete the build request and find out it's already deleted, then cleanup
04:09:32 melwitt hmm
04:09:38 mriedem because there is no mutex there at all from what i can tell,
04:09:55 mriedem and after we cast to conductor, we never refresh the build request from the db to get it's current state before we actually create the instance in the cell, from what i can tell anyway
04:12:56 melwitt yeah, that sounds reasonable. I was thinking along those lines of somehow the instance getting resurrected
04:17:02 openstackgerrit Matt Riedemann proposed openstack/nova: WIP: Add debug logging for delete/query race bug https://review.openstack.org/427544
04:21:10 mriedem well i'm going to call it a night i guess
04:21:14 mriedem maybe we'll catch a fish
04:21:32 melwitt gnight o/
05:08:57 openstackgerrit Yoshihiko Atsumi proposed openstack/nova: Add resize server functional negative tests https://review.openstack.org/420514
07:22:36 openstackgerrit Takashi NATSUME proposed openstack/nova: Refactor a test method including 7 test cases https://review.openstack.org/395436
07:22:45 openstackgerrit Takashi NATSUME proposed openstack/nova: api-ref: Fix keypair API parameters https://review.openstack.org/420626
07:46:55 lennyb wznoinsk, I see a lot of multinode jobs fail lately (also our), I found that it's related to latest placement-api that was merged.
08:00:17 lennyb Infra, regarding gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial where can I find nova.conf files for hypervisors of this job. I have some troubles to apply placement api to our multinode setup
09:26:24 wznoinsk lennyb, our people are already on it :-), thanks for pinging
09:27:33 lyarwood johnthetubaguy, sfinucan, bauzas ; Would you mind taking a look at https://review.openstack.org/#/c/427267/ this morning, mriedem marked the bug as High / ocata-rc-potential so I'd like to get a few more reviews on it today if possible.
09:35:56 oomichi mriedem: yeah, 422171 becomes better
09:37:03 bauzas lyarwood: roger
09:42:27 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova: Optimize time during PCI alias parsing process https://review.openstack.org/427145
10:01:23 lennyb wznoinsk, looks like your people should add placement-api to enabled services on all computes
10:01:59 wznoinsk lennyb, maybe they did already, I'll pass the hint, thanks
10:02:19 gmann johnthetubaguy: alex_xu : can you check(whenever get time), i think we cannot change default policy value directly - https://review.openstack.org/#/c/396420/5
10:03:06 gmann johnthetubaguy: alex_xu also if you can check this sort/filter release note. I updated this one - https://review.openstack.org/#/c/421760/
10:08:44 johnthetubaguy gmann: I think I am +1 a lot of your comments, I am going to draft a spec around the policy changes I would like to see happen next cycle
10:09:51 gmann johnthetubaguy: yea that nice.
10:10:13 gmann johnthetubaguy: i tried to update the existing one but yea separate is better-https://review.openstack.org/#/c/425533/
10:10:14 johnthetubaguy working with some folks over in keystone land on that, with any luck, they have similar ideas/plans forming
10:10:31 gmann ok
10:10:54 johnthetubaguy want to get stuff laid out with some structure so we can talk through things at the PTG, with any luck.
10:11:43 johnthetubaguy lyarwood: ack
10:12:02 gmann yea that is more aligned for PTG and prepare before that
10:12:47 gmann johnthetubaguy: alex_xu btw do we have meeting today? do not think alex_xu is back
10:13:55 johnthetubaguy gmann: I don't know if we decided something, given its crazy o'clock for your all, I vote we skip it, but I will try start the meeting in case folks are about and want to discuss things
10:15:33 gmann ok
10:20:12 openstack Launchpad bug 1605016 in OpenStack Compute (nova) "Post copy live migration interrupts network connectivity" [High,In progress] - Assigned to Sivasathurappan Radhakrishnan (siva-radhakrishnan)
10:20:12 kashyap raj_singh: Hi, you have assigned someone to work on this -- https://bugs.launchpad.net/nova/+bug/1605016
10:20:18 cdent gmann, johnthetubaguy: If we're talking about api meetings I'd vote for skip too
10:20:31 kashyap Do they have requisite knowledge to work on it? Or should I reassign the bug back to 'nodbody'?

Earlier   Later