Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-05
20:53:53 jaypipes edleafe: we don't currently add the user and project ID into the allocation_request object in the return from GET /allocation_candidates
20:54:04 jaypipes edleafe: unfortunately. was an oversight on my part.
20:54:18 jaypipes edleafe: I'm sure dansmith at some point told me to put it in there and I just forgot.
20:54:36 dansmith it doesn't matter, because 'latest' is not the version used by the scheduler (in the future when we're doing things correctly and placement is external)
20:56:24 cdent so if scheduler and placement are out of sync, grind
20:56:56 dansmith when placement is external, we must tolerate them being out of sync
20:59:32 edleafe oh, geez, I give up. I missed this: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L154
20:59:48 edleafe Forget everything I said about a-rs being opaque
21:00:00 mriedem yes i remember pointing out late in pike that we needed to update nova-status' check for the required minimum placement microversion to be 1.10 because that's what the scheduler was requesting during claim_resources
21:00:01 edleafe that ship has sailed.
21:00:14 mriedem we really only needed 1.8 for the user_id/project_id thing (i think?)
21:00:56 mriedem and we had to put something in the release notes saying you have to make sure to upgrade placement before scheduler since scheduler requires this new higher microversoin in placement that wasn't available in ocata
21:01:08 edleafe I'm going to finish the stuff I've been trying to work on and then I'll rethink how to change the series to add a versioned allocation_request to the Selection object
21:01:29 mriedem if the pike scheduler was requesting 'latest' to an ocata placement, the request might pass at whatever 'latest' is for placement in ocata, but not what the pike scheduler client actually needs
21:02:02 dansmith edleafe: okay and you caught the bit I said about the selectionlist object potentially being okay if we're going to use it for holding a version right?
21:03:04 edleafe dansmith: yeah, but that's minor
21:03:48 dansmith edleafe: yep, just saying, if you wan to go back to doing it that way, I'm cool with it
21:03:50 cdent edleafe’s link raises another wart doesn’t it? If _move_operation_alloc_request is working in the guts of alloc request, it has to know the version
21:04:21 cdent is that called from only the scheduler, or also in the cells?
21:04:28 cdent (and presumably there are others like it?)
21:04:38 jaypipes cdent: we're trying to get rid of that entirely.
21:04:45 jaypipes cdent: and do the migration owns allocation thing.
21:04:51 edleafe cdent: it will be called from within the cells too
21:04:52 mriedem cdent: it's called from the scheduler and, for the time being, superconductor
21:04:55 cdent yes, but will still inspect don’t we?
21:04:58 mriedem during force live migrate and force evacuate
21:05:01 mriedem where the scheduler is skipped
21:05:06 mriedem edleafe: not within the cells
21:05:18 cdent and in any case that code is pike
21:05:21 mriedem edleafe: oh you mean with alternate hosts yeah
21:05:22 edleafe mriedem: the cell conductor will have to claim
21:05:26 mriedem right right
21:05:42 dansmith but we don't need too look inside the a-r in the claim during reschedule
21:05:52 mriedem we just proxy it through
21:05:55 dansmith this move claim thing is a good example of the scheduler needing to examine it
21:05:57 dansmith mriedem: right
21:06:02 mriedem "here is a request the scheduler told me to send at this version k?!"
21:06:09 mriedem "<3 cell conductor"
21:06:26 edleafe dansmith: and I was thinking that this move claim thing is a bad example
21:06:48 dansmith edleafe: it's a bad example in the cosmic sense of things that suck... yes :)
21:11:04 efried mriedem Please cast your critical eye upon https://review.openstack.org/#/c/488137/ when you get time.
21:11:38 efried IIRC the goal was to get the whole series in by the first milestone thingy.
21:11:48 mriedem efried: oh efried
21:11:57 mriedem did i actually say that was a goal?
21:12:05 mriedem i mentioned it as being doable during a meeting a few weeks back
21:12:12 mriedem and you've been cruising my house at 1am ever since
21:12:15 efried Oh, please let me find that. Stand by.
21:13:19 efried mriedem http://eavesdrop.openstack.org/meetings/nova/2017/nova.2017-09-21-14.00.log.txt @14:03:09
21:14:00 efried It's entirely possible I've been misinterpreting "...should ... have ... merged by then"
21:14:11 mriedem that can be interpreted so many different ways
21:14:15 mriedem would never hold up in a court
21:14:41 jaypipes can we finalize on a decision on this then?
21:14:53 efried Fair enough. But if it ever gets interpreted as "this should have merged by then," I don't want it to be because I didn't pester people for reviews :)
21:16:24 mriedem efried: don't worry i know you've asked several times
21:16:36 mriedem jaypipes: pass the version down
21:17:14 dansmith yep
21:17:16 edleafe jaypipes: [t 4Bt]
21:17:17 purplerbot <edleafe> I'm going to finish the stuff I've been trying to work on and then I'll rethink how to change the series to add a versioned allocation_request to the Selection object [2017-10-05 21:01:08.583741] [n 4Bt]
21:17:36 jaypipes ok, thanks edleafe
21:26:45 mriedem ha,
21:26:49 mriedem good news folks
21:26:57 mriedem get ready for 100% nova gate failure
21:28:21 dansmith wat
21:28:28 dansmith I see the top of our gate is failing
21:28:33 mriedem yeah i know what it is
21:28:41 mriedem but i'll never tell
21:28:49 dansmith just fix, I don't care if you tell
21:29:01 mtreinish mriedem: oh it's your new test
21:29:10 mriedem SHHHHHHHHHHHHHHHH
21:29:14 mriedem TREINISH!
21:29:29 mriedem who were the ad wizards that merged that one
21:29:47 mtreinish mriedem: oomichi_afk gave it the +W
21:29:49 dansmith the shelve offload one?
21:29:53 mriedem no
21:29:55 mriedem i'm fixing
21:30:02 melwitt lol
21:30:53 mtreinish dansmith: https://review.openstack.org/#/c/480746/
21:31:56 mriedem hey, you're welcome ^
21:31:59 mriedem oops
21:32:05 openstackgerrit Matt Riedemann proposed openstack/nova master: Blacklist test_extend_attached_volume from cells v1 job https://review.openstack.org/509907
21:32:13 dansmith well, melissaml +1d it so I'm surprised it was buggy
21:32:30 mriedem usually pretty reliable
21:32:53 dansmith melwitt: jaypipes ^
21:34:48 openstackgerrit Jay Pipes proposed openstack/nova master: rp: break functions out of _set_traits() https://review.openstack.org/509908
21:35:30 mtreinish melwitt: hmm, on https://review.openstack.org/#/c/507976/ stestr said the blacklist didn't match anything
21:35:40 mtreinish you might have found a bug in it
21:36:55 melwitt okay :)
21:37:08 melwitt mtreinish: do you know wassup with this? http://logs.openstack.org/76/507976/5/check/gate-nova-python35/859471a/console.html#_2017-10-05_21_00_25_162394
21:37:56 mtreinish melwitt: yeah the post-processing on results is going a bit crazy because the test runner bailed before generating any artifacts
21:38:35 mtreinish so all the things are trying to operate on testrepository.subunit are blowing up because that was never created
21:39:11 mtreinish that specific du check was there for testr because it would just pass silently if no tests were ever run
21:39:30 melwitt oh
21:39:42 mtreinish so the run tox script that zuul runs does a du to check there is actual subunit data generated
21:39:54 melwitt do not matching anything made it bail?
21:39:56 mtreinish it's not really necessary on stestr though because it fails if nothign is run
21:40:01 melwitt *did
21:40:17 melwitt I guess that didn't really make my sentence better
21:40:25 mtreinish melwitt: yep, it exited with an error because it didn't match anything
21:40:44 mriedem jaypipes: i have a sql question
21:40:50 mtreinish that error message needs to be fixed though, it predates other non-regex selection mechanisms

Earlier   Later