Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-17
13:29:32 mordred cdent: corvus is going to be doing a keynote on the topic too - but as a keynote, it'll obviously be missing details :)
13:30:15 cdent I will probably need to coralled in order to remember. Do not feel bad about hassling me if it comes to that. I'm not good at remembering things at large gatherings.
13:30:21 mordred I figure placement is a popular enough kid that if we get you hooked up it might serve as a good blueprint for other people - or if that doesn't work it can serve as good feedback
13:30:38 mordred cdent: me either. but I think this is a good targetted opportunity, so I'll do my best to remember
13:30:53 cdent I will endeavor as well
13:31:19 cdent btw: the docker stuff got a story too: https://storyboard.openstack.org/#!/story/2005463
13:39:54 elmiko cdent: ack, will take a look
14:47:23 elmiko cdent: are the storyboard comments an appropriate place to leave my thoughts about your idea?
14:47:47 elmiko (sorry, don't have a ton of storyboard experience)
14:48:27 cdent elmiko: If you like, but I was thinking of it more as fodder for some api-sig noodling that would then be reflected back to either to the story or a guideline if everyone loved it
14:48:49 cdent elmiko: basically if you have comments on the goal (get sharding working in placement) the story would be the right place
14:49:10 cdent but if you have coments on the concept of an 'openstack-shard: header' somewhere else might be better
14:50:42 elmiko ack, thanks!
14:51:02 elmiko at this point i'm working more at the conceptual level, athough i did follow the email thread
14:52:17 elmiko i actually find the placement stuff to be kind of exciting/invigorating for the openstack community. it's nice to see that this community can still accept projects with the potential for high impact. ++ imo
15:00:17 efried mordred, dtroyer: I had another thing I wanted to bring up about consuming the SDK in projects like nova/cyborg...
15:00:59 efried We find ourselves having a tough time with testing at several levels because of the internal magic Connection does when you instantiate it
15:01:52 efried and could really use a fixture to mock out enough of those bits that we can use Connection mostly like it's supposed to be used, just mocking e.g. response payloads for certain methods
15:03:00 efried but writing those fixtures in the consuming project is going to be either really brittle because we patch out internals that could change; or too high-level because we patch out the whole Connection and essentially rewrite the SDK framework in our fixture.
15:03:29 efried tl;dr: would you support openstacksdk publishing a ConnectionFixture for use by consumers' tests?
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

Earlier   Later