| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-10-25 | |||
| 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 | |
| 18:20:18 | peschk_l | releasing a microversion for each migrated resource | |
| 18:21:05 | peschk_l | the thing is that we don't really know if microversions are used/supported in openstack right now | |
| 18:21:14 | kmalloc | some projects use microversions | |
| 18:21:26 | edleafe | So users of the API could continue to request things they currently do, and will get back a response that has the same format as now? | |
| 18:21:27 | kmalloc | cdent has extracted things into a nice middleware for processing the request itself | |
| 18:22:10 | peschk_l | kmalloc: yeah, I had a look at cdent's link, it look like like it could ease our work :) | |
| 18:22:14 | edleafe | Microversions are used by nova, placement, ironic, and maybe more | |
| 18:22:30 | kmalloc | microversions are explicitly NOT used by keystone (for example) | |
| 18:22:44 | edleafe | So yeah, microversions are supported :) | |
| 18:22:51 | kmalloc | so yeah depends on the project | |
| 18:23:12 | kmalloc | there is no reason you should feel like microversions are a tool you should avoid unless you want to avoid them | |
| 18:23:29 | peschk_l | edleafe: they could. At least for a while. idea would be to say: resource AAA has been made available in v2 since release 2.xx of the API. Support for the v1 endpoint of this resource will be dropped with API version 2.yy | |
| 18:23:38 | kmalloc | if it makes things easier for you and your users, they can be good. | |
| 18:23:42 | peschk_l | until we have no more resources in v1 | |
| 18:23:49 | peschk_l | kmalloc: glad to hear that | |
| 18:24:07 | edleafe | Ah. Well, there are many who say that dropping API support is a Very, Very Bad Thing | |
| 18:24:07 | kmalloc | so with microversions you wouldn't be eliminating v1, people could fall back to using it | |
| 18:24:40 | kmalloc | you can drop support in v2, but you'll want to maintain v1 with the limited (default) capabilities where the API can't inform data to the backend | |
| 18:24:48 | kmalloc | s/default/sane defaults | |
| 18:24:52 | peschk_l | well the goal would beb to eliminate v1 after some time | |
| 18:24:59 | peschk_l | *be | |
| 18:25:03 | edleafe | microversions only apply within a major release | |
| 18:25:16 | edleafe | Going from v1 to v2 is anything but micro | |
| 18:25:22 | kmalloc | removing APIs is bad in general | |
| 18:25:55 | kmalloc | as someone who championed removal of an api in a major project, i highly recommend not doing that. it surprises users in bad ways | |
| 18:26:01 | edleafe | peschk_l: https://blog.leafe.com/api-longevity/ | |
| 18:26:06 | kmalloc | edleafe: ++ | |
| 18:26:50 | kmalloc | as much as keystone team (and me personally) would love to drop some things to the side from our API, we wont remove apis from default deployment/functionality in the foreseeable future | |
| 18:27:10 | edleafe | Unless v1 is highly unstable or causes some other extreme issue, you really should keep it around | |
| 18:27:16 | kmalloc | ++ | |
| 18:27:40 | peschk_l | edleafe: we'd like to refactor the whole API... But we won't be able to accomplish that in a single release. So the idea would be to implement new endpoints within v2 only, and to slowly migrate "legacy" endpoints from v1 to v2 | |
| 18:27:49 | peschk_l | (thanks for the link btw) | |
| 18:28:45 | kmalloc | i also highly recommend, whatever you do, not version your endpoints in the catalog | |
| 18:28:59 | kmalloc | support v1/v2 (as you transition) on the same server/wsgi application | |
| 18:29:07 | kmalloc | versioned endpoints are a bad idea. | |
| 18:29:08 | peschk_l | Honestly, v1 has some major issues, for example (and I'm ashamed), there is no way to paginate results, except with begin/end timestamps | |
| 18:29:22 | edleafe | peschk_l: A general approach for creating the new API is along these lines: | |
| 18:29:39 | edleafe | 1) create a new endpoint, labeled 'EXPERIMENTAL' | |
| 18:29:53 | edleafe | 2) start adding more and more features to that endpoint | |
| 18:29:54 | peschk_l | kmalloc: we weren't planning to manage the endpoints. versions would only have been "markers" for which endpoints are supported, and which are not | |
| 18:30:41 | edleafe | 3) When you finally have a good, working version, change that version to 'CURRENT' and change the old version to 'SUPPORTED' | |
| 18:31:06 | edleafe | This way users can opt into the new API if they wish at their own pace, knowing that it is subject to change | |
| 18:31:10 | kmalloc | ++ | |
| 18:31:28 | kmalloc | ^ that is what i was in the middle of typing before edleafe beat me to it | |
| 18:31:40 | edleafe | You don't flip the switch until the new API is solid, and your can't see any more work needed on it | |
| 18:31:54 | kmalloc | and at that point you can support microversions on v2 | |
| 18:32:05 | kmalloc | and v1 is legacy, maintained for compat with old clients/users | |
| 18:32:35 | kmalloc | you give all the shiny new things to v2/v2+microversions so folks are encouraged to use v2 | |
| 18:32:36 | peschk_l | I see. Would you still add endpoint for new features on v2 only, and mark them as experimental ? | |
| 18:32:53 | peschk_l | kmalloc: ok, got my answer :) | |
| 18:32:55 | kmalloc | i would support in your service /v1 <current> | |
| 18:32:59 | kmalloc | and /v2 <new> | |
| 18:33:05 | kmalloc | and have / be a discovery doc | |