Earlier  
Posted Nick Remark
#openstack-sdks - 2019-04-17
15:06:09 mordred efried: yes.
15:06:31 mordred efried: so - in sdk's tests, we use requests-mock and do exactly that - we only mock the HTTP interactions, not the actual connection methods
15:06:49 mordred efried: to support that, we have a bunch of fixtures and other stuff to set up keystone catalogs and endpoints and whatnot
15:07:18 efried mordred: How hard to expose some subset of those fixtures?
15:07:23 mordred I've been meaning for a WHILE to make that stuff re-consumable - because people consuming Connection should also really be mocking http not mocking methods
15:07:46 mordred it shouldn't be too hard- it'll mostly be about organization and cleanup
15:08:13 efried mordred: though I wouldn't actually mind being able to mock the object thingies rather than the raw http payloads...
15:08:16 mordred and probably making a top-level Fixture class that can be easily instantiated
15:08:38 mordred efried: the tests we inherited from the sdk codebase do that ... and I find them to be exceptionally brittle
15:09:10 mordred however - if it's a thing that people need to be able to do and someone figures out how to write it - I would not be opposed to it living in the sdk repo
15:09:27 efried So e.g. I can say mock.patch.object(conn.image, 'images', side_effect=[list, of, Image, objects, returned, by, the, generator])
15:10:01 efried that ^ wouldn't exactly work, since the return value needs to *be* the generator, but it's the general idea.
15:10:33 mordred yeah - I find it easier to do:
15:10:35 mordred dict(method='GET',
15:10:37 mordred uri='https://image.example.com/v2/images',
15:10:39 mordred json=self.fake_search_return),
15:10:43 mordred but that's just me :)
15:11:18 mordred in any case - I am very supportive of the problem you want to solve
15:11:30 mordred quibbling about impl details notwithstanding
15:11:39 efried cool. Finding someone to do the work any time in the near future, that's going to be the tough part.
15:11:49 mordred yeah. but maybe we can!
15:11:58 efried I guess I should file a story or something.
15:13:14 mordred efried: mildly related - where's the nova ptg schedule? I believe there's an sdk related topic and I want to make sure it's on my calendar so I don't forget about it
15:13:45 efried mordred: Other than slots for three or so of the xproj sessions, I haven't put it together yet.
15:14:59 mordred ok. cool. I'll keep my eyes out :)
16:06:49 efried mordred, dustinc_away: https://storyboard.openstack.org/#!/story/2005475
17:54:56 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
18:17:52 elmiko edleafe, cdent, wanted to give you a heads up, etoews is giving a talk about the work he's doing in about 45 minutes, url for video conference https://bluejeans.com/8933049334
18:18:16 elmiko the general topic has been relayed as gitops
18:18:42 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Prevent setUpClass failures in volume v1 tests https://review.openstack.org/648760
18:18:42 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
18:18:45 cdent blast from the past
18:18:49 elmiko yeah totally!
18:19:00 elmiko when i saw his name popup on my email i thought i had to check it out
18:19:15 elmiko i guess the openshift commons group invited him to give a talk
18:19:23 cdent In about 45 minutes I hope to be buried in my dinner
18:19:50 edleafe That's a novel way of disposing of a corpse
18:20:14 cdent need something to eat for the long journey
18:21:08 elmiko lol
18:21:30 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
18:21:41 elmiko cdent: as a followup to your request from earlier, i think the sharding story makes sense at the level presented in the doc
18:22:02 elmiko i think there will be plenty of technical challenges, but in general i like the /idea/
18:22:43 cdent elmiko: does a header seems like the sensible route?
18:23:08 elmiko i think so, for me it has the lowest impact on things that are already installed
18:23:23 elmiko i can't imagine modifying the body of requests, well i can but it's not pretty
18:23:51 elmiko the other option would be something in the uri, but i /really/ don't like that
18:24:28 elmiko imo, unless someone comes with a better idea, the header seems like a good first approach
18:25:31 cdent cool, thanks
18:25:39 elmiko np =)
18:26:17 cdent i'm hoping that mordred is going to have something to say about a universal "this is openstack X" identifier that is already in the works
18:28:15 elmiko wouldn't that be lovely
19:00:53 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
19:52:29 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
21:23:23 openstackgerrit Jeremy Houser proposed openstack/python-openstackclient master: Alter test_volume.py to ensure volume deletion https://review.openstack.org/652682
22:53:46 openstackgerrit Eric Fried proposed openstack/openstacksdk master: WIP Make factory for a CloudRegion from CONF objects https://review.openstack.org/643601
22:54:52 efried mordred, dustinc_away: FYI, filed a blueprint for openstacksdk-in-nova (https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova) and updated topics and commit messages in the nova and sdk patches to refer to it https://review.openstack.org/#/q/topic:bp/openstacksdk-in-nova+(status:open+OR+status:merged)
22:57:57 openstackgerrit Eric Fried proposed openstack/openstacksdk master: WIP Make factory for a CloudRegion from CONF objects https://review.openstack.org/643601
#openstack-sdks - 2019-04-18
08:08:52 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
08:11:09 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update baremetal to use proxy logger https://review.openstack.org/652083
09:41:56 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: Add "name" filter in "list" call when retrieving a single register https://review.openstack.org/637238
10:30:43 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
13:03:55 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Remove now unused task_manager file https://review.openstack.org/653731
13:43:15 gtema mordred: do you have an opinion on https://review.openstack.org/#/c/651534/12/openstack/resource.py@425?
13:43:41 gtema do we want to support this logic everywhere?
13:46:55 gtema dtantsur: https://review.openstack.org/#/c/651534/12/openstack/image/v1/image.py@103 - an existing logic to give possibility to the requestor to self iterate over the result
13:47:16 mordred gtema: yes - I replied
13:47:42 gtema thanks
13:48:22 gtema I can also move "output" logic under the Image.download method if we want it now
13:48:53 mordred yeah - I think that's a good idea
13:49:24 gtema ok. Will also add few tests on the proxy.download_image (were missing so far)
13:50:10 dtantsur gtema: then why not change the second place to just 'return resp'?
13:50:34 gtema hmm
13:50:48 gtema maybe
13:54:24 gtema what do we want for chunk_size?
13:54:44 openstackgerrit Dmitry Tantsur proposed openstack/openstacksdk master: Support for the baremetal introspection service https://review.openstack.org/650044
13:54:51 dtantsur mordred: a new service ^^^ \o/
13:55:09 dtantsur gtema: I'd put at least 4k, but I don't have any reliable reasoning behind it
13:55:15 dtantsur ideally, we should benchmark it :)
13:56:07 gtema :D Benchmark will actually depend on the chosen setup/platform/image/etc
14:01:44 gtema dtantsur: returning resp instead of content breaks current behavior. This is not something I wanted to get with this change
14:17:04 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Continue refactoring of the image https://review.openstack.org/651534
14:21:47 dtantsur gtema: ah, I see
14:49:09 openstackgerrit Merged openstack/openstacksdk master: Move Orchestration methods into Proxy https://review.openstack.org/649273
15:02:38 openstackgerrit Merged openstack/openstacksdk master: Allow replacing service implementation https://review.openstack.org/648704
16:00:10 elmiko API SIG office hour is now open!
16:00:30 edleafe Yay!!!!
16:00:34 elmiko \o/
16:00:51 elmiko ooh la la
16:01:41 edleafe I did want to go over some outstanding api-sig patches, if that's ok with you
16:02:10 elmiko sure, i'm game!
16:02:15 edleafe I think the DNS guideline is ready for freeze https://review.openstack.org/#/c/651222/
16:02:30 elmiko ++
16:02:47 edleafe So is the version discovery doc, but it has a merge conflict https://review.openstack.org/#/c/459405/
16:03:00 elmiko i guess we should just send custom freeze emails to the ml since we don't have the newsletter?
16:03:22 elmiko oh wow, so exciting to see the version discovery finally getting there =)
16:03:38 edleafe Generally that's what the tools do: send an email to the liaisons, and add them to the reviewer list for the patch
16:04:04 elmiko ok, sweet
16:04:06 edleafe But sure, we could also send out an email
16:04:29 elmiko i suppose we don't have to, i was just curious and apparently the cob-webs have gotten the better of that part of my memory XD
16:04:47 edleafe dtantsur had a suggestion on the liaisons file patch https://review.openstack.org/#/c/645223/

Earlier   Later