Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-25
14:36:18 sdague mriedem: heh, yeh
14:36:22 sdague I can fix the typo
14:37:36 openstackgerrit Sean Dague proposed openstack/nova master: Have nova.context use super from_context https://review.openstack.org/467995
14:37:40 mriedem alex_xu: jaypipes: re-confirming, but when deleting a service we don't actually delete the compute_nodes record,
14:37:45 mriedem nothing actually deletes the compute_nodes record
14:37:48 mriedem https://review.openstack.org/#/c/467220/4//COMMIT_MSG
14:40:04 openstackgerrit Matt Rabe proposed openstack/nova master: Query deleted instance records during _destroy_evacuated_instances https://review.openstack.org/467774
14:41:11 danpawlik mriedem: new drivers install correctly. I will add mention about windows and vendor_id
14:41:23 danpawlik in release notes soon
14:43:25 edleafe jaypipes: got a minute (or 10) to talk about https://review.openstack.org/#/c/465171/ ?
14:43:51 jaypipes edleafe: on call for 15, then free.
14:44:15 edleafe jaypipes: okee dokee
14:46:24 cdent edleafe: ping me when you start, I'd like to ride along please
14:46:41 edleafe cdent: roger that
14:47:32 sdague mriedem: the context bits look good to you now?
14:47:59 sdague given that we're blocking a constraint update on that
14:48:10 mriedem sdague: +1 until dansmith can take a look
14:48:19 sdague ok, cool
14:48:38 dansmith mriedem: sdague: I got a call starting in a few and then I'll look
14:48:45 sdague dansmith: sounds good
14:48:48 sdague thank you
14:49:02 sdague mriedem: I have an orthoginal (but related question)
14:49:27 sdague for nova to be a good player in global request id, and accept them, we need https://review.openstack.org/#/c/467998/
14:49:33 alex_xu mriedem: yea, i think so. and interesting bug, add it into review list
14:49:39 sdague which is going to cause an extra http header to emit
14:49:50 sdague microversion?
14:49:57 mriedem alex_xu: i'm fixing the test in that one
14:50:10 sdague alex_xu might also want to weigh in there
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

Earlier   Later