| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-03-27 | |||
| 20:39:52 | openstackgerrit | Pierre Riteau proposed openstack/openstacksdk master: Do not disregard tags when updating stacks https://review.openstack.org/643195 | |
| #openstack-sdks - 2019-03-28 | |||
| 00:31:49 | dtruong | mordred Would it be possible to cut a new openstacksdk release off master branch? That would fix the connection leak problem for Senlin. | |
| 00:32:06 | dtruong | I also send an email to openstack-discuss with the same question: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004295.html | |
| 06:46:28 | mordred | dtruong: yes, I thnk that should be no problem | |
| 06:49:42 | mordred | dtantsur|afk: boo to that being broken. :( | |
| 07:02:42 | mordred | dtruong: oh - I say that - doing it as a release for stein might be harder because of the various freezes. | |
| 07:06:12 | mordred | dtruong: I'm going to ask the release team what they think | |
| 07:48:12 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add support for generating form-post signatures https://review.openstack.org/639760 | |
| 07:48:25 | mordred | timburke: ^^ thanks! nice catch | |
| 07:49:17 | mordred | Shrews, dtantsur|afk: ^^ timburke found a bug in that. I fixed the bug and added unit tests to actually exercise the methods in question which would have shown how horribly broken they were | |
| 08:59:02 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Move set_temp_url_key logic into resource objects https://review.openstack.org/648347 | |
| 09:01:09 | gtema | mordred, dtantsur: can you please do a next quick review on https://review.openstack.org/#/c/642218/ (split openstackcloud.py) | |
| 09:01:24 | gtema | I only did a "rebase" | |
| 09:01:50 | gtema | I would like to ask you to try to integrate it soon, as rebasing in it is a terrible mess with each new change | |
| 09:16:02 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Remove and rearrange object bonged proxy tests https://review.openstack.org/648352 | |
| 09:16:39 | mordred | gtema: +2 from e | |
| 09:16:58 | gtema | thks mordred | |
| 09:18:36 | gtema | btw, I would like to modify service_descriptions.__set__ and __delete__ to be able to be able to override default descriptors (you know OTC case with the DNS implementation) | |
| 09:18:55 | gtema | are you ok with that? | |
| 09:20:41 | mordred | gtema: I *think* that should be ok - although my brain isn't super functional today, so I might be missing an implication :) | |
| 09:22:08 | gtema | ok, will prepare patch. My problem is that in a particular cloud a service might differ from upstream. We currently do have possibility to add service implementation in runtime, but not to "replace" the ones delivered in SDK | |
| 09:22:21 | mordred | yah | |
| 09:22:32 | gtema | so for me DNS implementation should be replaced | |
| 09:22:38 | mordred | of course, insert obligatory grumbling about clouds having incompatible services ... | |
| 09:22:50 | gtema | yupp | |
| 09:23:00 | gtema | thks | |
| 10:03:08 | dtantsur | gtema: sure thing! btw, how did you visa application go? | |
| 10:05:08 | dtantsur | and unrelated, but we need to fix the masakari job: http://logs.openstack.org/18/642218/9/check/openstacksdk-functional-devstack-masakari/bd6a050/job-output.txt.gz#_2019-03-26_16_03_12_675170 | |
| 11:49:08 | openstackgerrit | Merged openstack/openstacksdk master: Split OpenStackCloud into reasonable pieces https://review.openstack.org/642218 | |
| 11:49:09 | openstackgerrit | Merged openstack/openstacksdk master: Do not disregard tags when updating stacks https://review.openstack.org/643195 | |
| 11:57:38 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: Make PATCH a first class operation and support it for baremetal https://review.openstack.org/647730 | |
| 11:59:26 | gtema | dtantsur: thanks. Visa is there. And I was really surprised to get it on 3 days after interview | |
| 12:00:45 | gtema | s/on/in/ | |
| 12:06:56 | dtantsur | yeah, it's nice :) | |
| 13:26:18 | ITD27M01 | mordred: My name is Igor, can you please do a review on https://review.openstack.org/#/c/648117/ (missing "params" for mistral workflow execution) we are developing some utilities on-site for mistral and blocked on this change. Thank you! | |
| 13:47:48 | dtantsur | mordred, gtema, when you have a second, I had to rebase: https://review.openstack.org/#/c/647730/ | |
| 13:54:42 | gtema | yupp - done | |
| 14:02:34 | dtantsur | thx | |
| 14:39:23 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/openstacksdk master: Add "name" filter in "list" call when retrieving a single register https://review.openstack.org/637238 | |
| 15:16:04 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Cleanup split of openstackcloud https://review.openstack.org/648435 | |
| 15:21:35 | ricolin | cdent, edleafe elmiko Hi any chance we can get your help on http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004246.html ?:) | |
| 15:22:12 | cdent | ricolin: I'll punt to edleafe and elmiko on that. I'm not as involved in the api-sig as I used to be | |
| 15:22:27 | edleafe | ricolin: I was going to bring that up at the office hour that starts in about 40 minutes | |
| 15:22:41 | ricolin | cdent, thanks for the help:) | |
| 15:23:10 | ricolin | edleafe, nice! where will the office hour hold, here? | |
| 15:23:14 | elmiko | ricolin: taking a look, but i agree with edleafe | |
| 15:23:27 | edleafe | ricolin: yup | |
| 15:23:37 | cdent | dr, I concur | |
| 15:23:48 | ricolin | will try to join you guys if I can:) | |
| 15:23:54 | elmiko | ah yes, i remember this email. i was kinda curious about our response | |
| 15:49:08 | mnaser | mordred: how do we go about updating patches to Ansible modules for code that recently landed in openstacksdk ? | |
| 15:49:26 | mnaser | i.e. brtknr has landed https://github.com/ansible/ansible/pull/53757 but it depends on a patch in openstacksdk | |
| 15:49:53 | mnaser | given we haven't released one (yet) afaik that includes it, do we hold off, do we push anyways and release openstacksdk when people yell? I'm a bit stuck on that | |
| 15:56:58 | mordred | mnaser: well, we've also got a request from dtruong for an sdk release containing the taskmanager patch - so I think in this case the next step is "cut an sdk release" - at which point the ansible features needing that release can check for the version and whatnot | |
| 15:57:33 | mordred | mnaser: in general we're generally pretty responsive to just cutting new sdk releases when needed - we happen to be in the middle of release freeze this week so it's slightly more complicated | |
| 15:59:33 | mordred | mnaser: I mean - I have no problem landing the ansible patch before we release sdk as long as it's protected by an "if version" - so we might want to ask brtknr to add in a check for sdk version and only add tags to the kwargs there if sdk isn't going to vomit - and maybe throw a warning if sdk is too old and tag is in params | |
| 16:00:12 | edleafe | The API-SIG Office Hour is now underway! Have your tickets ready! | |
| 16:00:22 | elmiko | \o/ | |
| 16:01:29 | edleafe | dtantsur: around? | |
| 16:02:18 | edleafe | Well, let's get started | |
| 16:02:44 | edleafe | ricolin: has brought up the email sent to the WGs/SIGs | |
| 16:02:47 | edleafe | #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004246.html | |
| 16:03:11 | edleafe | I would be happy to respond to point #1 with the requested info | |
| 16:03:43 | elmiko | i think #1 is the most important for us | |
| 16:04:03 | elmiko | we have been pretty stable for awhile and i don't think there is a ton of "we need help on this!" type work out there | |
| 16:04:06 | edleafe | As for #2 (the "Help Most Needed"), do we need to add anything to that? | |
| 16:04:16 | edleafe | jinx-ish | |
| 16:04:18 | elmiko | hehe =) | |
| 16:04:38 | elmiko | maybe we could re-state our position about guidelines growing out of needs in the community where gaps are found? | |
| 16:04:54 | elmiko | a call to action for anyone who might have a need | |
| 16:04:54 | ricolin | edleafe, #2 it's still something we encourage people to put in since that doc itself just recently created | |
| 16:05:33 | edleafe | ricolin: as elmiko mentioned, we don't have a lot of activity that we undertake | |
| 16:06:06 | edleafe | We are here these days mostly for clarification of existing guidelines, filling in missing things, and adjudicating API disputes | |
| 16:06:38 | edleafe | We've tried to act as a guiding force for SDKs, but none have really stepped up to work with us | |
| 16:07:03 | ricolin | The help most needed also can point to some features/help that you think it's really really important but just can't get projects to join | |
| 16:07:39 | elmiko | imo, the help most needed might just be a call for more folks to consider what the sig has done and reach out to us if questions arise | |
| 16:07:42 | edleafe | ricolin: sure, but as elmiko said, we are more of a responsive group to the community | |
| 16:08:19 | elmiko | i'm fine with pushing more a message as the "what do we need help with" as opposed to asking for direct help on something that doesn't quite exist | |
| 16:08:25 | edleafe | If the community isn't clamoring for API guidance, well, we aren't going to just do things to keep busy | |
| 16:08:32 | elmiko | ++ | |
| 16:08:53 | edleafe | elmiko: sounds like you're volunteering to add something for #2 | |
| 16:09:04 | elmiko | i'll give it my best =) | |
| 16:09:38 | elmiko | assuming ricolin is ok with the approach i am talking about | |
| 16:09:59 | edleafe | As far as #3 is concerned, I don't really see our work as being suitable for a community goal. Thoughts? | |
| 16:10:04 | ricolin | edleafe, I don't think to list out needed most means you have to put yourself in that action. It might be some statement/goal for other teams to know that the community should reach | |
| 16:10:53 | elmiko | community goal is definitely for folks to know about the guidelines, and how to reach out for help when needed | |
| 16:11:06 | elmiko | so, i could see 2 and 3 intermingling a little | |
| 16:11:14 | ricolin | elmiko, yes, I'm totally okay:) this should be whatever SIG itself needs or a suggestion goal from SIG to community | |
| 16:11:29 | elmiko | ok, cool | |
| 16:11:51 | edleafe | I see community goals as something that the TC is leading because OpenStack needs to do it. Moving to Python3 is a great example. But we've clearly stated that we do not expect teams to change their existing APIs to match the guidelines; in fact, we would consider that a very bad thing | |
| 16:12:31 | elmiko | ++, awareness and spreading knowledge have always been our pillars, we don't advocate for action in the project teams | |
| 16:12:49 | elmiko | (unless asked) | |
| 16:14:18 | elmiko | well, i guess, edleafe should you and i take some actions to get these filled out by next week? | |
| 16:14:25 | mordred | edleafe, elmiko: with the exception of when there is something _Additional_ we'd like for everyone to add to their api that can be done in a backwards compatible manner | |
| 16:14:49 | elmiko | that's a good call out mordred | |
| 16:15:00 | mordred | (that being a time when a community goal *could* emmanate from api-sig work - but I generally agree, it's not the primary or normal output | |
| 16:15:06 | edleafe | preach, brother mordred! | |
| 16:15:48 | gtema | ++ | |
| 16:16:07 | elmiko | hahaha | |
| 16:24:04 | elmiko | ricolin: looking at https://etherpad.openstack.org/p/community-goals i am really not feeling that our group's activity merit an entry there | |