Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-03-28
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
16:24:26 openstackgerrit Merged openstack/openstacksdk master: Add image.service_info resources https://review.openstack.org/638227
16:25:01 elmiko i feel like our community goal is "make sure everyone knows where the api guidelines are at and how to get help" does not seem to fit the same level of completion that the others have
16:25:41 ricolin elmiko, That's fine if we don't think any of API SIG goal match community goal (request #3)
16:26:55 elmiko ricolin: i will read through the "help most needed" list to see if we have an addition to propose
16:27:45 elmiko edleafe: you are going to reply with the info from item 1 ?

Earlier   Later