Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-21
18:18:48 mriedem dansmith: btw, i changed _GroupAntiAffinityFilter to False, ran functional tests and nothing failed
18:19:12 dansmith mriedem: it'll be non-deterministic
18:19:20 mriedem gha
18:19:22 mriedem *gah
18:19:25 dansmith because if it selects the other host by chance it'll be happy
18:19:49 dansmith it was oddly repeatable for me.. two tests validating the same thing (for two microversions) one would always pass the other would always fail
18:19:53 dansmith took me a while to figure out why
18:20:13 dansmith I was able to shake it up with different levels of concurrency and running the tests in isolation
18:20:30 mriedem test_rebuild_with_soft_anti_affinity ?
18:20:48 mriedem or test_rebuild_with_anti_affinity
18:20:58 dansmith soft I think
18:21:25 mriedem that one involves a weigher so yeah might be that one
18:21:27 dansmith I can try to repro if it's important
18:21:28 mriedem will run it a few times
18:21:58 openstackgerrit Eric Fried proposed openstack/nova master: Use ksa adapter for cinder client https://review.openstack.org/508345
18:22:13 mriedem i am dangerously close to needing some deterministic lunch
18:23:01 dansmith mriedem: http://logs.openstack.org/86/521186/3/check/openstack-tox-functional/dc8ab81/testr_results.html.gz
18:23:03 dansmith that was the failure I tried to repro locally that led me down the path I think
18:48:20 dansmith artom_: mriedem well, now I can't get it to fail
18:49:24 dansmith oh, wait
18:49:24 mriedem :/
18:49:36 mriedem was that with same_host or something?
18:49:37 dansmith I bet it's because I hit this before I was doing the force_hosts
18:49:58 mriedem ah
18:50:18 dansmith it was when I was going to do the check in conductor manager I think
18:50:29 mriedem so we can probably change that one then
18:50:33 mriedem which would help with the confusion
18:50:42 dansmith yeah I guess so
18:51:33 mriedem dansmith: artom: in general, what are your thoughts/feelings/hopes/dreams about just calling the hint _is_rebuild and the filter attribute RUN_FOR_REBUILD? then each filter decision is about that scope/use case rather than what policy means
18:52:16 dansmith I dunno, it feels too specific, but I can't come up with another reason to do this really
18:52:33 mriedem right, like you said, we could change it later if we have a need to generify it
18:53:01 dansmith yeah
18:53:08 mriedem we could also maybe remove the variable at some point later with rpc version changes, like passing an actual is_rebuild parameter to select_destinations or something
18:53:20 dansmith yeah
18:53:32 mriedem i'm not sure that would buy us much, except maybe more straight-forward
18:53:44 dansmith ideally it'd be operation="rebuild" to give us some room for the future
18:53:45 dansmith but yeah
18:53:51 mriedem sure
18:54:06 mriedem operation="mind crime"
18:54:12 dansmith heh
18:54:17 mriedem 80s queensryche reference for artom
18:58:18 artom I was -5 for half the 80s, though I do enjoy some of their music now :)
18:58:41 artom Renaming it to RUN_FOR_REBUILD would definitely make the scope clearer
18:58:46 artom I agree it's not pretty
18:59:25 artom Though I'm not as repulsed by the api <-> scheduler coupling - the scheduler knowing about rebuilds isn't as far fetched as it sounds
18:59:49 artom I think ideally I'd like more methods in the filters, like I said in my last comment
19:00:28 artom So host_passes for "can this host run this instance now?", host_acceptable for "can this host accept this instance, resource considerations aside", and maybe other ones for cases we haven't thought of
19:00:36 artom But that doesn't look very backportable
19:04:29 openstackgerrit Merged openstack/nova master: cleanup mapping/reqspec after archive instance https://review.openstack.org/515034
19:05:29 mriedem mgagne: a couple of small changes to make here and then i think we're good https://review.openstack.org/#/c/503088
19:06:26 mriedem artom: the scheduler is definitely aware of moves for placement allocations, even if it's not super obvious
19:06:35 mgagne mriedem: will work on it today. I think committed the Ironic release note by mistake, will reword as suggested
19:07:03 mriedem mgagne: yeah heh, that was my comment :)
19:07:14 mgagne didn't read yet :P, will do
19:07:59 artom mriedem, yeah, it decides which instances go to which hosts, to operations on instances that have to do with hosts aren't outside its domain :)
19:08:05 artom *so operations
19:08:28 artom If we started telling it about keypair updates I'd be more concerned ;)
19:08:37 mriedem artom: i mean this specifically https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1035
19:16:14 efried cdent Still around?
19:16:23 cdent yessir
19:16:33 mgagne mriedem: so should I refactor _generate_configdrive or not?
19:16:38 efried cdent Is there a way in gabbi for me to say "This must *not* be in the response" ?
19:17:30 cdent in a body or header?
19:17:38 efried body
19:18:12 efried I know about checking the length of a chunk of the response; will fall back on that if nothing else is available.
19:18:39 cdent there are a couple of additional options:
19:19:22 cdent if the surrounding chunk of json is small and you know all of it, you can make the value of the jsonpath be the entire chunk, instead of just a scalar value
19:19:37 cdent or you might be able to do something with regular expressions
19:19:49 cdent (the value side of the jsonpath statement can be a regex)
19:20:09 cdent efried: if you got a pointer to an almost there example I can probably say something more concrete
19:21:27 efried cdent Like here: https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml#L105
19:21:38 efried cdent I want to make sure there's no "traits" key
19:21:43 efried etc.
19:22:21 efried response_forbidden_json_paths:\n\t$.resource_providers[0].traits
19:22:34 cdent heh
19:23:02 cdent is your intent to validate the entire response? If so, you might consider:
19:23:38 cdent response_json_paths:\n$: @<my-big-response.json
19:24:18 mriedem mgagne: no, i think what you have is ok
19:24:21 efried cdent Right; though the docs kinda recommended against that.
19:24:27 mriedem the error handling being different makes a refactor less worthwhile
19:24:28 openstackgerrit Eric Young proposed openstack/nova master: Implement ScaleIO image backend https://review.openstack.org/407440
19:24:35 mgagne mriedem: got it
19:24:37 cdent efried: they also recommend not validating entire responses
19:24:56 cdent (in one test)
19:25:26 efried cdent Specifically in this case I'd like to ensure I don't return the extra fields when I don't request them. (Related to the traits/aggregates/inventories thing from this morning)
19:25:50 efried cdent (Yes, I realize I haven't abandoned this patch, but I'm taking it as an opportunity to learn gabbi.)
19:26:15 cdent :)
19:26:59 cdent another option would be to write your own CustomHandler that actually implements response_forbidden_json_paths
19:27:46 efried cdent That would live in nova, or that would be contributed back to gabbi?
19:28:30 efried oh, jsonpath_rw, that's a separate thing. /me looks too...
19:30:05 cdent I was thinking live in nova initially, and then merged to gabbi if it felt sufficiently useful/nice
19:31:29 openstackgerrit Eric Berglund proposed openstack/nova master: WIP(5): PowerVM driver: ovs vif https://review.openstack.org/422512
19:32:49 cdent efried: this might be a case where it would be better to have a unit test of your serializer
19:33:16 efried cdent Also.
19:34:08 dansmith mriedem: you have some changes against the set locally, right? will you make the hint change and the other things we discussed as part of that?
19:34:48 mriedem dansmith: i don't have anything local
19:35:11 dansmith oh okay I thought you were working on the reno and flipping some of the flags
19:35:22 efried cdent Thanks for the help. A CustomHandler might be more than I'm willing to bite off at the moment, but I'll pester you if I decide to have a crack at it.
19:35:26 dansmith I'll go ahead and do that other stuff then
19:35:44 mriedem dansmith: that got sidetracked by the review comments and waiting to hear back from some people

Earlier   Later