| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-23 | |||
| 20:21:32 | melwitt | coolness | |
| 20:21:58 | mriedem | btw, have we heard any updates from belmiro on the great cellsv2ification at cern? | |
| 20:22:01 | mriedem | and how it's going? | |
| 20:22:48 | melwitt | I haven't heard anything yet. just implied from the fixes they've been doing for other nova-manage cell_v2 commands, that they've been working on it | |
| 20:23:26 | melwitt | I think they'll need an improvement to map_instances themselves lest it take hours to run, heh | |
| 20:23:49 | melwitt | if they haven't already gone through it | |
| 20:27:19 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Handle RPC timeout on get_console_output https://review.openstack.org/525335 | |
| 20:33:41 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Expand on when you might want to set --max-count for map_instances https://review.openstack.org/536959 | |
| 20:34:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Expand on when you might want to set --max-count for map_instances https://review.openstack.org/536959 | |
| 20:50:20 | melwitt | what is with "libvirtError: Cannot recv data: Connection reset by peer" on stable, it's been flipping out, and specifically on the cells v1 job | |
| 20:52:33 | mriedem | is libvirt crashing? | |
| 20:52:37 | mriedem | check the libvirtd logs? | |
| 20:52:54 | mriedem | Roamer`: done https://review.openstack.org/#/c/140733/ | |
| 20:58:30 | Roamer` | mriedem, just got the e-mail, thanks! Looking at it... | |
| 21:01:08 | tonyb | mriedem: my plan is to do the double checking today and then ask infra. | |
| 21:01:19 | tonyb | mriedem: (re tagging nova newton-eol) | |
| 21:01:25 | melwitt | doesn't look like a crash but I'm not too familiar with libvirtd logging. I see a message '"kvm" accelerator not found' several times http://logs.openstack.org/97/536897/1/check/legacy-tempest-dsvm-cells/1f42e60/logs/libvirt/libvirtd.txt.gz#_2018-01-23_18_37_23_873 | |
| 21:06:00 | mriedem | doesn't look like it | |
| 21:06:10 | mriedem | tonyb: ok | |
| 21:07:30 | melwitt | comparing libvirtd.log with master change | |
| 21:08:08 | tonyb | melwitt: I wouldn't think that was a problem in a dsvm test | |
| 21:08:57 | melwitt | I don't find the kvm accelerator message in the master change libvirtd log | |
| 21:09:55 | mriedem | melwitt: what's the virt_type in nova.conf? | |
| 21:09:57 | mriedem | should be qemu | |
| 21:10:22 | mriedem | note that the version of libvirt is probably different between stable and master job runs | |
| 21:10:27 | mriedem | we use the pike UCA in master | |
| 21:10:49 | melwitt | huh, the nova-cpu.conf is very empty. http://logs.openstack.org/97/536897/1/check/legacy-tempest-dsvm-cells/1f42e60/logs/etc/nova/nova-cpu.conf.txt.gz | |
| 21:10:55 | melwitt | but in nova.conf virt_type = qemu | |
| 21:22:35 | melwitt | tonyb: what do you mean? the kvm accelerator thing shouldn't hurt? | |
| 21:23:11 | mriedem | melwitt: the cellsv1 job is probably not running in superconductor mode, | |
| 21:23:16 | mriedem | so doesn't use nova-cpu.conf | |
| 21:23:40 | melwitt | oh, okay | |
| 21:24:07 | tonyb | melwitt: just that in dsvm I'd expect kvm accelerator to me missing (as we should be using qemu), but it it strange that it's even looking for it | |
| 21:24:22 | melwitt | bah, there's a legit fail in the functional test_server_group tests on stable too. working on that | |
| 21:24:38 | melwitt | tonyb: oh, I see | |
| 21:30:13 | openstackgerrit | Merged openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 21:33:18 | openstackgerrit | Merged openstack/nova master: Replace curly quotes with straight quotes https://review.openstack.org/536727 | |
| 21:34:23 | melwitt | curly quotes eh? | |
| 21:35:15 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Handle RPC timeout on get_console_output https://review.openstack.org/525335 | |
| 21:35:37 | jackie-truong | If any core reviewer has a chance to take a look at this patch, it would be very much appreciated: https://review.openstack.org/#/c/486204/ | |
| 21:37:32 | jackie-truong | jaypipes was looking at the patch series, but he's out at a work conference at the moment. He had taken away +2 from its dependent patch (https://review.openstack.org/#/c/489408/) due to the patch series not being complete. But patch series is complete now :-) | |
| 21:38:15 | jackie-truong | Usage and testing instructions can be found here: https://etherpad.openstack.org/p/queens-nova-certificate-validation | |
| 21:38:35 | jackie-truong | And we also wrote a barbican-tempest-plugin test for it: https://review.openstack.org/#/c/515210/ | |
| 21:46:48 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: Set server status to ERROR if rebuild failed https://review.openstack.org/536897 | |
| 21:46:48 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: Fix false positive server group functional tests https://review.openstack.org/536981 | |
| 22:03:19 | openstackgerrit | Peter Penchev proposed openstack/nova master: Add the Nova libvirt StorPool attachment driver. https://review.openstack.org/140733 | |
| 22:05:37 | mriedem | dansmith: on alex_xu's 1.12 allocation candidate change, i assume you ran into the same sticky part here https://review.openstack.org/#/c/536083/4/nova/scheduler/client/report.py@1153 | |
| 22:05:47 | mriedem | with assuming that the client is getting a 1.12 format request, | |
| 22:06:14 | mriedem | we could be in the middle of a server create / cold migrate where the format is actually 1.10, you upgrade and restart conductor, and now the client code assumes it's going to get a 1.12 but it's 1.10 and kablammo | |
| 22:06:27 | mriedem | via reschedule from the compute | |
| 22:06:40 | mriedem | because we don't have a versioned object facade for this payload | |
| 22:10:17 | Roamer` | mriedem, new patchset up; thanks a lot for the very useful comments! | |
| 22:10:58 | Roamer` | (I guess now we wait for 12 hours or so for the checks to pass...) | |
| 22:17:41 | mriedem | Roamer`: do you have a 3rd party CI that will eventually comment on this change to say if it's working? | |
| 22:19:26 | Roamer` | mriedem, actually, yes, we do; the logs are at http://logs.ci-openstack.storpool.com/ but the run it's doing right now is not with this change yet, the next one will be | |
| 22:19:41 | Roamer` | so I guess in about two hours or so there'll be a run with this one | |
| 22:19:58 | Roamer` | (yeah, I should really look into speeding the CI runs up a bit) | |
| 22:20:04 | Roamer` | it's just Cinder though, not Nova | |
| 22:20:22 | Roamer` | I mean, it's the Tempest volume tests, not all the Nova-related tests | |
| 22:20:53 | mriedem | but at some point it's going to at least run a tempest compute api test to attach and detach a volume to a server instance yeah? | |
| 22:20:58 | Roamer` | yes, it will | |
| 22:21:00 | mriedem | ok | |
| 22:21:28 | Roamer` | I may not be awake when it does (just after midnight here), but I'll post a link in about seven hours | |
| 22:21:34 | Roamer` | then you won't be awake :) | |
| 22:21:50 | mriedem | oh i'll be awake | |
| 22:21:55 | mriedem | sitting by the phone | |
| 22:24:15 | mriedem | anyone know when jaypipes is going to be back? | |
| 22:24:47 | jackie-truong | mriedem: All I heard is "at a work conference this week" | |
| 22:25:11 | mriedem | alright | |
| 22:25:13 | Roamer` | hopefully you won't have to rescue the mailman again... here in Sofia we have a suburb up in the mountain where I used to live for like 20 years, and the snow is a bit of a problem sometimes, like public transport going "nuh-uh, not today" | |
| 22:25:37 | mriedem | i was unable to rescue the mailman - he had to get a tow truck | |
| 22:26:06 | mriedem | rear-wheel drive with go-kart tires on an inline in a foot of snow isn't going to cut it | |
| 22:26:11 | mriedem | *incline | |
| 22:27:05 | Roamer` | oh, I hear you... there was this New Year's Eve when a neighbor had a party, he specifically warned people not to drive if they don't have the tires, and as a result there were three taxi cabs stuck in the snow on our street | |
| 22:27:24 | mriedem | i did enjoy watching the neighbor across the street, who is new to snow, try to drive his bmw sedan over the 3 foot wall of ice that the plow left in front of his driveway, and of course get it stuck halfway | |
| 22:28:28 | melwitt | I have read that the most important thing is to have winter tires. and that 4x4 isn't necessarily needed? | |
| 22:28:37 | mriedem | i've never had winter tires | |
| 22:28:39 | mriedem | or 4x3 | |
| 22:28:41 | mriedem | *4x4 | |
| 22:28:45 | mriedem | just don't be a jackhole | |
| 22:28:54 | mriedem | and put a shovel in the trunk | |
| 22:29:00 | melwitt | heh, good to know | |
| 22:29:19 | mriedem | laura's got the 4x4 in our family | |
| 22:29:36 | jroll | melwitt: 4wd helps you go, winter tires help you stop :P | |
| 22:29:51 | mriedem | pump those brakes | |
| 22:29:59 | openstackgerrit | melanie witt proposed openstack/nova stable/ocata: Fix false positive server group functional tests https://review.openstack.org/536995 | |
| 22:29:59 | openstackgerrit | melanie witt proposed openstack/nova stable/ocata: Set server status to ERROR if rebuild failed https://review.openstack.org/536904 | |
| 22:30:15 | jroll | don't be a jackhole is definitely the best advice though | |
| 22:30:24 | mriedem | ha, that reminds me - saw a minivan racing down the hill towing like 6 kids on a sled yesterday, | |
| 22:30:31 | mriedem | if they would have had to stop short, all of those kids could have been destoryed | |
| 22:30:33 | mriedem | *destroyed | |
| 22:31:20 | Roamer` | well, they *might* have been able to roll to the side, fall off the sled, but still... no, not a good image at all | |
| 22:31:47 | mriedem | the ones that are destined to pass on their genes, yes they might have had the instinct | |
| 22:32:03 | mriedem | or, be in the back | |
| 22:32:48 | melwitt | *facepalm* | |
| 22:32:52 | dansmith | mriedem: hadn't even gotten that far actually, but yeah, newer code will probably need to handle the case and transform older ones to newer ones | |
| 22:33:22 | dansmith | mriedem: and yes, that's related enough to what I was saying about passing this dict of allocations/resources around to need some wrapage | |
| 22:34:13 | mriedem | i guess you could determine format based on whether or not the 'allocations' entry within is a list or dict, and swaparoo if it's not a dict | |
| 22:35:11 | dansmith | for this case I think it can be done, yeah, but it's not a good precedent | |
| 22:36:24 | mriedem | agree | |