Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-25
14:50:46 mriedem sdague: i tend to say yes, otherwise how do you know if the cloud has the header or not?
14:50:48 mriedem however,
14:51:03 mriedem do we hook in something that removes the header for requests < new microversion?
14:51:10 sdague nope
14:51:22 mriedem otherwise the new microversion is only signaling
14:51:27 sdague correct
14:51:42 sdague also, it depends on code version on the server and if they follow our upper constraints
14:52:04 sdague it's definitely a little messy, and mostly annoying we didn't do this a long time ago
14:52:16 mriedem sdague: we can't require a new minimum version of oslo.middleware?
14:52:39 sdague maybe, I can look at the force on the requirements side
14:52:48 sdague we could land it with the requirements force
14:55:16 mriedem you want oslo.middleware>=3.27.0 it looks like
14:55:20 mriedem for https://github.com/openstack/oslo.middleware/commit/0e3dbba0d9d373fbfa9e28897cd33377e2491d32
14:56:32 sdague yep
14:56:40 alex_xu emm...any special reason for not having a microversion?
14:56:51 sdague https://review.openstack.org/#/c/468057/
14:57:46 sdague mriedem: ok, I'll build on top of that in my spider of crazy depends on
15:01:28 edleafe jaypipes: free?
15:01:37 jaypipes edleafe: sorry, still on call.
15:01:46 jaypipes edleafe: will ping you asap.
15:02:30 edleafe jaypipes: kewl
15:05:21 openstackgerrit Sean Dague proposed openstack/nova master: Migrate to oslo request_id middleware - mv 2.46 https://review.openstack.org/467998
15:06:44 mriedem sdague: you'll throw a shoe, but we should have a bp and spec for that microversion
15:06:55 mriedem i imagine it will be small
15:07:36 sdague mriedem: specless blueprint?
15:07:39 cdent I should warn you, I do no the other one, so if you like that one, you're gonna hobble for a long time
15:07:49 mriedem sdague: all api changes need a spec
15:07:53 mriedem thems the rules
15:09:17 mriedem smcginnis: so what kind of fun dual maintenance path is it going to be for os-brick in both python and go?
15:09:31 sdague mriedem: ok, let me throw together something quick
15:10:51 mriedem jaypipes: isn't this vestigial now? https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L800
15:11:49 mriedem added in https://github.com/openstack/nova/commit/8941b45bc58a833261bb09fc7eb8fb5c765e154a
15:12:18 mriedem wondering b/c of https://github.com/openstack/nova/commit/ea4754ba21ea08eb367d62bc46b5eba3777c119c
15:12:23 jaypipes mriedem: yeah. the comment can be removed.
15:20:49 smcginnis mriedem: Eh, it's inevitable.
15:24:28 mriedem hmm, i've got questions about compute nodes and services records
15:24:34 mriedem b/c something isn't adding up
15:25:44 mriedem deleting a nova-compute service record doesn't delete the compute_nodes record,
15:26:07 mriedem but if you restart the nova-compute process, it's going to create a new services table record for the same host/binary/topic
15:26:15 mriedem the compute_nodes table entry has a service_id record in it
15:26:33 mriedem the resource tracker isn't going to create a new compute_nodes record because one already exists for the given host and nodename
15:26:43 mriedem but, do we ever update the compute_nodes.service_id record anywhere?
15:27:46 openstackgerrit Sean Dague proposed openstack/nova-specs master: oslo.middleware request_id spec https://review.openstack.org/468066
15:27:52 sdague mriedem: ok, spec ^^^
15:28:17 mriedem ok
15:30:19 mriedem jaypipes: do we actually not tie the compute nodes record to the nova-compute service anywhere?
15:31:31 mriedem ah looks like it's not, by design
15:31:34 mriedem since it's all deprecated
15:35:53 mriedem oh snap
15:36:06 mriedem alex_xu: we do soft delete the compute node record when the service is deleted,
15:36:09 mriedem if they are tied together,
15:36:15 mriedem which happens for very old compute nodes records
15:36:52 mriedem https://github.com/openstack/nova/blob/65402e1aeb770d077620f2935a0cb305474aa7a1/nova/db/sqlalchemy/api.py#L461
15:37:15 jaypipes mriedem: we removed the direct linkage between the two on purpose
15:37:27 mriedem https://github.com/openstack/nova/blob/65402e1aeb770d077620f2935a0cb305474aa7a1/nova/db/sqlalchemy/api.py#L461
15:37:28 mriedem yeah
15:37:37 mriedem the db api tests are still doing the very old style linkage
15:37:47 mriedem so testing using those for a modern setup is really confusing
15:46:15 jaypipes edleafe: k, sorry about that. ready now.
15:46:16 jaypipes hangout?
15:51:20 mriedem sdague: -1 is specifically for expanding on this https://review.openstack.org/#/c/468066/1/specs/pike/approved/oslo-middleware-request-id.rst@48
15:51:23 mriedem otherwise +2
15:52:01 sdague mriedem: so, it's not sufficient that the patch already has that in it?
15:52:12 mriedem the spec is a doc
15:52:22 sdague sure
15:52:24 mriedem published as a doc, people reading those later shouldn't have to dig through lp to find the patch
15:52:55 edleafe jaypipes: cdent: so you suggested passing the instance UUIDs in the reqspec
15:53:20 edleafe That was my original approach, but dansmith preferred the RPC parameter approach, so I changed it
15:53:38 edleafe jaypipes: see https://review.openstack.org/#/c/463623/
15:53:45 jaypipes edleafe: right.
15:54:16 jaypipes edleafe: lemme walk through in my head whether the recent "continuing the automatic reschedule behaviour" thing affects my decision on that...
15:54:18 cdent edleafe: I don't really have a strong opinion. my natural inclination is parameters, but that's not been seasoned by years of nova-based RPC
15:55:07 edleafe jaypipes: cdent: my preference was reqspec (which is why I did it that way first), since it already had the pretty much useless 'instance_uuid' attribute
15:55:08 openstackgerrit Sean Dague proposed openstack/nova-specs master: oslo.middleware request_id spec https://review.openstack.org/468066
15:55:13 jaypipes dansmith: can you, in one sentence, explain your preference to change the RPC interface vs. add a field to the reqspec object?
15:55:21 sdague mriedem: done
15:55:35 jaypipes dansmith: I want to make sure I understand you completely.
15:56:00 dansmith jaypipes: we don't need to store the uuids in the database, right?
15:56:22 dansmith we've had this conversation a couple times
15:56:44 edleafe dansmith: but there is already the 'instance_uuid', which we don't store either
15:57:46 dansmith edleafe: um, what?
15:57:53 dansmith already instance_uuid in the reqspec?
15:58:00 edleafe yup
15:58:33 edleafe dansmith: https://review.openstack.org/#/c/463623/5/nova/objects/request_spec.py@77
15:58:38 dansmith what do you mean we don't store it
15:58:39 dansmith ?
15:58:49 dansmith ...right, I know it's in there
15:58:54 edleafe well, we don't *need* to store it
15:59:12 edleafe it's useless if num_instances > 1
15:59:15 dansmith okay not sure what that has to do with not adding another thing we don't need to store, which could be a hundred uuids :)
15:59:31 mriedem fuel on the fire makes it better right?
15:59:50 mriedem at what point do we add kitchen_sink to request spec?
16:00:21 edleafe I understand the reqspec to be the vehicle for passing the requested info to the scheduler
16:00:28 edleafe the scheduler needs this info
16:01:28 jaypipes dansmith: so the reason I was advocating passing in all the instance uuids in the reqspec was because I wanted to get rid of the retry stuff and do all of that in the scheduler (and thus we'd need all those UUIDs). But now that that is off the table, I'm not sure it makes sense any more.
16:01:50 dansmith aye
16:01:52 edleafe jaypipes: it definitely does
16:02:22 edleafe if num_instances > 1, how will the scheduler claim the resources if it doesn't know the consumer_id?
16:02:38 dansmith the uuid list is only something that makes sense for a single call to the scheduler, AFAIK, so it shouldn't be stuffed into the database, just something we pass like anything else, IMHO
16:03:19 jaypipes edleafe: a fair point.

Earlier   Later