Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-18
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/
16:04:59 edleafe Once I fix that, I think that that should be a quick approve
16:05:21 edleafe I.e., it's not changing a guideline or anything
16:05:35 elmiko ok, cool. i will remove my +2 with a note just for clarity sake
16:05:42 elmiko i agree with dtantsur's idea
16:05:42 edleafe schweet
16:06:28 edleafe I thought that the tags update was ready, but after thinking a bit more about Akihiro's comment, I want to revisit it https://review.openstack.org/#/c/642497/
16:07:05 edleafe And I was going to fast-approve the emai list name change https://review.openstack.org/#/c/632255/1
16:07:25 edleafe but it was stated that it was a dupe without referencing what it is a dupe of
16:07:31 edleafe Do you have any idea?
16:07:58 elmiko edleafe: i agree about Akihiro's comment, thanks for taking that on
16:08:05 dtantsur edleafe: I don't see a dup, let's approve it..
16:08:46 edleafe I just posted a reply to the dupe patch a few minutes ago. There's no rush, so if there is no good answer by next week, let's approve it then
16:09:49 elmiko edleafe: agreed
16:10:57 edleafe That's all I had on my plate to discuss
16:11:26 elmiko edleafe ++
16:17:26 edleafe https://review.openstack.org/#/c/651222 has been frozen
16:17:41 elmiko thanks edleafe
16:19:01 dtantsur w00t!
16:19:09 openstackgerrit Ed Leafe proposed openstack/api-sig master: Added Placement to the liaisons file https://review.openstack.org/645223
16:19:14 edleafe dtantsur: elmiko: ^^ Fixed the ordering
16:19:23 edleafe Either of you want to fast-approve that?
16:19:38 elmiko edleafe: looking now
16:19:50 edleafe Nobody will ask such a dumb question. We already know the answer is yes
16:20:26 efried Does the API SIG deal with things like adoption of OpenStack SDK?
16:20:49 dtantsur efried: it borders with our responsibilities, at least
16:20:53 elmiko ++
16:20:53 efried not to interrupt; feel free to come back to me when you reach an appropriate spot in the agenda
16:21:04 edleafe efried: not specifically, but we do say things like "yes, that's a good thing to do"
16:21:07 elmiko no real agenda, this is just open office hours
16:21:25 elmiko dtantsur edleafe , +wf on the liaison file
16:21:39 edleafe elmiko: kewl
16:21:42 dtantsur efried: I think it's a good topic for right now, but what exactly do you have in mind?
16:21:57 efried Okay, so this is mostly FYI: I'm kind of involved in / leading a charge to make nova use the sdk.
16:22:07 dtantsur if you need some to do some work, we have mordred to appoint
16:22:07 elmiko nice
16:22:13 elmiko LOL
16:22:22 efried https://blueprints.launchpad.net/nova/+spec/openstacksdk-in-nova
16:22:26 dtantsur because we don't do work here, it's not the goal of API SIG
16:22:27 efried mordred has already done some work.
16:22:43 dtantsur oh?
16:22:45 elmiko dtantsur ++
16:22:47 edleafe We pride ourselves on convincing others to do the work
16:22:56 elmiko XD
16:23:05 efried there's this: https://review.openstack.org/643601 which needs to be cleaned up and have UT added
16:23:14 efried but has been integration-tested and works.
16:23:28 dtantsur efried: I'd really like to get to switching ironic-inspector to use SDK for talking to ironic and swift
16:23:33 efried tl;dr: lets you set up Connection with oslo.config ksa opts instead of clouds.yaml
16:23:34 dtantsur I mean, get to it in Train
16:23:53 dtantsur efried: I'm very much in favor of that. very.
16:23:55 efried ...so we can make the transition transparent to operators initially.
16:24:24 efried and then there's this: https://review.openstack.org/#/c/643664/ which introduces the plumbing for sdk in nova
16:24:42 efried and the patch on top of it https://review.openstack.org/#/c/642899/ which starts the process of swapping out calls into ironicclient.
16:24:56 efried idea being to stack several of those ^ up until we can rip out ironicclient entirely.
16:25:09 efried (from nova)
16:25:38 efried I've got a new guy helping out with the nova things
16:25:45 efried but could use some help on the sdk side
16:25:58 efried there's the patch noted above, already started, could use closure
16:26:00 mordred yeah. I'll definitely be digging in to help
16:26:14 mordred and I need to finish that patch as soon as I can finish up all the meetings I've been stuck in this week

Earlier   Later