| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-30 | |||
| 13:29:55 | bauzas | should we understand that US people are in holidays ? | |
| 13:30:56 | ildikov | sfinucan: I answered your question about the exception with attachment_create, so I think we're on the same with that | |
| 13:31:41 | ildikov | sfinucan: I can add a comment to the simple create, although we don't plan to touch that code maybe someone gets interested to rethink that one | |
| 13:31:52 | sfinucan | peter-hamilton: Actually, I take that back. The second one looks good to me, with the exception of the incorrect version. Fix that and I can +2/+W | |
| 13:32:11 | edleafe | bauzas: Yes, just Monday. But hangovers can last longer. :) | |
| 13:32:29 | bauzas | heh, like French folks :p | |
| 13:33:31 | sfinucan | ildikov: Perfect, thanks. The create case is a nit so we don't need to bother about. Once I know there's something there :) | |
| 13:34:56 | openstackgerrit | Béla Vancsics proposed openstack/nova master: Transform aggregate.update_metadata notification https://review.openstack.org/460625 | |
| 13:36:58 | peter-hamilton | sfinucan: thanks, i'll push out an update in a bit | |
| 13:38:51 | openstackgerrit | Merged openstack/nova master: Add `img_hide_hypervisor_id` image property https://review.openstack.org/459753 | |
| 13:39:49 | mriedem | bauzas: https://review.openstack.org/#/c/468549/ and the one after it are cells v2 regressions and need to go back to newton, so would appreciate a review on those | |
| 13:39:54 | mriedem | first is the recreate, 2nd is the fix | |
| 13:40:41 | bauzas | mriedem: will look very shortly, just amending a change | |
| 13:41:07 | openstackgerrit | Peter Hamilton proposed openstack/nova master: Add configuration options for certificate validation https://review.openstack.org/457678 | |
| 13:41:24 | danpawlik | mriedem: \o/ | |
| 13:41:28 | danpawlik | thanks | |
| 13:42:25 | mriedem | danpawlik: yw | |
| 13:43:20 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/468494 | |
| 13:43:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Pass a list of instance UUIDs to scheduler https://review.openstack.org/465171 | |
| 13:43:32 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: _schedule_instances() supporting a RequestSpec object https://review.openstack.org/469037 | |
| 13:43:44 | bauzas | edleafe: there it is ^ | |
| 13:44:13 | bauzas | edleafe: I just did cut your change in twice because it was becoming a big big | |
| 13:44:16 | bauzas | bit big | |
| 13:44:25 | danpawlik | Does someone have problem with Windows server 2012/2016 instance when is suspended and after resume Windows is freezed ? | |
| 13:46:03 | bauzas | mriedem: I had a question for https://review.openstack.org/#/c/466088/2 | |
| 13:46:21 | bauzas | mriedem: do you think we should add a functional regression test for that, given it's only for a driver ? | |
| 13:46:30 | bauzas | my guts are still yes tho | |
| 13:49:04 | mriedem | bauzas: functional regression test for what specifically? | |
| 13:49:10 | mriedem | we use the fake virt driver in our in-tree functional tests | |
| 13:49:54 | bauzas | mriedem: for the fact that a returning evacuation doesn't work for libvirt because of permissions | |
| 13:50:27 | mriedem | bauzas: we don't have libvirt in our functional test tree | |
| 13:50:29 | bauzas | and you're right, I knew for the fake driver, but I do wonder if we would need to verify some other drivers | |
| 13:50:36 | bauzas | okay, then... | |
| 13:51:08 | mriedem | we've talked about having an 'integrated' set of tests with a live devstack or something in the backend for more low-level testing, or things tempest can't test, like evacuate | |
| 13:51:21 | mriedem | but until someone makes that happen it's just talk | |
| 13:51:30 | bauzas | mriedem: I was wondering if we were having something like a LibvirtFixture :p | |
| 13:51:50 | bauzas | okay, then nevermind, I thought it was already there | |
| 13:52:33 | mriedem | there is already the FakeLibvirt fixture yes | |
| 13:52:46 | mriedem | you could use that in some functional tests i guess | |
| 13:53:01 | andymccr | morning nova - since https://review.openstack.org/#/c/458635/ & https://review.openstack.org/#/c/458634/ - we're seeing gate failures in OSA due to host not being mapped to a cell - if you try the boot a short while later it works. I'm wondering if there is a step we are maybe missing, or something that might've changed? | |
| 13:54:14 | mriedem | andymccr: when are you running discover_hosts? | |
| 13:54:33 | mriedem | bauzas: fyi http://lists.openstack.org/pipermail/openstack-dev/2017-April/116029.html | |
| 13:54:50 | andymccr | mriedem: we run it as one of the last steps, after compute is up. (it's set to -1 so it should only map if its manual - if my understanding of that option is correct at least) | |
| 13:55:06 | edleafe | bauzas: in meetings for the next few hours. Will review after | |
| 13:55:11 | andymccr | but booting an instance will work fine if you try manually after the failure, although it fails consistently since those patches merged | |
| 13:55:31 | mriedem | andymccr: i'm not sure i understand - which option? | |
| 13:56:00 | mriedem | andymccr: do you mean discover_hosts_in_cells_interval ? | |
| 13:56:30 | mriedem | the default on that, -1, means it won't run as a periodic task | |
| 13:56:32 | andymccr | mriedem: yeah - i figured it could be a race condition on that - but since we're setting it to -1 for the gate and then manually running host_discover i figured it should work | |
| 13:56:40 | mriedem | so you'd have to run nova-manage cell_v2 discover_hosts manually | |
| 13:56:41 | kaisers1 | Hi! I've a fix for an old and rather nasty driver bug, the fix (https://review.openstack.org/#/c/432344/) has been through a few cycles with mbooth and now requires some Core love. Would be great to see this finally land. :) | |
| 13:56:54 | mriedem | andymccr: is discover_hosts running before the server boot failure? | |
| 13:57:20 | andymccr | mriedem: yeah. the boot failure happens as part of the tempest run we do after nova is setup | |
| 13:57:41 | mriedem | andymccr: do you have logs for one of these failures? | |
| 13:57:45 | andymccr | mriedem: sure | |
| 13:57:53 | andymccr | http://logs.openstack.org/21/468321/2/check/gate-openstack-ansible-os_nova-ansible-func-ubuntu-xenial/2b36790/logs/openstack/openstack1/nova/nova-scheduler.log.txt.gz#_2017-05-30_12_00_41_488 | |
| 13:58:15 | andymccr | thats the scheduler log although i should have any other nova logs that would be helpful | |
| 13:58:26 | andymccr | appreciate the help! | |
| 13:58:39 | mriedem | andymccr: ^ is a different thing | |
| 13:58:43 | mriedem | which i have a patch for | |
| 13:58:58 | mriedem | https://review.openstack.org/#/c/454426/ | |
| 13:59:33 | andymccr | mriedem: ahh awesome - i'll test that then. thanks! | |
| 13:59:52 | mriedem | that won't fix a boot failure, but it fixes the ugly stacktrace on startup | |
| 14:00:07 | artom | Hrrm, what if Tempest got a "synchronized" test decorator - ie, run this test by itself | |
| 14:00:29 | andymccr | ahh so the stack trace is a red herring | |
| 14:00:40 | artom | For evacuation testing, for example (to sort of continue the previous discussion) | |
| 14:02:10 | mriedem | artom: they already have a lock fixture in tempest | |
| 14:02:21 | mriedem | we use it for the default quota class tests | |
| 14:02:44 | mriedem | https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_quotas.py#L32 | |
| 14:03:23 | artom | Ah, but you have to specify a lock name | |
| 14:03:26 | artom | (Right?) | |
| 14:03:40 | artom | So if we want to use it for evacuation tests, we'd have to modify every other test to lock them out | |
| 14:03:41 | mriedem | yes, and define that lock in other tests too, that you need to lock with | |
| 14:03:51 | mriedem | correct, or do something sneaky in the base compute class | |
| 14:04:02 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Add is_vz_container function https://review.openstack.org/445947 | |
| 14:04:15 | artom | At least it shows they're amenable to that sort of stuff | |
| 14:04:36 | artom | Maybe a "synchronized" thing would fly | |
| 14:04:46 | jaypipes | edleafe, bauzas, cdent, mriedem: fancy doing a quick pow-wow about scheduler topics given we missed yesterday's meeting? | |
| 14:04:56 | bauzas | why not | |
| 14:05:02 | bauzas | I just provide some new revs | |
| 14:05:20 | mriedem | andymccr: is there a log with the tempest console logs in it from the failed tempest run? http://logs.openstack.org/21/468321/2/check/gate-openstack-ansible-os_nova-ansible-func-ubuntu-xenial/2b36790/console.html#_2017-05-30_12_03_59_084558 | |
| 14:05:26 | bauzas | about a thought I had about not providing instance UUIDs but rather a list of Spec objects | |
| 14:05:48 | mriedem | bauzas: so just totally explode rpc then? | |
| 14:05:52 | cdent | jaypipes: ten minutes ago edleafe said he was in meetings for next few hours, and I'm out in the big city on yet another dead car curn | |
| 14:05:57 | cdent | mriedem: that's what I thought too | |
| 14:06:00 | bauzas | mriedem: we already do that for the conductor | |
| 14:06:20 | bauzas | mriedem: as dan wrote it :) | |
| 14:06:23 | mriedem | we should do it less if we can help it | |
| 14:06:42 | bauzas | as I said in the commit msg, it's not really a performance issue | |
| 14:06:55 | bauzas | only if you're asking for more than one instance | |
| 14:06:55 | mriedem | how do you know? | |
| 14:07:00 | mriedem | right, which people do | |
| 14:07:02 | mriedem | people/systems | |
| 14:07:27 | bauzas | mriedem: see code, you'll see api calling conductor with passing a list of buildrequests and request_specs | |
| 14:07:34 | andymccr | double checking that. it looks like we might not be copying it for the gate purposes. will run a test and check! | |
| 14:08:03 | bauzas | not sure why it would be a problem now with the scheduler API, while it wasn't a problem with the conductor one | |
| 14:08:34 | cdent | bauzas: do you want to do it for sake of consistency, or is there some other reason? | |
| 14:08:59 | mriedem | bauzas: it might have been a problem that no one directly complained about, but people have complained about the memory usage bloat in nova over the last few releases | |
| 14:09:07 | bauzas | cdent: because of the comments I made in PS7 | |
| 14:09:16 | mriedem | and i have to assume some of that is tied to us passing big lists of big objects around and assuming it's fine | |