| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-07-17 | |||
| 16:08:45 | stephenfin | mriedem: That patchset passed the gate checks on Jul 9 13:54. I'm guessing this is an intermittent gate issue? | |
| 16:09:19 | stephenfin | The other rechecks were necessary because the patch below wasn't merging, I think | |
| 16:12:45 | mriedem | stephenfin: ok all failures are in cleaning up network resources | |
| 16:12:50 | mriedem | so looks like some new regression on the neutron side | |
| 16:13:18 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22pymysql.err.InternalError%3A%20(1305%2C%20'SAVEPOINT%20sa_savepoint_6%20does%20not%20exist')%5C%22%20AND%20tags%3A%5C%22screen-q-svc.txt%5C%22&from=7d | |
| 16:17:55 | mriedem | actually that's showing up a ton in successful jobs too, so that's not it, | |
| 16:17:58 | mriedem | it's likely this: | |
| 16:17:58 | mriedem | sqlalchemy.exc.InvalidRequestError: Could not refresh instance '<Router at | |
| 16:18:45 | mriedem | only 2 hits in logstash on that though, so maybe just totally random | |
| 16:19:05 | stephenfin | That's purely a neutron thing though, I'm assuming, given that I'm only consuming things in any of those patches | |
| 16:19:08 | mriedem | efried: gibi: the neutron change under this is approved now https://review.openstack.org/#/c/523604/ | |
| 16:19:16 | mriedem | stephenfin: agree | |
| 16:19:26 | stephenfin | phew | |
| 16:19:33 | mriedem | did you fart? | |
| 16:19:56 | stephenfin | not this time | |
| 16:20:44 | mriedem | melwitt: i'm going to throw https://blueprints.launchpad.net/nova/+spec/neutron-new-port-binding-api back into a runway slot since the dependent neutron change at the bottom is approved now and the bottom half of the series has +2s on it | |
| 16:21:11 | efried | mriedem: Is it legit to merge the bottom five patches at this point? | |
| 16:21:17 | mriedem | yeah | |
| 16:21:22 | efried | mriedem: Or will that make dansmith hate us for merging partial function? | |
| 16:21:22 | mriedem | it's all neutron api plumbing | |
| 16:21:30 | mriedem | none of this series is 'on' until the very end | |
| 16:21:40 | mriedem | we're mergin partial function on stephenfin's series too | |
| 16:21:45 | efried | Hate us *more*, that is. | |
| 16:22:40 | efried | mriedem: Okay, +W'd the bottom five. | |
| 16:22:44 | mriedem | thanks | |
| 16:25:22 | efried | mriedem: "random dict of terrible boat"? | |
| 16:26:08 | mriedem | correct | |
| 16:26:38 | mriedem | vif_details and profile in a neutron port are like the connection_info in a volume, | |
| 16:26:44 | mriedem | totally backend dependent and unversioned | |
| 16:31:06 | sean-k-mooney | mriedem: well not quite. the standard keys are defiend in the port_bindings api extention. addtion backend keys can be added as vendor extentions and it is unversioned | |
| 16:31:35 | efried | I just don't know what "boat" is doing in that description. | |
| 16:31:57 | sean-k-mooney | mriedem: the binding profile can be set by the end user so it can have anything in it that fits in the db filed. | |
| 16:32:12 | mriedem | efried: they are in the same "random dict of terrible" boat | |
| 16:32:17 | mriedem | it's a boat called "random dict of terrible" | |
| 16:32:26 | mriedem | and profile is a passenger alongside vif_details | |
| 16:32:32 | efried | ahhh, I see now. | |
| 16:32:36 | mriedem | heh | |
| 16:33:08 | mriedem | sean-k-mooney: gross | |
| 16:33:09 | efried | would be clearer as "...in the same random-dict-of-terrible boat..." | |
| 16:33:57 | sean-k-mooney | efried: part of creating os-vif was to sink that boat and have neutron return serialised vif object in the future. | |
| 16:34:15 | sean-k-mooney | may next release. or the one after | |
| 16:35:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove support for /os-floating-ip-dns REST API https://review.openstack.org/582943 | |
| 16:35:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove "DEPRECATED" tag from Obsolete APIs https://review.openstack.org/583092 | |
| 16:36:53 | mriedem | once that dns one is approved ^ we can probably close out that bp for rocky | |
| 16:37:06 | mriedem | stephenfin: thanks for hitting those when the call for help was raised | |
| 16:37:37 | stephenfin | mriedem: np | |
| 16:43:42 | s10 | Can anyone confirm, that this is a bug on the nova side? https://bugs.launchpad.net/nova/+bug/1781880 | |
| 16:43:43 | openstack | Launchpad bug 1781880 in OpenStack Compute (nova) "nova service-list for new compute service causes TypeError with servicegroup_driver mc " [Undecided,Confirmed] | |
| 16:46:56 | s10 | We currently have to execute "update nova.services set updated_at = NOW() where updated_at is NULL" after every new node with nova-compute addition, which looks strange to do. We didn't have such issue before Pike. | |
| 16:47:11 | mriedem | s10: your analysis on the problem looks correct | |
| 16:47:26 | mriedem | we don't have much rigorous testing with the enable_new_services config option | |
| 16:47:30 | mriedem | or the MC driver for that matter | |
| 16:48:15 | mriedem | looks like the logic should be: | |
| 16:48:15 | mriedem | if updated_time_in_mc: | |
| 16:48:17 | mriedem | oops | |
| 16:48:24 | mriedem | if updated_time_in_mc and updated_time_in_db: | |
| 16:51:01 | mriedem | we could probably easily recreate this with a test that uses the oslo.cache.dict backend | |
| 16:51:10 | mriedem | *oslo_cache.dict | |
| 16:51:27 | mriedem | set the config options appropriately, start a compute service and see it blow up | |
| 17:13:07 | sean-k-mooney | efried: mriedem stephenfin mind taking a look at https://review.openstack.org/#/c/559398/ before ye head home today | |
| 17:13:56 | efried | sean-k-mooney: Did you see my comment there? | |
| 17:14:03 | efried | I guess maybe I'm looking for stephenfin to answer it. | |
| 17:14:04 | openstackgerrit | Merged openstack/nova master: Fix a newly introduced UUID warning in the unit test https://review.openstack.org/583205 | |
| 17:14:20 | sean-k-mooney | efried: just saw it now | |
| 17:14:45 | sean-k-mooney | am yes but then agin if we dont we are not testing if the lower contraitns are vaild for the doc requiremetns | |
| 17:15:13 | efried | I get that, I get that. But... do we care? | |
| 17:15:40 | sean-k-mooney | do we care if the unit tests run. technically we could just see if everything installs | |
| 17:16:49 | sean-k-mooney | if we are going to check lower-constratins for docs then we should build the docs. if not then we should not | |
| 17:17:13 | sean-k-mooney | we shoudl proably do the same for nova and the rest but that leaves the question do we care | |
| 17:20:14 | efried | meh, okay, +2 sean-k-mooney | |
| 17:38:11 | openstackgerrit | Merged openstack/nova master: Escalate UUID validation warning to error in test https://review.openstack.org/540386 | |
| 18:00:11 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 18:32:15 | openstackgerrit | Eric Fried proposed openstack/nova master: perform reshaper operations in single transaction https://review.openstack.org/582383 | |
| 18:32:16 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: [placement] Add /reshaper handler for POST https://review.openstack.org/576927 | |
| 18:32:17 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Compute: Handle reshaped provider trees https://review.openstack.org/576236 | |
| 18:38:30 | openstackgerrit | sean mooney proposed openstack/os-vif master: convert os-vif docs to follow PTI https://review.openstack.org/559398 | |
| 18:47:17 | mriedem | new theory on http://status.openstack.org/elastic-recheck/#1781710 | |
| 18:47:28 | mriedem | members = set(spec_obj.instance_group.members) is empty by the time the filter runs | |
| 18:48:20 | openstackgerrit | sean mooney proposed openstack/nova master: update tox venv env to install all requirements https://review.openstack.org/583336 | |
| 18:50:14 | sean-k-mooney | mriedem: since you are still looking at that im assuming the fixed released status of the bug is incorrect? | |
| 18:50:22 | mriedem | correct | |
| 18:50:29 | mriedem | although i can't recreate it locally with a functional test | |
| 18:52:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add regression test for bug 1781710 https://review.openstack.org/583339 | |
| 18:53:00 | openstack | bug 1781710 in OpenStack Compute (nova) "ServersOnMultiNodesTest.test_create_server_with_scheduler_hint_group_anti_affinity failing with "Servers are on the same host"" [High,Fix released] https://launchpad.net/bugs/1781710 - Assigned to Matt Riedemann (mriedem) | |
| 18:53:00 | mriedem | ^ | |
| 18:56:34 | mriedem | i think this might be causing problems https://github.com/openstack/nova/blob/master/nova/scheduler/filters/affinity_filter.py#L98 | |
| 18:57:22 | mriedem | actually it's something else | |
| 18:57:29 | mriedem | reqspec.instance_group.members is 0 | |
| 18:58:29 | sean-k-mooney | on line 103 | |
| 18:58:39 | mriedem | yes | |
| 18:58:48 | mriedem | but then i'm not sure why my functional regression test would be passing | |
| 18:58:58 | mriedem | b/c i've added a custom weigher which should put each instance on it's own host | |
| 19:00:04 | sean-k-mooney | well its anti afinity so is that not the desired result? | |
| 19:00:52 | sean-k-mooney | im just reading over the regression test code. i dont dig into the functional tests often | |
| 19:01:48 | mriedem | actually the thing in the api doesn't matter, because prior to scheduling, conductor calls setup_instance_group which gets the current group information from the db which should have the current members in it | |
| 19:01:52 | mriedem | before they get to the filter | |
| 19:04:25 | sean-k-mooney | my knoladge of multi create is a little less clear then it should be. all instace in the multicreate are part of the same api request. are all instance schduled indepently or does the schduler process the batch of instance as one request. | |
| 19:05:13 | mriedem | the scheduler processes the batch as one request, | |
| 19:05:21 | mriedem | and as a host is selected per instance, | |
| 19:05:46 | mriedem | the scheduler 'consumers' resources for the in-memory representation of that host, | |