Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-06
19:16:50 bauwser leakypipes: I already wrote that, lemme upload it
19:17:01 bauwser leakypipes: I just want to not wait for that
19:17:09 mriedem leakypipes: that's what this does https://review.openstack.org/#/c/417111/2/nova/scheduler/client/__init__.py
19:17:13 leakypipes mriedem, bauwser: i.e. I don't want to hold up progress putting together an object-oriented placementclient-type thing.
19:17:21 bauwser exactly
19:17:24 mriedem yeah i agree with not holding it up
19:17:27 bauwser the change is becoming huge
19:17:30 mriedem but...if it's a simple lieft
19:17:34 mriedem *lift
19:17:40 mriedem bauwser: what is huge about it? the tests?
19:17:41 bauwser so I'll write the scheduler modification before that change
19:17:44 bauwser mriedem: zacvtly
19:17:57 bauwser mriedem: and because I copy/paste a lot
19:18:06 bauwser creating a new module
19:18:11 leakypipes bauwser: yeah, I don't see that patch being too big?
19:18:20 bauwser leakypipes: mriedem: you'll see
19:18:33 bauwser just rebasing the API change and you'll see, folks
19:18:35 openstackgerrit John Garbutt proposed openstack/nova: WIP: Objectify _validate_requested_network_ids https://review.openstack.org/411950
19:18:39 leakypipes ok
19:19:55 leakypipes bauwser: the only thing I'd like to see is the use of encapsulation instead of inheritance there.
19:19:57 mriedem bauwser: so the alternative is just using the existing stuff in the scheduler report client class right?
19:20:19 leakypipes bauwser: in other words, just have the scheduler report client contain an instance of PlacementClient.
19:20:31 bauwser leakypipes: yup
19:20:32 mriedem if it's just a matter of using the scheduler report client right now because it's available and easy, then just do that and we can split apart and cleanup later
19:20:49 bauwser leakypipes: I wrote an encapsulation like cdent asked
19:20:56 leakypipes k
19:21:07 bauwser leakypipes: I wrote an inheritance because I was lazy
19:23:15 bauwser mriedem: just a question : we created a stable 14.0.2 pin but we have a DB migration in it, which requires a db sync, shouldn't we have created a 14.1.0 ?
19:23:36 jroll mriedem: I see you in my meeting agenda, are you attening or did you just want me to say words about that
19:23:46 jroll I'm up to date on the statuses of those things
19:25:46 leakypipes superdan: your eyeballs on https://review.openstack.org/#/c/415031/ would be appreciated. I know it's a blocker for mlavalle :)
19:25:49 mriedem bauwser: do we have rules anywhere about versions on stable branches that include a db migration?
19:25:54 mriedem bauwser: it was additive
19:26:22 mriedem bauwser: fyi our next stable/newton is going to have an online data migration bug fix in it too
19:26:26 mriedem not a schema migration though
19:27:27 superdan leakypipes: I have to figure out this cellsv1 thing before I can do anything else or we're all fscked
19:27:33 superdan so yeah, maybe but not today sorry
19:27:38 leakypipes superdan: not a problem.
19:27:59 leakypipes superdan: lemme know if I can assist on the cellsv1 issues.
19:28:07 superdan leakypipes: got any guns?
19:28:47 mriedem he does live in FL...
19:29:00 mriedem there are probably some just lying around
19:29:05 superdan I could loan him one
19:29:28 jroll he could just send floridaman your way
19:29:30 superdan sdague: back around yet?
19:29:55 bauwser mriedem: sorry, was diverted
19:30:10 bauwser mriedem: lemme look at semver rules in the governance repo
19:30:28 bauwser mriedem: but AFAIR, .z versions means just apt-get and then restarty
19:30:34 bauwser or yum :)
19:30:38 bauwser erf
19:30:39 bauwser dnf even
19:30:57 bauwser (shhhht, don't tell my employer :p )
19:31:04 jroll heh
19:31:05 mriedem heh
19:31:21 jroll feels like db migrations would be a .y but I'd probably ask release folks
19:31:28 mriedem either way,
19:31:35 mriedem that ship has kind of sailed...
19:31:40 mriedem as of like a month ago
19:31:45 bauwser yeah I know
19:31:56 bauwser mriedem: it's somehow an internal discussion, y'know
19:32:04 mriedem bauwser: i figured
19:32:07 bauwser just popping up here :)
19:32:08 mriedem tell them i'm sorry,
19:32:18 mriedem bauwser: however, if they care about how upstream stable releases are versioned,
19:32:25 mriedem there is a way they can get involved in monitoring that...
19:32:52 bauwser mriedem: no worries, I'll ask them to leave tar and feather at home
19:33:29 openstackgerrit Dan Smith proposed openstack/nova: WTFWIP: Multicell support for instance listing https://review.openstack.org/396775
19:33:30 openstackgerrit Dan Smith proposed openstack/nova: Make the SingleCellSimple fixture a little more comprehensive https://review.openstack.org/410472
19:33:42 melwitt superdan: I dunno if you saw the scrollback but I was thinking I wonder if the hosts api call is going out on the wrong topic ('compute' instead of 'cells' topic, since the rpc connects get cached via cell uuid) and that's why it doesn't get a response there. I just don't get how that would start up with your patch and not being failing as-is
19:33:47 openstackgerrit Matthew Edmonds proposed openstack/nova: update policy UT fixtures https://review.openstack.org/398610
19:35:14 superdan melwitt: hmm
19:35:45 superdan melwitt: I just put up a test what just comments out the fanout to the cells, which will fail a bunch of things, but I want to see if it affects the host bit
19:36:04 mriedem bauwser: so where are we at with cleaning up https://review.openstack.org/#/c/392569/ ?
19:36:29 leakypipes superdan: I live in Florida. of course I do.
19:36:37 melwitt because what's failing is this 'intercell' communication, the 'cells' topic
19:37:02 superdan melwitt: well, it's not actually.. if you look, the cells-child is failing to call to the compute via compute topic, which is cascading up
19:38:28 melwitt superdan: I thought this is showing a send to the 'cells' topic? http://logs.openstack.org/75/396775/21/check/gate-tempest-dsvm-cells-ubuntu-xenial/2d615a2/logs/screen-n-api.txt.gz?#_2017-01-06_16_06_16_678
19:38:40 superdan melwitt: right, but hang on
19:38:51 melwitt lemme look in the other logs again
19:38:56 superdan melwitt: http://logs.openstack.org/75/396775/21/check/gate-tempest-dsvm-cells-ubuntu-xenial/2d615a2/logs/screen-n-cell-child.txt.gz?level=TRACE#_2017-01-06_16_01_16_493
19:39:08 superdan that's what gets called, which makes a call to compute, which times out
19:43:04 melwitt it says FANOUT topic 'cells.intercell.response' for the same req-id. you're saying the call to compute will go on the 'compute' topic though, and that's not responding and thus doesn't end up responding on the cells topic
19:43:29 superdan melwitt: but it's a call to compute_rpcapi
19:43:48 superdan File "/opt/stack/new/nova/nova/compute/rpcapi.py", line 920, in get_host_uptime
19:44:19 melwitt yeah. okay. so it goes on cells topic -> compute topic then replies go backward. hmm
19:44:29 superdan right
19:46:02 cdent leakypipes: you might find this amusing or interesting: https://tank.peermore.com/_/8760ec93-b39a-4dd5-849f-d880572fb2cd
19:46:39 cdent that's a gabbit using a new $HISTORY feature in gabbi + some yaml anchors to play games with the placement api
19:47:22 cdent ./stack.sh && openrc admin && gabbi-run http://localhost < that.yaml
19:47:44 cdent gonna flesh it out a bit more, but going to dinner now
19:48:18 cdent s/openrc/. openrc/
19:50:00 melwitt superdan: for cells v1 do we have a host mapping set up that has the child cell transport_url in it?
19:50:27 melwitt sorry cell mapping
19:50:41 superdan melwitt: yeah, should, but hmm, I wonder if that points to the wrong thing
19:50:56 superdan melwitt: in the devstack job, do we really have any different mq exchanges or anything?
19:51:01 melwitt I noticed the nova.conf and nova-cells.conf have different transport urls. but I don't get how it ever worked then
19:51:09 superdan ooooh
19:51:10 superdan because
19:51:17 superdan I just changed that in a not yet merged dep patch :)
19:51:21 superdan check the depends-on

Earlier   Later