| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-24 | |||
| 19:30:07 | mriedem | laura's mom went to grad school for that i think, she'll talk your ear off | |
| 19:30:21 | mriedem | about vacuums that also polish wood floors | |
| 19:30:26 | mriedem | controlled via your iphone app | |
| 19:30:38 | jaypipes | I'm wondering if we can't just recreate the limits['numa_topology'] on the compute host.... | |
| 19:31:16 | mriedem | i guess i'm failing to see the issue with sending both back from select_destinations | |
| 19:31:25 | mriedem | we're already sending host_dict_with_limits_thing | |
| 19:31:35 | jaypipes | dansmith: ^ | |
| 19:31:37 | mriedem | we're just tacking allocation_request(s)? onto that | |
| 19:31:39 | mriedem | as a tuple | |
| 19:31:55 | mriedem | btw, are these allocation requests plural or singular? | |
| 19:32:05 | edleafe | mriedem: we're changing 2 things | |
| 19:32:05 | mriedem | one per host right? so singular | |
| 19:32:10 | jaypipes | mriedem: singular per host, yeah. | |
| 19:32:12 | edleafe | instead of a single host | |
| 19:32:13 | dansmith | yeah, like I said above, I think I was missing that we're already passing that grossness in the rpc calls downstream from where we get them | |
| 19:32:21 | edleafe | we're sending a list of hosts | |
| 19:32:34 | edleafe | and each of those has an associated allocation_candidate | |
| 19:32:35 | mriedem | edleafe: please provide context | |
| 19:32:42 | mriedem | "sending" from where to where? | |
| 19:32:51 | edleafe | to the cell conductor | |
| 19:32:57 | edleafe | from the super conductor | |
| 19:33:10 | dansmith | super conductor doesn't call cell conductor | |
| 19:33:19 | dansmith | super conductor calls the first compute node, which will call cell conductor on retry | |
| 19:33:35 | mriedem | edleafe: ok so here https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L1046 | |
| 19:33:44 | edleafe | I thought that was changing so that we supported alternates | |
| 19:34:17 | dansmith | no | |
| 19:34:35 | edleafe | So we're sending the compute node the big honking list of list of stuff? | |
| 19:34:42 | mriedem | api -> super conductor > scheduler > super conductor > compute > cell conductor (retry) > compute | |
| 19:34:52 | dansmith | right | |
| 19:34:54 | edleafe | And then it sends it to cell conductor on retry? | |
| 19:34:59 | mriedem | yes | |
| 19:35:05 | mriedem | the allocation requests are getting passed through | |
| 19:35:13 | mriedem | like barnacles | |
| 19:35:23 | mriedem | or a tube sock in mortier | |
| 19:35:26 | mriedem | *mortimer | |
| 19:35:27 | edleafe | more like kidney stones | |
| 19:35:45 | mriedem | 2nd question, | |
| 19:35:48 | melwitt | lol omg, mortimer | |
| 19:36:12 | mriedem | are we changing the build_and_run_instances compute rpc api to pass allocation requests, or shoving those into something else already being sent, like request spec or filter properties? | |
| 19:37:37 | dansmith | one of those | |
| 19:37:58 | mriedem | which would also impact the build_and_run_instance method in conductor rpc api | |
| 19:38:11 | mriedem | *build_instances | |
| 19:38:35 | dansmith | if we put it into something like reqspec, we won't be able to send them to older computes | |
| 19:38:41 | dansmith | which will break our upgrade process | |
| 19:38:46 | dansmith | because they'll kick the newer version back | |
| 19:39:00 | mriedem | personally i think it's cleaner as a new parameter on the rpc api | |
| 19:39:08 | dansmith | which I guess is the same for the new param approach | |
| 19:39:26 | dansmith | we just need to handle the case in the retry logic, | |
| 19:39:35 | dansmith | if we didn't get these new things, assume we can talk to the scheduler and do a reschedule | |
| 19:40:18 | mriedem | but if your cell conductor is blocked from up calls to the scheduler, how would that work? | |
| 19:40:31 | dansmith | if you have old computes, | |
| 19:40:39 | dansmith | then you don't have a multi-tier cellsv2 environment, | |
| 19:40:43 | dansmith | because we didn't support it before, | |
| 19:40:46 | openstackgerrit | Ed Leafe proposed openstack/nova master: Migrate Ironic Flavors https://review.openstack.org/484949 | |
| 19:40:46 | dansmith | thus it must be fine | |
| 19:41:11 | mriedem | idk, we don't really have anything doc'ed for this | |
| 19:41:21 | dansmith | eh? | |
| 19:41:24 | dansmith | it can't work right now | |
| 19:41:29 | dansmith | no need to doc it :) | |
| 19:41:40 | mriedem | what does old computes have to do with multi-tier cells v2? | |
| 19:42:13 | dansmith | can we discuss on a hangout? I'm about out of steam and have to move onto something else soon | |
| 19:42:14 | dansmith | be quicker if we can hash it out like that I think | |
| 19:42:25 | mriedem | i'm fine with a hangout | |
| 19:42:36 | jaypipes | me too. | |
| 19:43:04 | dansmith | https://hangouts.google.com/call/pjno3bssgba33a343nf47d357iu | |
| 19:52:38 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted certificates to InstanceExtras https://review.openstack.org/457711 | |
| 19:53:47 | openstackgerrit | Merged openstack/nova master: Remove an unnecessary argument in _prep_resize https://review.openstack.org/486521 | |
| 19:54:35 | openstackgerrit | Merged openstack/python-novaclient master: Expect id and disabled_reason in GET /os-services response https://review.openstack.org/485409 | |
| 20:09:13 | openstackgerrit | Eric Fried proposed openstack/nova master: nova.utils.get_service_url() https://review.openstack.org/458257 | |
| 20:10:51 | efried | mriedem mordred os-service-types didn't get released last week. If it gets released soon, is it too late to get it through and use it in nova for pike? | |
| 20:11:56 | mriedem | efried: i haven't reviewed the nova code so can't really say what the risk is, or if this is all disabled by default and then people have to opt-in, or what | |
| 20:12:49 | efried | mriedem I was about to crank back up on the nova side, now that all the ksa stuff has landed. But one of the main pieces I need is os-service-types. If I can't have that, I'm going to have to basically inline a bunch of it. | |
| 20:13:06 | efried | mriedem os-service-types is brand new, so there's no risk of breaking backward compatibility or whatever. | |
| 20:13:22 | efried | mriedem It'll be a brand new dep, for whatever that means. | |
| 20:27:50 | mriedem | edleafe: so let's hold off on the alternatives stuff for pike, it's too high risk at this point in the schedule, we'll work on that for queens. it means you can't do multi-tier multi-cell with retries, but if you don't care about retries, like CERN, then you're still golden for pike. | |
| 20:28:00 | mriedem | edleafe: so focus on the ironic flavor migration stuff for pike | |
| 20:30:15 | edleafe | mriedem: ok | |
| 21:04:32 | openstackgerrit | Jeroen van Bemmel proposed openstack/nova master: Closes-Bug: 1702475 https://review.openstack.org/486753 | |
| 21:04:33 | openstack | bug 1702475 in OpenStack Compute (nova) "IPv6 data missing from latest/metadata info" [Medium,Confirmed] https://launchpad.net/bugs/1702475 | |
| 21:05:22 | openstackgerrit | Jeroen van Bemmel proposed openstack/nova master: Closes-Bug: 1702475 https://review.openstack.org/486753 | |
| 21:31:41 | openstackgerrit | Merged openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945 | |
| 21:32:24 | mriedem | cdent: the thing that your wsgi-intercept patch failed on failed in another unrelated change http://logs.openstack.org/02/485602/6/check/gate-nova-tox-functional-ubuntu-xenial/edf4c41/testr_results.html.gz | |
| 21:32:29 | mriedem | so probably just some new fun | |
| 21:32:45 | cdent | le sigh | |
| 21:32:58 | cdent | i have the OSAPIFixture using wsgi-intercept in progress | |
| 21:33:10 | cdent | I might stack them and see if that gets us anywhere | |
| 21:42:45 | openstackgerrit | Ed Leafe proposed openstack/nova master: Migrate Ironic Flavors https://review.openstack.org/484949 | |
| 21:51:37 | mriedem | think i know what's causing the spike in the functional tests failing | |
| 21:51:46 | mriedem | https://review.openstack.org/#/c/484154/2/nova/tests/functional/api/openstack/placement/gabbits/resource-class-in-use.yaml | |
| 21:52:00 | mriedem | i think we have gabbits racing that work against the same custom resource class | |
| 21:52:46 | dansmith | they use the same db instance in parallel? | |
| 21:52:57 | mriedem | creating the same custom resource class, | |
| 21:53:17 | mriedem | in one case it already exists i think so it returns 204 | |
| 21:53:26 | mriedem | which fails the assertion for a 201 | |
| 21:53:51 | mriedem | https://bugs.launchpad.net/nova/+bug/1706207 | |
| 21:53:52 | openstack | Launchpad bug 1706207 in OpenStack Compute (nova) "resource-class-in-use_delete_resource_class fails with "AssertionError: '404' not found in ['204']" since 7/22" [High,Confirmed] | |
| 21:54:33 | dansmith | oh, the same placement fixture I guess? | |
| 21:54:38 | mriedem | yeah | |
| 21:54:41 | dansmith | I see | |
| 21:57:31 | mriedem | although these tests should be using isolated sqlite dbs | |