Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-07
18:58:56 cdent (sorry, line 37)
18:59:50 mriedem cdent: i'm not so sure https://github.com/openstack/nova/blob/master/nova/rpc.py#L292
19:00:10 cdent indeed
19:00:21 openstackgerrit Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
19:00:22 openstackgerrit Dan Smith proposed openstack/nova master: Enlighten server tags API about cells https://review.openstack.org/440856
19:00:22 openstackgerrit Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162
19:00:23 openstackgerrit Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163
19:00:23 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022
19:00:24 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023
19:00:24 openstackgerrit Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891
19:00:25 openstackgerrit Dan Smith proposed openstack/nova master: Make consoleauth target the proper cell https://review.openstack.org/441461
19:00:25 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
19:00:26 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
19:00:26 openstackgerrit Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388
19:00:27 openstackgerrit Dan Smith proposed openstack/nova master: Teach os-aggregates about cells https://review.openstack.org/442200
19:00:27 openstackgerrit Dan Smith proposed openstack/nova master: Teach os-migrations about cells https://review.openstack.org/442685
19:00:42 cdent even if it is problem, based on the conversations we've had with searchlight in the past they've strenuously said: we will make this work...
19:04:33 mriedem gibi: do you know where the compute. prefix shows up in the unversioned legacy notifications?
19:04:43 mriedem cdent: yeah also https://blueprints.launchpad.net/searchlight/+spec/nova-versioned-notifications
19:05:40 cdent ack
19:11:24 cdent i have continuouspartialattentionitis
19:11:49 mriedem i have a headache staring at this notification code
19:12:08 mriedem i think we've also changed compute.instance.create.start to conductor.instance.create.start
19:12:16 mriedem maybe
19:15:58 openstackgerrit Jay Pipes proposed openstack/nova master: placement: standard memory page resource classes https://review.openstack.org/442718
19:17:19 mriedem cdent: i think this is where we get the compute. prefix on the unversioned notification https://github.com/openstack/nova/blob/master/nova/compute/utils.py#L324
19:17:26 mriedem versioned is https://github.com/openstack/nova/blob/master/nova/compute/utils.py#L356
19:17:29 mriedem which doesn't have the prefix
19:18:26 cdent that seems rather unfortunate
19:18:32 cdent he said blandly
19:21:58 mriedem i assume that was intentional
19:22:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Update docstrings for legacy notification methods https://review.openstack.org/442723
19:23:18 cdent I know that there was intention to make it so you could have both of them going at the same time, but from the consumer side, having different names (instead of different topics (is that right, I'm not sure of the nomenclature)) makes switching harder
19:23:35 mriedem by default nova is configured to send both
19:24:09 mriedem http://logs.openstack.org/59/382959/17/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f2fe0de/logs/screen-n-cpu.txt.gz#_2017-03-06_14_39_55_787
19:24:16 mriedem notifications.notification_format = both
19:24:35 mriedem http://logs.openstack.org/59/382959/17/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/f2fe0de/logs/screen-n-cpu.txt.gz#_2017-03-06_14_39_55_756
19:24:43 mriedem i only see the one topic
19:24:43 mriedem oslo_messaging_notifications.topics = ['notifications']
19:27:12 mriedem https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/versioned-notification-transformation-newton.html#notifications-impact
19:27:18 mriedem "As implemented in the versioned-notification-api bp the versioned notifications are always emitted to a different amqp topic called ‘versioned_notifications’ so the consumer can differentiate between the legacy and the new format by the topic."
19:27:28 mriedem i'm not sure that's true
19:28:19 mriedem what i think i'd like to see, is some docs in https://docs.openstack.org/developer/nova/notifications.html about how to actually configure / set things up to use this
19:28:30 openstackgerrit Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736
19:28:36 mriedem because i'm putting this together, shittily, from code and old specs
19:30:54 cdent everyone else has continuouspartialattentionitis too
19:31:27 mriedem oh i see it https://github.com/openstack/nova/blob/master/nova/rpc.py#L92
19:31:40 mriedem the default topic is 'notifications'
19:31:46 mriedem which is why the legacy notifier doesn't define a topics kwarg
19:31:53 mriedem so we're sending to separate topics
19:31:58 mriedem with different event types
19:32:11 openstackgerrit Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754
19:32:11 openstackgerrit Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162
19:32:12 openstackgerrit Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163
19:32:12 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022
19:32:13 openstackgerrit Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023
19:32:13 openstackgerrit Dan Smith proposed openstack/nova master: Teach os-migrations about cells https://review.openstack.org/442685
19:32:14 dansmith jaypipes: guh, sorry, pep8 fail on the _second_ friggin patch
19:32:14 openstackgerrit Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891
19:32:14 openstackgerrit Dan Smith proposed openstack/nova master: Make consoleauth target the proper cell https://review.openstack.org/441461
19:32:15 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
19:32:15 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
19:32:16 openstackgerrit Dan Smith proposed openstack/nova master: Teach simple_tenant_usage about cells https://review.openstack.org/441388
19:32:16 openstackgerrit Dan Smith proposed openstack/nova master: Teach os-aggregates about cells https://review.openstack.org/442200
19:32:17 openstackgerrit Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736
19:35:43 jaypipes dansmith: damn you, Smith!
19:40:13 dansmith I know, I suck
19:54:46 mriedem dansmith: found your issue
19:54:46 mriedem http://logs.openstack.org/94/436094/12/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/051cffa/logs/screen-n-api.txt.gz#_2017-03-07_00_14_09_285
19:55:17 mriedem something jacked with the compute service version
19:55:54 mriedem https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L448
20:08:10 openstackgerrit Sarafraj Singh proposed openstack/nova-specs master: WIP: Add live-migration-force-after-timeout spec https://review.openstack.org/438467
20:09:13 openstackgerrit Sarafraj Singh proposed openstack/nova-specs master: Add live-migration-force-after-timeout spec https://review.openstack.org/438467
20:09:51 dansmith mriedem: oh I bet it's just that we need to check all cells
20:09:55 dansmith mriedem: for the service version
20:09:58 dansmith mriedem: thanks for that
20:10:21 mriedem \o/
20:12:02 dansmith yeah, that's an easy fix
20:12:17 dansmith alternately we can probably remove that as it's for mitaka computes right?
20:12:45 efried Did flake8 get an upgrade recently? Suddenly my imports are wrong.
20:14:37 mriedem dansmith: maybe?
20:15:12 mriedem dansmith: we have this talk every few weeks about supporting n-2 vs handling service version checking
20:15:27 mriedem we don't support n-2 officially, we don't test that way,
20:15:39 mriedem but we don't have anything that says what the minimum required compute is either
20:15:43 dansmith mriedem: we've never supported anything beyond n-1,
20:15:51 dansmith mriedem: we do because n-2 computes will refuse to start
20:15:53 mriedem we could use nova-status upgrade check mofo ftw
20:16:14 dansmith mriedem: you literally can't start n-2 computes, I think that's pretty clear messaging :)
20:16:26 mriedem why?
20:16:34 dansmith why is that clear or why can you not?
20:16:38 mriedem why can you not?
20:16:51 dansmith the service checkin will refuse to roll the minimum version back
20:17:10 mriedem but what if i never restarted the compute and i've just got a mitaka compute still running
20:18:00 dansmith mriedem: you likely wouldn't have been able to complete online migrations, and thus never have been able to apply ocata schema migrations, etc
20:18:15 dansmith mriedem: we've had those kinds of deps before, not sure if we really have had them between mitaka and ocata, but..
20:18:29 mriedem to be clear, you're talking about this? https://github.com/openstack/nova/blob/master/nova/objects/service.py#L304
20:18:32 dansmith it's always been a blanket policy, I'm not sure why we're suddenly concerned about it
20:18:40 dansmith yeah
20:18:54 mriedem "This could happen if we were started with older code by accident, either due to a rollback or an old and un-updated node suddenly coming back onto the network."
20:19:03 mriedem so i get that, like with an evacuated node

Earlier   Later