Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-08
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
15:35:43 bauzas gibi: thanks for the paste, very insightful
15:36:38 gibi bauzas: cleary there is progress as the instance and the compute is found in cell1.
15:36:56 gibi bauzas: no worries. I leave for today now anyhow
15:37:11 bauzas gibi: I appreciate your positivity :
15:37:12 bauzas :p
15:37:23 gibi :)
15:49:09 openstackgerrit Dan Smith proposed openstack/nova master: Add image caching API for aggregates https://review.opendev.org/687140
15:50:14 openstackgerrit Stephen Finucane proposed openstack/nova master: fixtures: Add support for security groups https://review.opendev.org/686802
15:50:18 openstackgerrit Stephen Finucane proposed openstack/nova master: fixtures: Add support for security groups https://review.opendev.org/686802
15:50:25 artom dansmith, left some thoughts about exception handling in your series
15:50:35 artom dansmith, tell me if I'm way off base
15:51:13 dansmith artom: ack, thanks
15:51:32 dansmith mriedem: looks like the bulk of our aggregate docs are in the user guide.. is that where you think I should put my stuff?
15:53:20 mriedem dansmith: rebase, that all recently moved and just merged
15:53:38 mriedem https://docs.openstack.org/nova/latest/admin/aggregates.html
15:53:54 dansmith mriedem: like, this week?
15:53:57 mriedem yeah
15:54:02 dansmith mkay
15:54:07 mriedem https://review.opendev.org/#/c/667133/
15:54:13 mriedem merged last night
15:54:41 mriedem efried: before i make changes please ack that i've answered your questions here https://review.opendev.org/#/c/686835/2/nova/tests/functional/test_boot_from_volume.py@192
15:56:55 mriedem dansmith: if we had docs on the image cache in general i'd say that would be a good place but we don't have any docs about the image cache :(
15:57:06 dansmith heh
15:58:27 mriedem i guess another place you could stuff it is https://docs.openstack.org/nova/latest/admin/manage-the-cloud.html if that aggregates page isn't a good fit
16:01:05 dansmith erm, the aggregates page seems better than that
16:01:15 dansmith but obviously something image- or imagecache-specific would be better
16:01:33 dansmith I'll add it here in minimal detail and then we should probably shoot for some imagecache doc
16:02:34 dansmith looks like something has reshuffled in that aggregates doc to put the usage section after the more advanced topics
16:02:41 mriedem i think a pretty simple image cache doc could start with a high level description, list of drivers that support it, and the related config options
16:03:00 mriedem dansmith: you'll have to wrestle with stephenfin about that
16:04:09 dansmith heh yeah all the google linkage is broken now after that admin/user shuffleup
16:04:47 mriedem yeah i'm not surprised, the patch didn't account for redirects
16:06:16 dansmith yeah that new aggregates page is just kindof a mess and the ordering makes no sense
16:06:24 dansmith I guess I'll just chuck my thing at the bottom
16:06:34 openstackgerrit Merged openstack/nova master: compute: refactor volume bdm rollback error handling https://review.opendev.org/656500
16:06:41 openstackgerrit Merged openstack/nova master: doc: Improve PDF document structure https://review.opendev.org/682746
16:06:51 openstackgerrit Merged openstack/nova master: docs: Remove a whole load of unused images, most remainder https://review.opendev.org/686211

Earlier   Later