| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-28 | |||
| 00:19:40 | superdan | yeah | |
| 00:19:42 | mriedem | so do we make it 65_placement? | |
| 00:19:45 | superdan | no, | |
| 00:19:51 | superdan | because then computes will not start in 60_nova | |
| 00:19:52 | mriedem | although nova depends on placement | |
| 00:19:53 | superdan | they will bail | |
| 00:19:55 | mriedem | yeah | |
| 00:19:56 | mriedem | fuck | |
| 00:20:05 | mriedem | so.... | |
| 00:20:06 | ptcBRO | Hey guys, I have instances with invalid data in the instance.info_cache. Is there a recommended way to invalidate this cache? | |
| 00:20:11 | superdan | I think we have to revert to before this change, minus the inflamatory correctness checking I had in there | |
| 00:20:21 | mriedem | superdan: couldn't we install nova from 55_placement? | |
| 00:20:27 | mriedem | i asked about that in your change actually | |
| 00:20:40 | mriedem | re-installing it from 60_nova is just redundant | |
| 00:20:42 | mriedem | but who cares | |
| 00:20:48 | superdan | mriedem: no | |
| 00:20:57 | superdan | mriedem: because it will install new nova before we have a chance to do things like from-newton and stuff | |
| 00:21:15 | superdan | and within-newton, more specifically | |
| 00:21:44 | mriedem | ok i'll just trust you | |
| 00:21:53 | superdan | surely you don't think that's legit anyway right? | |
| 00:21:57 | mriedem | you're the 2nd most knowledgeable grenadier in openstack now :) | |
| 00:22:04 | superdan | it would be like newton upgrading nova because whatever.. | |
| 00:22:15 | superdan | if it's a separate service, it needs to be self-contained, right? | |
| 00:22:22 | mriedem | yar | |
| 00:23:40 | mriedem | cool, well, at least i feel like we're getting closer | |
| 00:23:49 | mriedem | and by we, i mean you | |
| 00:23:50 | mriedem | :) | |
| 00:23:54 | superdan | really? because now we're where we were 24 hours ago | |
| 00:24:06 | superdan | I'm not at all impressed | |
| 00:24:24 | mriedem | superdan: need to call out anything in the commit message about why it has to be this way for when sdague asks? | |
| 00:24:49 | superdan | I was just going to do a comment on it, but I can I guess | |
| 00:25:09 | superdan | I just want to merge this shit and have a weekend, I'm becoming less interested in the minutia | |
| 00:25:11 | mriedem | either/or, i left a comment too | |
| 00:25:19 | mriedem | just leave it | |
| 00:25:34 | mriedem | i've rechecked the nova patch | |
| 00:26:14 | superdan | I just pushed again | |
| 00:26:20 | superdan | had to remove the bit about counting services anyway | |
| 00:26:30 | superdan | let me address your nit on the exception | |
| 00:26:49 | mriedem | breaks within-$release and my brain | |
| 00:26:50 | mriedem | ha | |
| 00:28:20 | superdan | I meant the idea of trying to pre-upgrade from another service is uncool | |
| 00:29:23 | openstackgerrit | Dan Smith proposed openstack/nova: Scheduler calling the Placement API https://review.openstack.org/417961 | |
| 00:29:23 | openstackgerrit | Dan Smith proposed openstack/nova: Block starting compute unless placement conf is provided https://review.openstack.org/425806 | |
| 00:50:40 | mriedem | notifications functional test failed, simple recheck | |
| 00:50:56 | superdan | functional failure on that 7!=8 thing | |
| 00:50:57 | superdan | heh | |
| 00:56:15 | mriedem | yeah - related to that https://review.openstack.org/#/c/424574/ | |
| 00:56:20 | mriedem | if you want to +W if you're happy with it | |
| 00:56:28 | mriedem | i'm not sure about time.clock() vs time.time() in there | |
| 00:56:36 | mriedem | i feel like pythonistas would flame that up | |
| 00:57:24 | melwitt | I was looking at that earlier and wondering, is there really no way to do notifications synchronously for tests? it's using eventlet etc | |
| 00:58:33 | superdan | maybe later, I'm breaking for at bit | |
| 00:59:03 | mriedem | melwitt: do we spawn(_n) the notifications> | |
| 00:59:04 | mriedem | ? | |
| 00:59:33 | mriedem | we could set those tests to REQUIRES_LOCKING=True | |
| 00:59:43 | mriedem | if they use spawn/spawn_n we can make those synchronous too | |
| 01:00:21 | melwitt | mriedem: I don't really understand it yet, but was looking at nova/tests/unit/fake_notifier.py | |
| 01:00:39 | mriedem | we could also use SpawnIsSynchronousFixture | |
| 01:01:01 | melwitt | I think you already added that | |
| 01:02:09 | melwitt | in the FakeNotifier, the SUBSCRIBERS are threading.Events that it waits on | |
| 01:03:09 | melwitt | well, if you call wait_for_versioned_notification(), which is what the proposed patch is doing, I think | |
| 01:13:10 | melwitt | we have a RPCFixture which configures the driver to the 'fake' one provided by oslo.messaging, but I don't see that we do anything similar for notifications. there's a 'test' driver for testing and I wonder if we could use that somehow https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/notify/_impl_test.py | |
| 01:14:44 | melwitt | I don't know what driver is currently being used. there's no default in oslo.messaging and I don't find it configured in nova anywhere | |
| 01:16:13 | mriedem | idk either, gibi probably does | |
| 01:17:24 | mriedem | single-node grenade is happy now on the scheduler change | |
| 01:18:30 | melwitt | yeah, I should ask on the review. just seems weird to have to wait for an async notification in a test | |
| 01:18:54 | mriedem | and grenade multinode | |
| 01:22:05 | ptcBRO | Hey guys, I have instances with invalid data in the instance.info_cache. Is there a recommended way to invalidate this cache? | |
| 01:38:55 | mriedem | ptcBRO: there is a periodic task on the compute node that will refresh the cache automatically | |
| 01:39:39 | mriedem | otherwise i think you have to reset it in the db directly, i don't know of a REST API to refresh it manually | |
| 01:40:07 | ptcBRO | mriedem: does that periodic task exist in Juno? | |
| 01:40:20 | mriedem | ptcBRO: yeah i think so | |
| 01:40:31 | mriedem | heal_info_cache or something like that | |
| 01:40:34 | mriedem | heal_instance_info_cache | |
| 01:41:11 | mriedem | ptcBRO: https://github.com/openstack/nova/blob/juno-eol/nova/compute/manager.py#L5368 | |
| 01:41:25 | ptcBRO | mriedem: thank you | |
| 01:43:09 | mriedem | melwitt: i'd love it if we could get this in https://review.openstack.org/#/c/403925/ - i get tired of the InstanceNotFound stacktraces all over the logs in CI runs | |
| 01:48:49 | melwitt | mriedem: I've seen those and would also like to get rid of them. will review | |
| 02:35:32 | diana_clarke | man, did I ever mess up this rebase... poor friday night choices | |
| 02:57:15 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 verify_instance https://review.openstack.org/421436 | |
| 02:57:15 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 delete_cell https://review.openstack.org/421459 | |
| 02:57:16 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 discover_hosts https://review.openstack.org/421442 | |
| 02:57:16 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 list_cells https://review.openstack.org/421458 | |
| 02:57:17 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 create_cell https://review.openstack.org/421444 | |
| 03:01:47 | oomichi | mriedem: I saw your mail: http://lists.openstack.org/pipermail/openstack-dev/2017-January/111137.html | |
| 03:02:11 | oomichi | mriedem: I could not find any related changes since 1/21 | |
| 03:03:35 | oomichi | devstack changes live_migration False on tempest.conf, but devsack-gate makes it True. And there are not any changes related to that recently | |
| 03:12:00 | mriedem | oomichi: yeah it's a mystery | |
| 03:12:12 | mriedem | i checked the git logs on devstack, grenade, nova, tempest and d-g | |
| 03:16:47 | oomichi | mriedem: I guess https://review.openstack.org/426461 can help | |
| 03:17:15 | oomichi | mriedem: but I still am not sure why this happens recently | |
| 03:17:36 | mriedem | superdan: so the nova changes are approved, what should we do about the grenade change? | |
| 03:17:51 | mriedem | i guess wait for sdague on monday? | |
| 03:20:25 | oomichi | mriedem: oh, mine is wrong | |
| 03:21:17 | mriedem | oomichi: d-g is setting it correctly http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/console.html#_2017-01-27_23_16_09_271784 | |
| 03:21:30 | mriedem | it's just that for whatever reason, it's not getting set in tempest.conf from within devstack | |
| 03:22:53 | oomichi | nice hint. Yeah that seems mystery.. | |
| 03:29:07 | mriedem | i'm wondering if the devstack-tools thing is messing something up | |
| 03:29:13 | mriedem | but i don't know enough about that change | |
| 03:29:35 | mriedem | but for example, NOVA_ALLOW_MOVE_TO_SAME_HOST=False is in local.conf | |