| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-08-05 | |||
| 16:52:58 | mordred | OH | |
| 16:53:00 | mordred | it's because I can't read | |
| 16:54:06 | openstackgerrit | Monty Taylor proposed openstack/cliff master: Pin cmd2 on python3 as well https://review.opendev.org/674652 | |
| 16:54:10 | mordred | frickler, dtroyer: ^& | |
| 17:01:05 | efried | [2] https://opendev.org/openstack/nova/src/branch/master/nova/tests/fixtures.py#L2125 | |
| 17:01:05 | efried | [1] https://logs.opendev.org/25/674625/1/check/nova-tox-functional-py36/27b16b6/testr_results.html.gz | |
| 17:01:05 | efried | mordred: This [1] is likely because of the way we're (not) fixturing [2], which was pretty weak to begin with. I suspect I can get moving by adding a mock for get_endpoint_from_catalog, and then possibly also get_session_client... but I'm kinda not sure I should keep chasing fixtures for sdk internals like that. Thoughts? | |
| 17:13:26 | mordred | efried: hrm. you're making my brain do work | |
| 17:13:44 | mordred | efried: I agree - I don't think you should need to chase fixtures for internals lke that | |
| 17:14:11 | efried | I did open a story for sdk to publish fixtures for this purpose, but people are busy | |
| 17:14:22 | mordred | yeah. and I really want to publish those | |
| 17:14:46 | efried | perhaps initially it's as simple as moving the one from nova into sdk, and it can get better refined later. | |
| 17:14:51 | mordred | efried: maybe for today just adding in a get_endpoint_from_catalog mock - but let's elevate the priority of getting you a real fixture | |
| 17:15:19 | efried | okay, I'll try that on the nova test patch and see what shakes out. | |
| 17:15:55 | mordred | efried: cool. and I'll see if I can sort out something WRT workable long-term exported fixture status | |
| 17:16:45 | efried | thanks mordred | |
| 17:24:54 | openstackgerrit | Merged openstack/openstacksdk master: Enable ansible module test for keypair to check return data https://review.opendev.org/674333 | |
| 17:28:05 | tosky | mordred: hi, is there any update on version handling in SDK (and then microversioning in osc)? I happened to discuss about https://review.opendev.org/#/c/590807/ a few days ago with some cinder developers | |
| 17:58:24 | mordred | tosky: well - sdk handles versions and microversions - but I think to take advantage of that in osc we need to make progress on osc4 | |
| 17:58:44 | mordred | and then start using sdk methods instead of python-cinderclient methods for cinder operations - it's not going to be a QUICK process | |
| 18:01:40 | tosky | mordred: so it does not match that "a couple of weeks" from that comment, I guess? Can you share there (or some public place) what is missing? Because this was one of the blockers for cinder to even start considering OSC as proper replacement | |
| 18:01:50 | tosky | or so I understood | |
| 18:02:10 | tosky | and maybe other people could help with the porting effort | |
| 18:02:26 | mordred | tosky: I just replied on the change - I think we need to circle with dtroyer on plans here - but yes, I totally agree it would be best if we get people to help with the porting effort | |
| 18:09:49 | tosky | mordred: slightly different question - I noticed that the openstackclient functional tests implements their own base classes; have you considered using CLIClient from tempest.lib? | |
| 18:10:18 | tosky | It can be used without the rest of tempest; that's what the python-cinderclient functional tests do (stestr run and that's it) | |
| 19:01:14 | openstackgerrit | Eric Fried proposed openstack/openstacksdk master: Allow limiting Connection service_types from oslo.config https://review.opendev.org/674675 | |
| 19:01:24 | efried | mordred: howza ^ | |
| 21:14:33 | mordred | efried: awesome | |
| 21:43:21 | openstackgerrit | Merged openstack/openstacksdk master: Fix bm tests: sort lists being compared https://review.opendev.org/674640 | |
| 23:53:45 | openstackgerrit | Christian Berendt proposed openstack/openstacksdk master: Update betacloud vendor entry https://review.opendev.org/674715 | |
| #openstack-sdks - 2019-08-06 | |||
| 08:24:43 | dtantsur | Shrews, mordred: there was an existing patch for the traits problem, but thanks for fixing it anyway | |
| 10:22:17 | openstackgerrit | Merged openstack/openstacksdk master: Update betacloud vendor entry https://review.opendev.org/674715 | |
| 10:22:18 | openstackgerrit | Merged openstack/openstacksdk master: Add Python 3 Train unit tests https://review.opendev.org/667494 | |
| 10:32:13 | dtantsur | mordred: we don't support global_request_id in SDK, do we? | |
| 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... | |