Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-08
15:10:34 bauzas cool, on a meeint
15:10:38 bauzas meeting*
15:11:47 cdent efried: did you check if x-server-management url was used anywhere? it appears to be part of the reason why you've appended /auth to the auth_url and that jarred while reviewing
15:12:07 efried jarred like hell when I was writing it too :(
15:12:44 efried cdent: I checked my devstack before and after the patch, and the headers coming back with the version document are the same with keystone/password
15:13:23 efried cdent: note that the noauth middleware exists solely for test, which is confusing that it's a) not under a test/ subdir, and b) documented as conf'able. That confused (me and) stephenfin as well.
15:13:44 cdent yeah, I've left a comment about that
15:13:52 cdent and then fell in this x-server-management hole
15:14:01 cdent I think it is 9yo ancient history
15:15:21 efried cdent: I can't actually find reference to that header in keystone[auth|middleware]
15:15:39 cdent it's not anywhere in .tox/py37 when i grep
15:15:47 cdent see: https://wiki.openstack.org/wiki/Obsolete:API for the main reference i could find
15:16:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_dest compute method https://review.opendev.org/633293
15:16:47 openstackgerrit Matt Riedemann proposed openstack/nova master: Add PrepResizeAtDestTask https://review.opendev.org/627890
15:16:48 openstackgerrit Matt Riedemann proposed openstack/nova master: FUP for I66d8f06f19c5c631e33208580428aa843abb38d2 https://review.opendev.org/678951
15:16:48 openstackgerrit Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.opendev.org/634832
15:16:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.opendev.org/627891
15:16:49 openstackgerrit Matt Riedemann proposed openstack/nova master: Add finish_snapshot_based_resize_at_dest compute method https://review.opendev.org/635080
15:16:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Add FinishResizeAtDestTask https://review.opendev.org/635646
15:16:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Execute CrossCellMigrationTask from MigrationTask https://review.opendev.org/635668
15:16:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Plumb allow_cross_cell_resize into compute API resize() https://review.opendev.org/635684
15:16:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Filter duplicates from compute API get_migrations_sorted() https://review.opendev.org/636224
15:16:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Start functional testing for cross-cell resize https://review.opendev.org/636253
15:16:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle target host cross-cell cold migration in conductor https://review.opendev.org/642591
15:16:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Validate image/create during cross-cell resize functional testing https://review.opendev.org/642592
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Add zones wrinkle to TestMultiCellMigrate https://review.opendev.org/643450
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for cross-cell finish_resize failing https://review.opendev.org/643451
15:16:54 openstackgerrit Matt Riedemann proposed openstack/nova master: Refresh instance in MigrationTask.execute Exception handler https://review.opendev.org/669012
15:16:55 openstackgerrit Matt Riedemann proposed openstack/nova master: Add negative test for prep_snapshot_based_resize_at_source failing https://review.opendev.org/669013
15:16:56 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add confirm_snapshot_based_resize_at_source compute method https://review.opendev.org/637058
15:17:02 efried cdent: results in codesearch all look crusty too.
15:17:19 cdent rackspace thing
15:18:28 efried last edit on that wiki page was 2013, but the content about that header wasn't changed since 2010.
15:18:46 efried (assume that's what you meant by 9yo)
15:21:21 artom dansmith, are you using the service user in your image pre-cache series?
15:21:44 dansmith artom: no, but I think the service token thing is automatic if configured no? /cc mriedem
15:22:05 dansmith artom: meaning not specifically, but service token will be important for this to work in a lot of cases
15:22:18 artom I thought you had to specifically get it? I'm trying to find other examples in the code
15:23:01 efried gibi: stephenfin: I'm going to edit the commit message on https://review.opendev.org/#/c/686801/ without rebasing everything on top of it and then fast approve it, cool?
15:23:16 mgagne mriedem: we no longer use the middleware you mentioned (to force volume-backed flavor)
15:23:28 gibi efried: cool with me
15:23:39 mriedem artom: it's built in if configured
15:23:40 dansmith artom: to use the service user as your credentials I think so, but isn't there some new thing that lets the service use its token to allow use of an expired user token?
15:23:43 dansmith I thought that was automatic
15:24:38 mriedem mgagne: oh really, what changed?
15:24:47 efried dansmith: You have to do a thing in code to get service user melded into your context. I don't think we're doing that for cinder yet. But once that's done, it will happen automatically if the service user is set up in your conf.
15:25:12 artom mriedem, so it's automagic from our POV? Ie, if we hit the image API with an expired token, it'll convert to use the nova service user?
15:25:14 dansmith efried: okay that doesn't jive with what mriedem just said
15:25:16 mriedem artom: see https://github.com/openstack/nova/blob/master/nova/service_auth.py#L36
15:25:26 mriedem efried: this is glance
15:25:28 dansmith efried: or do you mean it's done for glance already (which covers me)?
15:25:31 mriedem and it already goes through ^
15:25:44 mgagne mriedem: we do have a local orchestrator for one region which requires volume-backed flavor. other regions now have local storage available for all flavors.
15:25:46 mriedem glane was the #1 use case for the service user stuff from osic
15:25:54 mriedem b/c of token timeouts during long snapshots
15:25:54 efried dansmith: sorry, I was wrong about cinder, which already does the service auth wrapper; and yes, so does glance.
15:26:02 dansmith efried: ackj
15:26:11 efried (swedish for 'ack' ^ )
15:26:22 dansmith mriedem: what is the magic sauce for doing an api samples test with an empty response?
15:27:08 mriedem i'd have to dig
15:27:19 mriedem but i was wondering, is 202 the correct response if there is no body? should it be 204?
15:27:22 zigo If I run "nova host-evacuate-live", will it keep my VMs in their original availability zones?
15:27:33 mgagne mriedem: as for the local orchestrator, the user doesn't have access to the Nova API. If he had access to the API, we would probably have to put that middleware back in. (I don't see that one coming anytime soon)
15:27:43 dansmith mriedem: le shrug
15:27:52 mriedem cdent: "is 202 the correct response if there is no body? should it be 204?"
15:28:11 cdent 204 is if there's no body and you're done
15:28:13 dansmith mriedem: I guess maybe I validate the return value manually instead of calling the thing that would process a template
15:28:17 openstackgerrit Eric Fried proposed openstack/nova master: nova-net: Make even more nova-net stuff optional https://review.opendev.org/686801
15:28:20 dansmith aight
15:28:32 cdent 202 is "imma do a bit more, check back later"
15:28:39 mriedem cdent: yeah in this case we're not done,
15:28:43 mriedem rpc cast to conductor
15:28:46 mriedem but no response body
15:28:49 dansmith yeah, async but no response
15:28:55 gmann you can skip the verify_response and just check the status code. that is how we did for action APIs with no response
15:29:24 cdent in that 202 is probalby fine as long as somewhere in the response (header or body) there is a reference to how I check back later
15:29:43 mriedem right now there is no checking back later
15:29:53 dansmith yeah, specifically uncheckable
15:29:57 mriedem i.e. there is no status tracking or anything
15:30:59 cdent then from the user's standpoint a 204 might make more sense
15:31:05 dansmith gdi cdent
15:31:09 dansmith 202 is less work for me
15:31:27 mriedem heh, how?
15:31:31 cdent dansmith: have a read of https://httpstatuses.com/202 and make your choice. either is probalby fine
15:31:40 dansmith mriedem: because 202 is done and checked in a few places already :)
15:31:47 mriedem that's what i figured
15:32:26 mriedem "The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. "
15:32:28 mriedem sounds spot on
15:32:33 mriedem especially the batch-oriented part
15:32:44 dansmith cdent: right so we picked 202 specifically because all of those things are true.. it's async, it may or may not happen, some constraints are checked later and may cause us to do nothing with no warning
15:32:54 dansmith mriedem: yeah, exactly
15:33:15 dansmith once per day batch is exactly this
15:34:14 cdent yeah, 202 is probably fine
15:34:15 mriedem unrelated to the response code, something i thought about while tossing and turning at 3am last night was that your api validation should probably check that the list of dicts is a unique set of image IDs and 400 if not
15:34:29 dansmith mriedem: already doing that :)
15:34:33 mriedem whew
15:34:36 gibi bauzas: tested your latest audit patch with bandwidth and left the result in https://review.opendev.org/#/c/670112/7
15:34:51 bauzas gibi: /me is scared
15:35:00 efried fwiw I vote for 202 dansmith cdent mriedem
15:35:30 gibi bauzas: There is some confusing printout, and as you stated the current code does not handle child RPs

Earlier   Later