| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-25 | |||
| 16:10:43 | kmalloc | and that reminds me, i need to re-prioritize my work to do that middleware extraction bit first | |
| 16:10:56 | kmalloc | i was about to dive into SDK / make keystoneclient dead work. | |
| 16:11:56 | elmiko | wow, seems like there is actually some topics today or just folks looking to get more guidance at a future date? | |
| 16:12:29 | cdent | bitrot++ | |
| 16:12:51 | Miouge | Can the SDK identity which OpenStack release a given region is running (Pike/Queens/…)? Or is that a “Ask your administrator” type situation? | |
| 16:13:20 | dtantsur | Miouge: the latter. to a great extent because some people mix-and-match versions of different components. | |
| 16:13:39 | edleafe | elmiko: Yeah, peschk_l had a question, but we pushed it until 1800 UTC | |
| 16:13:55 | elmiko | edleafe: cool | |
| 16:14:04 | dtantsur | for the record: ironic-inspector uses flask and microversins (well, some flavor of them) | |
| 16:14:13 | kmalloc | Miouge: keystoneauth (and likewise things consuming it) can provide discovery information to you [max/min api versions in the case of microversions, etc], but you'd need to know what the differing APIs and Versions really mean, realistically, you're asking the administrator | |
| 16:14:17 | edleafe | dtantsur: Microversions cure all your ills! | |
| 16:14:22 | dtantsur | and now I'm writing a proxy for BM API that will use flask and microversions | |
| 16:14:30 | dtantsur | oh yeah, but how many do they add... | |
| 16:14:45 | kmalloc | in general though, it is much easier to just ask "what version" | |
| 16:14:48 | dtantsur | so, I'm writing a proxy. instead of implementing one baremetal API, I need to implement 48 of them | |
| 16:14:52 | dtantsur | what a time to be alive | |
| 16:15:03 | elmiko | yeesh | |
| 16:15:11 | kmalloc | dtantsur: thankfully flask makes things super easy on that front to do fun things... | |
| 16:15:21 | elmiko | ++ | |
| 16:15:23 | kmalloc | s/fun/fun for some measure of fun/ | |
| 16:15:38 | kmalloc | personally i love the before-request/after-request functions. | |
| 16:15:41 | kmalloc | elmiko: ^ | |
| 16:15:46 | kmalloc | vs. full bore middleware | |
| 16:16:04 | kmalloc | also... with app.test_client() <--- best test client thing ever :) | |
| 16:16:16 | elmiko | i just like how dead simple it is to get a basic http server running | |
| 16:16:19 | dtantsur | kmalloc: that's a good point, these hooks may help with micorversioning stuff | |
| 16:16:27 | kmalloc | dtantsur: absolutely. | |
| 16:16:55 | elmiko | i've found the middleware pipeline to be really easy to extend as well | |
| 16:16:57 | kmalloc | way way simpler and you don't need to wrap app.wsgi_app (whatever you do do NOT wrap app directly with middleware) | |
| 16:16:58 | dtantsur | yeah, I got https://github.com/dtantsur/ironic-proxy/blob/master/ironic_proxy/api.py running in a few hours, half of them was fighting with oslo.config and keystoneauth :D | |
| 16:17:27 | dtantsur | kmalloc: mmm, why not? I'm quite sure we do it in a few places.. | |
| 16:17:30 | kmalloc | dtantsur: i found out the hard way to wrap app.wsgi_app when i tried to do test_client | |
| 16:17:37 | kmalloc | basically wsgi_app is the *actual* application | |
| 16:17:37 | dtantsur | ah, with tests? | |
| 16:17:42 | kmalloc | yeah | |
| 16:17:57 | kmalloc | so if you wrap app.wsgi_app instead it exposes all the nice flask things on app stil | |
| 16:17:58 | kmalloc | l | |
| 16:18:05 | kmalloc | etc | |
| 16:18:05 | kmalloc | like test_client() and test_RequesT_context() | |
| 16:18:12 | dtantsur | ah, got it. makes sense indeed :) | |
| 16:18:36 | kmalloc | i highly recommend flask-restful | |
| 16:18:44 | kmalloc | over straight flask if you're doing REST APIs | |
| 16:19:07 | dtantsur | I feel like our API are unrestful enough to not use flask-restful | |
| 16:19:16 | dtantsur | don't remember for sure, but something made me not go that way | |
| 16:19:29 | kmalloc | well, what i like about flask restful is it builds resource objects you then just implement http methods on | |
| 16:19:33 | kmalloc | get/put/etc | |
| 16:19:34 | Miouge | dtantsur and kmalloc thanks! I saw the “openstack versions show” but i’m not able to draw conclusions from that output | |
| 16:19:50 | cdent | objectdispatch-- | |
| 16:19:55 | kmalloc | Miouge: yeah, it's a lot of apriori knowledge or "go search the interwebs" | |
| 16:19:59 | dtantsur | kmalloc: ah, this is exactly what I don't like :) I guess tastes differt | |
| 16:20:01 | kmalloc | Miouge: i usually just ask. | |
| 16:20:25 | kmalloc | dtantsur: ah, with the complexity of keystone's (sigh... double sigh) API, it made life a lot easier | |
| 16:20:35 | dtantsur | I can imagine | |
| 16:20:40 | kmalloc | though it has some weird edge cases, like the resource object isn't instantiated until the request is processed... | |
| 16:20:46 | dtantsur | Ironic API is not THAT restful, unfortunately | |
| 16:21:19 | kmalloc | the other benefit is flask-restful has nice hooks for swagger and/or openapi doc | |
| 16:21:38 | kmalloc | but i can see ironic's apis being happier with straight flask | |
| 16:21:57 | kmalloc | cdent: i'll have to poke at gabbi then :P | |
| 16:21:59 | kmalloc | cdent: hehe | |
| 16:31:48 | Miouge | kmalloc: in my situation asking is not really an option, maybe I can infer stuff based on the nova doc then? https://docs.openstack.org/nova/latest/reference/api-microversion-history.html | |
| 16:43:51 | kmalloc | that is the idea | |
| 16:43:56 | kmalloc | you should be able to infer things | |
| 16:44:06 | kmalloc | it's just much easier if you know what to expect :) | |
| 16:50:56 | kmalloc | cdent: ah, gabbi is cool, i think i can couple it with the test_client context manager for great success | |
| 16:51:12 | cdent | huzzah! | |
| 16:51:36 | kmalloc | cdent: the test_client context manager in flask is super useful becasue it holds the context around so i can inspect lots of flask data and ensure everything is right, but the programatic stuff of gabbi will mkae some of the steps super easy | |
| 16:52:00 | kmalloc | so super good stuff, thnx! | |
| 16:53:07 | cdent | kmalloc: a thing you might want to keep in mind with gabbi is that it is oriented so that you're only thinking about the http api, not about the internals of the implementation. It doesn't want you to care about "lots of flask data", just whether the api is doing the right thing | |
| 16:53:32 | kmalloc | right, for cases we do those things it's going to be perfect | |
| 16:53:33 | cdent | so in that sense, I probably should have hassled you about gabbi and keystone before you did the switch the flask, so you could test both sides of the change with the same gabbit tests | |
| 16:53:45 | kmalloc | a lot of our tests are "do X and check response" | |
| 16:54:05 | kmalloc | nah, we didn't change any of our tests (ok not many) when moving to flask | |
| 16:54:41 | kmalloc | that was part of the requirements, so moving to gabbi is totally doable and wont be undoing/redoing much of any work I already did | |
| 16:54:52 | cdent | cool | |
| 16:55:13 | kmalloc | in fact we have an outreachy project specifically to work on our test suite. | |
| 16:57:36 | elmiko | don't know if i'll be around at 1800UTC, but if not i'll catch you next week edleafe o/ | |
| 16:57:43 | edleafe | \o | |
| 16:58:31 | elmiko | take care cdent o/ | |
| 16:58:41 | cdent | elmiko: have you been fired? | |
| 16:58:50 | elmiko | not that i know of | |
| 16:58:59 | cdent | "cleaning desk" | |
| 16:59:09 | elmiko | oh, lol, bad "office hours" joke | |
| 16:59:56 | elmiko | i imagine myself coming in to some univeristy office that we all share to hold office hours, just trying to leave the camp site better than i found it ;) | |
| 18:12:53 | peschk_l | kmalloc, edleafe: I'm back | |
| 18:13:10 | edleafe | I'm here | |
| 18:13:24 | kmalloc | peschk_l: o/ | |
| 18:14:16 | peschk_l | about my questions: Basically, cloudkitty has changed the way it processes and manages data internally. We also created a new storgae backend. Which means we need to refactor the current API | |
| 18:15:39 | peschk_l | currently, we use pecan + wsme, which I personally don't like at all, given that it's hard to understand at first... which doesn't help us to gain some new contributors | |
| 18:15:52 | edleafe | peschk_l: why would an internal change require changing the API? | |
| 18:16:46 | kmalloc | ^ | |
| 18:16:49 | kmalloc | good question | |
| 18:17:09 | peschk_l | edleafe: because there are a lot of things which our new storage interface supports, for example (re-)grouping | |
| 18:17:14 | kmalloc | unless the API leaks implementation details, which then I do encourage fixing that :) | |
| 18:17:46 | kmalloc | so how can i help you? :) i'm happy to answer questions re: flask or other things. | |
| 18:17:55 | edleafe | ah, so you're adding new functionality? | |
| 18:18:07 | peschk_l | edleafe: exactly | |
| 18:18:20 | peschk_l | we would at least need to implement a new API endpoint | |
| 18:18:56 | edleafe | Are you using microversions now? | |
| 18:19:02 | peschk_l | no | |
| 18:20:01 | peschk_l | given that we are a tiny project, the plan was more or less the following: have v1 and v2 APIs served at the same time. Given that we won't be able to move all v1 resources to v2 in a single release, we would like to do that resource after resource | |