| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-28 | |||
| 00:15:53 | superdan | multinode doesn't care though | |
| 00:15:54 | mriedem | it's just that we don't fail in the multinode grenade job b/c the scheduler doesn't use placement b/c of the newton compute | |
| 00:15:56 | mriedem | right | |
| 00:15:59 | mriedem | single-node cares, and dies | |
| 00:16:04 | superdan | hmm | |
| 00:16:05 | mriedem | b/c the scheduler needs ocata placement | |
| 00:16:14 | superdan | I don't know where we actually update the git tree though | |
| 00:16:19 | superdan | but I can totally believe that | |
| 00:16:50 | mriedem | yeah i don't see where the stack happens on the target side | |
| 00:16:58 | superdan | we don't stack | |
| 00:17:09 | superdan | I should have fought harder to merge the shit we had working this morning | |
| 00:17:39 | superdan | perfect timing for sdague to leave | |
| 00:18:18 | mriedem | did that work with single-node grenade? | |
| 00:18:49 | superdan | yeah, | |
| 00:18:55 | superdan | because we did it inside the nova service | |
| 00:19:00 | superdan | stack_install_service nova | |
| 00:19:03 | superdan | is where it is upgraded I bet | |
| 00:19:07 | mriedem | oh, | |
| 00:19:10 | mriedem | YEAH | |
| 00:19:11 | mriedem | mfer | |
| 00:19:13 | superdan | which we have not done in 55_placement of course | |
| 00:19:15 | mriedem | so 55_placement again | |
| 00:19:19 | mriedem | bites our arseholes | |
| 00:19:19 | superdan | le sigh | |
| 00:19:23 | mriedem | la creme | |
| 00:19:26 | superdan | right, that's my point above about not fighting harder | |
| 00:19:37 | mriedem | fuck a duck | |
| 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 | |