| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-06 | |||
| 19:14:40 | mriedem | leakypipes: oh, ok...well....we'd have that same pattern in 3 places in nova then... | |
| 19:14:47 | mriedem | scheduler report client, nova-status, and then the host manager | |
| 19:15:06 | mriedem | and as seen with the 401 issue this week, if we have a bug in one we have to check all of the others | |
| 19:16:22 | leakypipes | mriedem, bauwser: I'd be cool pulling the very basic safe_connect() and get/put/delete/post methods into a base class, I suppose, but nothing more than that. | |
| 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 | |