Earlier  
Posted Nick Remark
#openstack-nova - 2017-06-13
17:59:55 mriedem but not so worried that i'm going to do a thorough audit right now :)
18:00:50 dansmith well, lack of test coverage is lack of test coverage
18:01:00 dansmith we're hitting one thing right here before real people do, so...
18:01:16 mriedem so kudos to us
18:01:46 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.rebuild-scheduled notification https://review.openstack.org/473929
18:06:27 mriedem cfriesen: something still failing here https://review.openstack.org/#/c/435141/
18:11:35 dansmith mriedem: there aren't even unit tests for that bit of HostAPI
18:12:11 mriedem nice
18:12:23 mriedem i've noticed we test the rest api but not the host api so well
18:15:58 dansmith I don't see rest tests for this either
18:24:04 sdague mriedem: oh, it's just a flat out broken sphinx thing
18:24:09 sdague gdi
18:24:41 cfriesen mriedem: we found the bug in https://review.openstack.org/#/c/465787 and I updated the review
18:26:56 cfriesen mriedem: I think that's new after rebasing...I only reran the test_shell unit tests after changing stuff
18:28:48 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Canary https://review.openstack.org/473565
18:28:49 openstackgerrit Dan Smith proposed openstack/nova master: Make compute_node_statistics() work across cells https://review.openstack.org/473931
18:29:28 cfriesen mriedem: this is weird...novaclient.tests.unit.test_client.SessionClientTest.test_global_id passes locally
18:30:41 cfriesen mriedem: and I didn't change anything related to that code, that I can see at least
18:37:21 cfriesen mriedem: locally it looks fine. what's with the key.lower() in the traceback of the failing test at http://logs.openstack.org/41/435141/13/check/gate-python-novaclient-python27-ubuntu-xenial/df4a44b/testr_results.html.gz ?
18:42:07 cfriesen andreykurilin: can you see any reason why https://review.openstack.org/#/c/473910 would cause the failure in test_global_id at http://logs.openstack.org/10/473910/1/check/gate-python-novaclient-python27-ubuntu-xenial/76e7e46/testr_results.html.gz ?
18:44:18 mriedem cfriesen: the global id thing is being fixed
18:44:23 mriedem sdague has a patch for it
18:45:17 mriedem cfriesen: good catch on https://review.openstack.org/#/c/465787/3/nova/network/neutronv2/api.py@2322
18:56:21 cfriesen mriedem: can't take credit personally...we ran into it during testing and one of the guys tracked it down
18:57:43 cfriesen mriedem: you okay with https://review.openstack.org/#/c/435141/ otherwise, or did you still have issues with the json blob output?
18:58:00 mriedem haven't looked at it yet
18:58:06 mriedem getting https://review.openstack.org/#/c/473224/ sorted out
18:58:09 cfriesen kay, no worries
18:59:33 mriedem cfriesen: i definitely don't like dumping a json blob in a table cell,
18:59:39 mriedem but as you replied, we do it elsewhere
19:00:45 mriedem the alternative is we dump the flavor name
19:00:51 mriedem with the server details
19:01:00 mriedem and then if you want details on the flavor, you do nova flavor-show <flavor name>
19:03:57 bauzas mriedem: dansmith: just a note that I'll be on PTO tomorrow
19:04:16 mriedem ok
19:04:59 bauzas that, next week and the other week
19:05:39 cfriesen mriedem: that doesn't work if the flavor is deleted or modified though
19:05:52 mriedem cfriesen: true
19:06:07 mriedem cfriesen: would be nice at least to dump key-value pairs in a table cell rather than a json blob
19:06:13 mriedem but i don't know how easy that is
19:06:19 mriedem with prettytable
19:06:42 mriedem we might have done something like that with nova-status, checking
19:07:08 cfriesen mriedem: the output currently looks like this: http://paste.openstack.org/show/612457/
19:07:30 sdague mriedem: fyi - https://review.openstack.org/473941 is what was needed to get your api-ref warnings emitted
19:07:35 mriedem cfriesen: yikes
19:08:08 mriedem sdague: any idea if that works with sphinx 1.5.1? https://github.com/openstack/requirements/blob/master/global-requirements.txt#L412
19:08:33 mriedem sdague: also curious for your opinion on embedding the nested flavor in the server show ouput as a json blob http://paste.openstack.org/show/612457/
19:08:58 mriedem i personally think that's ugly, but we also do it for volume attachments and extra specs in the flavor-show output
19:09:43 cfriesen I'm not wedded to it, happy to do something better
19:09:58 cfriesen just don't know what other options we have
19:11:46 mriedem cfriesen: i'd prefer to see it like this somehow http://paste.openstack.org/show/612458/
19:11:51 mriedem but not sure how easy that is
19:13:15 sdague mriedem: I don't yet, still puttering through this
19:13:44 sdague mriedem: I agree, I think it should be unrolled
19:13:54 cfriesen mriedem: that'd make functional tests a bit of a mess, trying to correlate that against the output of "flavor show"
19:14:18 cfriesen I guess we could take the "flavor show" output and mangle it into that format and then compare
19:14:34 sdague um, why isn't this just flavor_ ephemeral
19:14:41 sdague flavor_ram
19:14:44 sdague etc
19:14:51 mriedem could be namespaced
19:14:52 mriedem that's an option
19:15:19 sdague if you are putting the output in the tables, it should be table friendly data
19:15:45 sdague or flavor:ram
19:15:54 cfriesen sdague: I was just following the existing pattern where the "flavor" entry had the name and the id on one line
19:16:06 sdague cfriesen: right, but that was a key
19:16:08 mriedem sure, but now it's more than id
19:16:12 sdague mriedem: ++
19:16:47 mriedem cfriesen: i'd think it would be pretty easy to transform that to flavor_ namespaced keys in the server resp body object before sending it to the table output formatter
19:17:03 mriedem there might even be a callback function available with the output formatter
19:17:07 cfriesen agreed. you want "flavor_" or "flavor:"?
19:17:23 mriedem hmm
19:17:29 sdague I think flavor:
19:17:33 mriedem you're treading on OS-SRV-EXT territory :)
19:17:38 sdague mriedem: sure
19:17:46 mriedem i'm cool with flavor:
19:17:52 mriedem makes it more namespacey
19:17:54 sdague yep
19:18:05 cfriesen okay, will give that a try
19:22:06 openstackgerrit Matt Riedemann proposed openstack/nova master: Pull out code that builds VIF in _build_network_info_model https://review.openstack.org/466449
19:22:07 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Handle network-changed event for a specific port https://review.openstack.org/465787
19:41:01 mriedem no artom?!
19:41:19 mriedem kashyap: i assume if i see this in the libvirtd logs, it means it's a persistent domain: "Writing domain status to disk"
19:41:35 mriedem well i already know it's a persistent domain, so nm
20:02:59 openstackgerrit Merged openstack/nova master: Remove old service version check for mitaka https://review.openstack.org/472395
20:18:05 openstack Launchpad bug 1696125 in OpenStack Compute (nova) "Detach interface failed - Unable to detach from guest transient domain (pike)" [High,Confirmed] - Assigned to Matt Riedemann (mriedem)
20:18:05 mriedem sgordon: you might like this https://bugs.launchpad.net/nova/+bug/1696125/comments/16 - we have a bug where detaching an ethernet tap device takes ~5 minutes to be gone from the guest
20:18:08 mriedem using linuxbridge
20:18:23 mriedem nova waits ~1-2 minutes for the device to be gone before giving up
20:18:47 mriedem i've done the libvirtd log digging
20:19:04 mriedem not sure if this is a problem in libvirt/qemu or if it's expected to take this long
20:19:09 mriedem not a problem for ovs
20:19:37 sgordon mmm, and if i am perfectly honest most of the testing on our end focuses on ovs these days
20:22:15 mriedem we could bump this timeout for tap devices, but that's just a workaround, and i believe the tempest tests would actually timeout before that
20:23:18 mriedem tempest times out just at 5 minutes
20:23:26 mriedem so it'd be a craptacular race to the bottom
20:24:27 sgordon mriedem, i would like to think it should not in fact take > 1 minute but i will track down someone who is actually intelligent to look at it
20:24:32 sgordon :)
20:25:05 mriedem sgordon: fwiw the neutron side reverted the change to use vif_type='tap' with linuxbridge https://review.openstack.org/#/c/472365/
20:25:12 mriedem interested to know why that would make a difference
20:25:41 mriedem the vif_type is now using 'bridge' again

Earlier   Later