Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-05
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
21:40:50 melwitt k
21:40:56 mriedem i want to add an index on instance_actions_events for the action_id and event_id fields,
21:41:15 mriedem jaypipes: when we query those, we also include the deleted column so i'm assuming we want that in the index too right?
21:42:15 jaypipes mriedem: you don't *have* to do that, no... especially if the deleted column has very low cardinality
21:42:30 jaypipes mriedem: i.e. deleted column has very few distinct values
21:42:34 mriedem i've just noticed that we have deleted in most of our other indexes
21:42:36 mtreinish melwitt: the thing I'm confused by is the selection code in stestr I basically just copy and pasted from ostestr, so I'm surprised it's behaving differently
21:42:53 melwitt ah, yeah. I was wondering that
21:43:02 jaypipes mriedem: yeah, I know we have deleted in a lot of the indexes...
21:43:14 mriedem jaypipes: well, the values are 0 or positive int
21:43:36 jaypipes mriedem: right, but most are 0.
21:43:42 mriedem sure
21:43:53 mriedem maybe i should just run it both ways and see
21:43:58 jaypipes mriedem: that's like have a phone book with all dan smiths in it.

Earlier   Later