| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-06 | |||
| 18:46:38 | melwitt | mriedem: thanks. we're seeing a failure where a test that calls direct to the hypervisors api is failing though too | |
| 18:47:38 | mriedem | sean-k-mooney: you know https://launchpad.net/~os-vif-drivers/+members doesn't mean core team right? | |
| 18:47:40 | melwitt | I wonder if the server listing causes an rpc connection to get cached to the wrong queue topic or something, because what we're seeing is compute not responding on the 'cells' topic | |
| 18:48:06 | melwitt | with cells v1, compute has to listen/respond on both the 'compute' and 'cells' topics | |
| 18:48:17 | sean-k-mooney | mriedem: yes i wanted to be able to do bug triage | |
| 18:48:20 | mriedem | ah ok | |
| 18:48:34 | mriedem | btw, https://review.openstack.org/#/admin/groups/1175,members i don't need to be in the core team there :) | |
| 18:48:49 | mriedem | i think i've reviewed maybe 2 os-vif patches | |
| 18:49:48 | sean-k-mooney | mriedem: leakypipes "volentold" you but if you do not want to be on it or dont feel comfortable reviewing it in general i can remove you again | |
| 18:51:11 | leakypipes | mriedem is an all-round amazing velvet doberman of a programmer. he is amazing. thus the desire to make him an os-vif-core. | |
| 18:51:38 | mriedem | sean-k-mooney: removed myself :) | |
| 18:52:59 | sean-k-mooney | mriedem: no worries, leakypipes looks like we need to up our flattery game. | |
| 18:53:42 | sean-k-mooney | ok i have to run so ill talk to everyone later | |
| 18:53:42 | mriedem | heh, i just can't handle the pressure | |
| 18:56:44 | leakypipes | boo :( | |
| 18:59:36 | melwitt | looks like that host service status is just a servicegroup api query for up/down so shouldn't be related | |
| 19:02:40 | cdent | I'm finding myself wishing I could create nameless resource providers over the api. But it is really only for testing, not real life, so I guess that doesn't count. | |
| 19:05:33 | mriedem | leakypipes: superdan: i'm cool with https://review.openstack.org/#/c/410471/ now | |
| 19:07:17 | mriedem | bauwser: leakypipes: i was at lunch and missed the discussion about the placement client stuff - was the decision to NOT pull that out and instead just re-use the scheduler report client stuff in the host manager? | |
| 19:11:23 | leakypipes | mriedem, superdan: Wallaby'd. | |
| 19:12:11 | leakypipes | mriedem, bauwser: well, what I was saying was to not create a placement client and instead do raw calls into the placement API in the same vein as the scheduler report client. | |
| 19:13:35 | mriedem | leakypipes: superdan: got a problem in this https://review.openstack.org/#/c/410472/ | |
| 19:13:50 | superdan | mriedem: leakypipes thanks | |
| 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/ ? | |