Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-06
10:36:55 dtantsur also it seems that the Volume support it very basic, right?
12:10:11 mordred dtantsur: I'm not sure what global_request_id is? so probably not - but maybe we do via keystoneauth?
12:11:09 mordred dtantsur: and yeah - the openstack.block_storage layer could use more love for sure.
12:25:46 dtantsur oh, yeah, global_request_id is a keystoneauth thing. I just need to know how to pass it to a Connectin..
12:44:33 mordred dtantsur: ok. I just read the global_request_id stuff in ksa
12:45:08 mordred this is going to be a fun one ... because it's supposed to be set per-request, but the individual requests aren't partcularly exposed
12:46:58 mordred dtantsur: I almost think we should make a $something like a context manager or something, so you coudl say with conn.global_request_id(the_id) as req_conn: req_conn.baremetal.machines() ... or something similar
12:48:08 mordred (because a Connection can be used from a multi-threaded context, so just setting a global_request_id attribute on the Connection object so that it picked it up and passed it in to the request arguments would be a step, but it wouldnt' be the full picture)
12:48:44 dtantsur Ironic currently creates a connection per request (may end up in 1-10 sdk requests, but still)
12:49:04 dtantsur but I like the idea with a context manager
12:50:34 mordred dtantsur: let me poke for just a sec - I think I can make you a patch real quick
13:04:08 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for global_request_id https://review.opendev.org/674807
13:04:13 mordred dtantsur: ^^ how about that?
13:04:22 dtantsur lemme see
13:04:52 mordred dtantsur: (it should also let you just set it in the constructor in ironic since you're only doing connection per request anyway)
13:23:58 rm_work dtroyer: apparently here
13:24:13 dtroyer rm_work: +1
13:25:34 rm_work dtroyer: barbican meeting happening right now and there's some discussion of the right direction for client work, like ... python-Xclient, openstack-sdk, and interfacing with openstackclient etc
13:25:56 rm_work i dunno if they want to spend meeting time on it or if we might just follow up after, but i know you had some thoughts on this from the last time we talked at the PTG I think?
13:27:10 rm_work they're considering deprecating their python-barbicanclient and moving to openstacksdk only? is that right right direction?
13:27:22 rm_work and then would they write in openstack-client support via the SDK code?
13:27:25 dtroyer rm_work: I'm in another meeting at the moment but everything is basically converging on SDK, so I'd support tha
13:27:30 rm_work kk
13:27:36 rm_work np maybe can talk after
13:31:02 mordred rm_work: yes - deprecating python-*client and moving to SDK is the right direction for sure
13:43:02 rm_work ok cool thanks :)
13:55:43 efried mordred, dtantsur: I just added that global_request_id kwarg in ksa's Session.request so you can set it per call
13:56:01 efried I haven't looked at what you're doing in sdk yet...
13:56:02 mordred efried: yah - I bumped the sdk min so we can consume it
13:56:09 efried ah cool
13:56:17 mordred (and added some hooks and stuff)
13:56:48 efried okay, I'll take a closer look.
14:04:06 dtantsur great!
14:20:43 Shrews dtantsur: oops, sorry for missing the traits fix
16:37:30 Shrews mordred: so that code... seems to delete a single object, yet from my cleanup, i see multiple objects for each image. does sdk split that up into separate objects, or is that something rax does behind the scenes?
16:38:03 mordred Shrews: it's something we do ... one sec
16:38:30 mordred Shrews: if you look in openstack/cloud/_object_store.py - and look for "use_slo"
16:39:02 mordred Shrews: and then _upload_large_object
16:40:24 mordred Shrews: https://docs.openstack.org/swift/latest/overview_large_objects.html is the docs for the feature
16:42:01 Shrews ok. i'll have to study this
16:42:23 mordred Shrews: and in delete_object in openstack/cloud/_object_store.py - we check to see if it was a static-large-object. if not, we pass the multipart-manifest = delete param which shoudl cause deleting the dynamic-large-object to delete all the segments. and if it is a static large object deleting the manifest is _supposed_ to delete the segments *I think*
16:42:45 mordred it's also possibel that with static large objects it's our responsibility to delete the segments
16:42:47 mordred or with dynamic
16:42:52 mordred I might be getting the boolean backwards
16:43:11 mordred anyway - yes - please learn things - I'm probably wrong about many parts
16:48:08 timburke ?multipart-manifest=delete works on SLOs -- it does *not* work on DLOs
16:50:55 mordred timburke: on DLOs, we're supposed to delete all of the segments ourselves, yes?
17:16:13 timburke mordred, yup, client's gotta manage the segments for DLO
18:14:03 mordred Shrews: ^^ - ok, so on DLO we're almost certainly leaking segments
18:14:53 mordred Shrews: but I don't see anywhere in nodepool where we're setting use_slo to false so I'd expect we're using SLO
18:15:44 Shrews mordred: would that come from a clouds.yaml setting?
18:16:08 Shrews rackspace profile maybe?
18:17:30 Shrews hrm, all i see is "image_api_use_tasks": true
18:29:05 mordred yeah - it's not a setting we set in clouds.yaml
18:29:26 mordred Shrews: so - a few things ...
18:30:07 mordred Shrews: I think it's entirely possible that we will leak swift objects any time sometihng _else_ goes wrong in an image upload that doesn't trigger that finally
18:30:27 mordred also - maybe we leaked a bunch of things a while back - I think there was a time when the default of use_slo was the opposite
18:31:08 mordred Shrews: maybe on use_tasks clouds we should have delete_image go and look for the object that would have been used and try to delete it?
18:31:41 Shrews maybe
18:34:19 Shrews mordred: is the slo manifest an object within itself? where would i find it?
18:35:39 Shrews wondering if i can view it from the openstack client. all i see are the segments in 'images'
18:40:27 mordred Shrews: it is an object
18:40:55 mordred Shrews: iirc, there should be a bunch of segment objects like foo/123456 - and then there should be a manifest object foo
18:41:36 mordred which should contain a json document pointing to all of the segment objects
18:47:41 Shrews mordred: ah, maybe something...
18:47:46 Shrews openstack.exceptions.BadRequestException: BadRequestException: 400: Client Error for url: https://storage101.ord1.clouddrive.com/v1/MossoCloudFS_28a933f9-900d-40b8-9de3-deb24d213aa2/images/opensuse-15-1564920980?multipart-manifest=put, Bad Request
18:48:09 Shrews mordred: if we fail to save the manifest, i bet we don't (can't?) delete the segments
18:49:25 Shrews that one happened 2 days ago, and is the only image segments i did not delete in ORD because it was too recent
18:50:21 Shrews mordred: so feeling like your first suspicion might be viable
18:51:29 mordred Shrews: ah - yeah
18:52:11 mordred Shrews: sounds like we should maybe retry the manifest put - and if it exceeds retries maybe unwind deleting teh segments since we do have the list of segments in the manifest at that point?
18:52:57 Shrews mordred: yup
18:53:30 mordred Shrews: also - a retry at that point is WAY cheaper than a hard-fail followed by re-uploading all of the segments later
18:56:28 Shrews totally
18:56:47 Shrews will see what kind of code i can barf out after the meeting
18:57:49 Shrews mordred: also, i'm guessing the 'images_segments' container is an old artifact? doesn't seem to be used
18:58:46 Shrews it exists in rax, but empty across the board
19:08:41 mordred yeah - I thnk old
19:12:06 mordred efried: dammit. your sensible request for tests has caused me to remember that something else is broken and find a whole new thing is broken
19:17:20 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add support for global_request_id https://review.opendev.org/674807
19:17:45 mordred efried, dtantsur|afk: ^^ that adds a test and fixes the other issues - and also 2 things are borked that I would like to get fixed
19:49:22 efried mordred: ack, and #sorrynotsorry
20:00:53 mordred Shrews: we're naming the swift object after the image name, right?
20:01:20 Shrews mordred: i believe so
20:01:33 mordred Shrews: so we could also do a scan of objects matching the pattern ${imagename}/${index} on image delete perhaps?
20:02:26 Shrews mordred: well, yeah, but why? as an extra precaution?
20:03:49 efried mordred: reviewed
20:05:29 Shrews mordred: unless in rax, the images automatically reference the swift object? i had assumed that there was some step after uploading to make it a proper "image", but maybe that's not correct
20:07:40 mordred Shrews: well - there's no swift object anywhere but rax
20:07:52 mordred Shrews: but yeah - extra precaution - probably not worth the energy
#openstack-sdks - 2019-08-07
07:52:48 openstackgerrit Adrian Turjak proposed openstack/keystoneauth master: add support for auth_receipts and multi-method auth https://review.opendev.org/675049
07:59:10 openstackgerrit Adrian Turjak proposed openstack/keystoneauth master: add support for auth_receipts and multi-method auth https://review.opendev.org/675049
10:10:06 dtantsur mordred: we don't have anything to build swift temporary URLs in SDK, do we?
10:13:05 dtantsur we could probably just copy https://opendev.org/openstack/python-swiftclient/src/branch/master/swiftclient/utils.py#L71 as it is :)
13:04:47 mordred dtantsur: we've got support for form_post which uses the temp-url-key infrastructure
13:05:04 mordred dtantsur: so yeah, we could probably lift in that code for generating temp_urls themselves pretty easily
13:05:09 openstackgerrit Loan Harrouin proposed openstack/openstacksdk master: Add get_actions for servers https://review.opendev.org/675113
13:05:55 dtantsur makes sense. it seems that the code in swiftclient doesn't depend on anything specific to swiftclient
13:08:40 openstackgerrit Loan Harrouin proposed openstack/openstacksdk master: Add get_actions for server resource https://review.opendev.org/675113
13:22:30 edleafe Who knew that our API work extended to snail mail? https://twitter.com/shawnacscott/status/1158813468704698368

Earlier   Later