Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-10-08
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
16:06:57 openstackgerrit Merged openstack/nova master: trivial: Change name of network provided by NeutronFixture https://review.opendev.org/686798
16:07:05 openstackgerrit Merged openstack/nova master: nova-net: Stop mocking the instance network cache https://review.opendev.org/686799
16:07:16 openstackgerrit Merged openstack/nova master: trivial: Make it obvious where we're getting our names from https://review.opendev.org/686800
16:09:13 mriedem luckily infra has a report of active docs 404s
16:10:35 sean-k-mooney the most annoying thing about google+docs is it does not priorties latest
16:10:47 mriedem http://files.openstack.org/docs-404s/
16:11:11 dansmith sean-k-mooney: that's probably good since we apparently just break our latest a lot
16:11:49 mriedem 5 /nova/latest/user/aggregates.html
16:11:55 mriedem yeah we should have a redirect for that
16:11:58 mriedem stephenfin: ^

Earlier   Later