| *** bobh has joined #openstack-sdks | 02:13 | |
| *** bobh has quit IRC | 03:32 | |
| *** lbragstad has quit IRC | 04:00 | |
| *** Luzi has joined #openstack-sdks | 06:00 | |
| *** tobiash_ has quit IRC | 06:03 | |
| *** tobiash has joined #openstack-sdks | 06:04 | |
| *** gildub has quit IRC | 06:22 | |
| *** maxbab has joined #openstack-sdks | 06:25 | |
| *** slaweq has joined #openstack-sdks | 06:35 | |
| *** gildub has joined #openstack-sdks | 06:38 | |
| *** jpena|off is now known as jpena | 07:15 | |
| *** madorn has quit IRC | 07:34 | |
| *** nmimi has joined #openstack-sdks | 07:43 | |
| *** jpich has joined #openstack-sdks | 08:00 | |
| *** ttsiouts has joined #openstack-sdks | 08:26 | |
| *** sc68cal has quit IRC | 08:26 | |
| *** sc68cal has joined #openstack-sdks | 08:27 | |
| *** e0ne has joined #openstack-sdks | 08:42 | |
| *** gildub has quit IRC | 08:55 | |
| *** gildub has joined #openstack-sdks | 08:58 | |
| *** ttsiouts has quit IRC | 09:02 | |
| *** ttsiouts has joined #openstack-sdks | 09:02 | |
| *** gildub has quit IRC | 09:07 | |
| *** dtantsur|afk is now known as dtantsur | 09:09 | |
| dtantsur | morning folks | 09:09 |
|---|---|---|
| *** tosky has joined #openstack-sdks | 09:16 | |
| *** ttsiouts has quit IRC | 09:21 | |
| *** ttsiouts has joined #openstack-sdks | 09:22 | |
| nmimi | Hi all!My name is Nikos | 09:46 |
| nmimi | I have a task in sfc project, in which i have to replace SNAPS library with SDK and i am facing some difficulties... | 09:46 |
| nmimi | I have a list of SDK objects and in the end of the test case, inside a for loop, i delete them(object.delete(conn.session) | 09:46 |
| nmimi | I have successfully deleted floating ips, instances, images, flavors, but when i try to delete router i get the following error: | 09:46 |
| nmimi | HttpException: HttpException: Unknown error | 09:47 |
| nmimi | i have tried also : | 09:47 |
| nmimi | obj.remove_gateway(conn.session) & obj.remove_interface(conn.session) but i get the following error message: | 09:47 |
| nmimi | EndpointNotFound: Could not find requested endpoint in Service Catalog. | 09:47 |
| nmimi | After that errors, i have executed: | 09:47 |
| nmimi | self.conn.network.remove_interface_from_router(creator.id, subnet_obj.id) | 09:47 |
| nmimi | self.conn.network.delete_router(obj) | 09:48 |
| nmimi | and the router has been deleted successfully. | 09:48 |
| nmimi | Could please someone tell me what i am doing wrong and i get these error messages? | 09:48 |
| dtantsur | nmimi: hi! maybe the problem is that the router is still connected to a subnet? I seem to recall you cannot delete connected routers | 09:54 |
| dtantsur | "Unknwon error" is not good, of course | 09:54 |
| nmimi | yes the first time i try to delete the router with command router.delete(conn.session) the subnet is still connected | 09:56 |
| nmimi | but i ahave tried also: | 09:57 |
| nmimi | router.delete(conn.session) | 09:57 |
| nmimi | sorry wrong command | 09:57 |
| nmimi | router.remove_interface(conn.session) | 09:58 |
| nmimi | and router.remove_gateway(conn.session) | 09:58 |
| nmimi | but i get the error messages | 09:58 |
| dtantsur | about the endpoint not found? | 10:02 |
| nmimi | yes exactly | 10:02 |
| dtantsur | mmmm | 10:03 |
| dtantsur | slaweq: I wonder if you have an idea ^^^ | 10:03 |
| *** gildub has joined #openstack-sdks | 10:03 | |
| slaweq | dtantsur: checking | 10:04 |
| slaweq | dtantsur: I don't know why it's like that, maybe nmimi should open bug for that? | 10:06 |
| nmimi | ok i will investigate it a bit more and if the error persists i will open a bug | 10:08 |
| *** cdent has joined #openstack-sdks | 10:10 | |
| *** ttsiouts has quit IRC | 10:11 | |
| *** ttsiouts has joined #openstack-sdks | 11:04 | |
| *** jpena is now known as jpena|lunch | 11:34 | |
| *** jpena|lunch is now known as jpena | 12:33 | |
| *** ttsiouts has quit IRC | 12:47 | |
| *** ttsiouts has joined #openstack-sdks | 12:48 | |
| *** bobh has joined #openstack-sdks | 13:02 | |
| *** d0ugal has quit IRC | 13:33 | |
| *** lbragstad has joined #openstack-sdks | 13:33 | |
| *** d0ugal has joined #openstack-sdks | 13:34 | |
| *** tobberydberg has joined #openstack-sdks | 13:43 | |
| *** d0ugal has quit IRC | 13:49 | |
| *** d0ugal has joined #openstack-sdks | 13:51 | |
| *** Luzi has quit IRC | 13:57 | |
| *** ttsiouts has quit IRC | 14:24 | |
| *** ttsiouts has joined #openstack-sdks | 14:26 | |
| *** maxbab has quit IRC | 14:38 | |
| -openstackstatus- NOTICE: Zuul and Nodepool services are being restarted to migrate them to a new Zookeeper cluster. THis brings us an HA database running on newer servers. | 14:40 | |
| *** bobh has quit IRC | 14:55 | |
| *** tobberydberg has quit IRC | 14:56 | |
| *** Luzi has joined #openstack-sdks | 15:01 | |
| *** openstackgerrit has joined #openstack-sdks | 15:04 | |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Add disk and container format to image task test https://review.openstack.org/613349 | 15:04 |
| *** jpena is now known as jpena|brb | 15:04 | |
| *** tobberydberg has joined #openstack-sdks | 15:05 | |
| mordred | dtantsur, nmimi: the session argument to Resource objects is misleading. try router.remove_interface(conn.network) | 15:06 |
| mordred | we really should rename that parameter, but MAN that'll be a big patch | 15:09 |
| *** tobberydberg has quit IRC | 15:13 | |
| *** jpena|brb is now known as jpena | 15:15 | |
| dtantsur | oh yeah | 15:21 |
| *** tobberydberg has joined #openstack-sdks | 15:25 | |
| *** Luzi has quit IRC | 15:26 | |
| *** bobh has joined #openstack-sdks | 15:29 | |
| mordred | dtantsur: are we having bifrost job issues again? I thought we'd fixed that | 15:31 |
| -openstackstatus- NOTICE: The Zuul and Nodepool database transition is complete. Changes updated during the Zuul outage may need to be rechecked. | 15:32 | |
| openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Don't pass disk_format or container_format to image task upload https://review.openstack.org/613141 | 15:33 |
| dtantsur | mordred: did keystoneauth with the fix hit upper-constraints? | 15:33 |
| mordred | oh. upper-constraints. hrm. not sure ... | 15:34 |
| dtantsur | do we have any docs on how to use keystoneauth1.loading.adapter.load_from_conf_options? | 15:34 |
| dtantsur | whatever I do, it fails with __init__() missing 1 required positional argument: 'session' | 15:34 |
| *** bobh has quit IRC | 15:35 | |
| mordred | dtantsur: they use it in nova | 15:35 |
| dtantsur | we use it in ironic too, but that's part of tribal knowledge I don't posess.. | 15:35 |
| mordred | oh maybe they don't | 15:35 |
| mordred | yeah they do - nova/utils.py | 15:36 |
| mordred | dtantsur: fwiw, I want to make an sdk equiv | 15:36 |
| mordred | but with less tribal knowledge required - basicaly a "from_conf_options" that will get you a connection with all of the services having been configured from any config values in your CONF object | 15:37 |
| dtantsur | that would be awesome | 15:37 |
| mordred | I started work on it a couple of days ago - will try oto get an initial thing up tmorrow | 15:38 |
| *** bobh has joined #openstack-sdks | 15:39 | |
| *** e0ne has quit IRC | 15:59 | |
| edleafe | API-SIG Office Hour has officially begun | 16:00 |
| edleafe | peschk_l: around? | 16:00 |
| peschk_l | edleafe yes, but unfortunately I don't have an access to my laptop right now, so I may need some time to type | 16:02 |
| edleafe | No worries | 16:02 |
| edleafe | Will you have time later? I'll be around | 16:02 |
| peschk_l | edleafe: would 18H UTC be ok for you ? | 16:03 |
| * cdent has a question about microversions | 16:03 | |
| edleafe | peschk_l: That would be fine | 16:04 |
| * edleafe shushes cdent | 16:04 | |
| * cdent also wonders if elmiko returned from the uk | 16:04 | |
| peschk_l | edleafe: perfect :) My questions would mainly be about flask and microversions | 16:05 |
| mordred | kmalloc might be helpful too | 16:05 |
| mordred | he's been working on the flak transition in keystone | 16:05 |
| kmalloc | ohai | 16:05 |
| kmalloc | what can i do for folks? | 16:05 |
| edleafe | kmalloc: peschk_l has some questions, but isn't at a laptop for another two hours. Will you be around then? | 16:07 |
| kmalloc | edleafe: sure! | 16:07 |
| kmalloc | i'll be around for a couple hours. In ~3hrs i need to duck out for a couple hours (Doctor appt) | 16:07 |
| cdent | peschk_l: you might find https://pypi.org/project/microversion_parse/ interesting/useful | 16:07 |
| kmalloc | but will be back when done | 16:07 |
| kmalloc | peschk_l: o/ I'll look for a ping from you a little later today | 16:08 |
| kmalloc | cdent: i.. i ... wow that's a thing? neato | 16:09 |
| peschk_l | kmalloc, edleafe Nice, see you later then | 16:09 |
| cdent | kmalloc: dag nabbit, I only sent tons of mail about it once upon a time :) | 16:09 |
| kmalloc | cdent: well.... i personally greatly dislike microversions | 16:09 |
| kmalloc | so i probably blocked those emails from my brain | 16:09 |
| kmalloc | doesn't change that it's nice to see that packaged up | 16:09 |
| kmalloc | and easily consumable | 16:10 |
| elmiko | hi | 16:10 |
| elmiko | cdent: yes, i did make it back in one piece =) | 16:10 |
| cdent | yeah, that's basically why I did it: this is painful and annoying and a burden so let's make it not | 16:10 |
| kmalloc | ++ | 16:10 |
| cdent | elmiko: excellent | 16:10 |
| kmalloc | and that reminds me, i need to re-prioritize my work to do that middleware extraction bit first | 16:10 |
| kmalloc | i was about to dive into SDK / make keystoneclient dead work. | 16:10 |
| * kmalloc hopes to get to say keystoneclient is officially bit-rottable by the end of stein. | 16:11 | |
| elmiko | wow, seems like there is actually some topics today or just folks looking to get more guidance at a future date? | 16:11 |
| cdent | bitrot++ | 16:12 |
| 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:12 |
| dtantsur | Miouge: the latter. to a great extent because some people mix-and-match versions of different components. | 16:13 |
| edleafe | elmiko: Yeah, peschk_l had a question, but we pushed it until 1800 UTC | 16:13 |
| * dtantsur sighs at microversions | 16:13 | |
| elmiko | edleafe: cool | 16:13 |
| dtantsur | for the record: ironic-inspector uses flask and microversins (well, some flavor of them) | 16:14 |
| 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 |
| edleafe | dtantsur: Microversions cure all your ills! | 16:14 |
| dtantsur | and now I'm writing a proxy for BM API that will use flask and microversions | 16:14 |
| dtantsur | oh yeah, but how many do they add... | 16:14 |
| kmalloc | in general though, it is much easier to just ask "what version" | 16:14 |
| dtantsur | so, I'm writing a proxy. instead of implementing one baremetal API, I need to implement 48 of them | 16:14 |
| dtantsur | what a time to be alive | 16:14 |
| elmiko | yeesh | 16:15 |
| kmalloc | dtantsur: thankfully flask makes things super easy on that front to do fun things... | 16:15 |
| elmiko | ++ | 16:15 |
| kmalloc | s/fun/fun for some measure of fun/ | 16:15 |
| kmalloc | personally i love the before-request/after-request functions. | 16:15 |
| kmalloc | elmiko: ^ | 16:15 |
| kmalloc | vs. full bore middleware | 16:15 |
| kmalloc | also... with app.test_client() <--- best test client thing ever :) | 16:16 |
| elmiko | i just like how dead simple it is to get a basic http server running | 16:16 |
| dtantsur | kmalloc: that's a good point, these hooks may help with micorversioning stuff | 16:16 |
| kmalloc | dtantsur: absolutely. | 16:16 |
| elmiko | i've found the middleware pipeline to be really easy to extend as well | 16:16 |
| 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 |
| 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:16 |
| dtantsur | kmalloc: mmm, why not? I'm quite sure we do it in a few places.. | 16:17 |
| kmalloc | dtantsur: i found out the hard way to wrap app.wsgi_app when i tried to do test_client | 16:17 |
| dtantsur | ah, with tests? | 16:17 |
| kmalloc | basically wsgi_app is the *actual* application | 16:17 |
| kmalloc | yeah | 16:17 |
| kmalloc | so if you wrap app.wsgi_app instead it exposes all the nice flask things on app stil | 16:17 |
| kmalloc | l | 16:17 |
| kmalloc | like test_client() and test_RequesT_context() | 16:18 |
| * cdent clearly needs to convert kmalloc to gabbi | 16:18 | |
| kmalloc | etc | 16:18 |
| dtantsur | ah, got it. makes sense indeed :) | 16:18 |
| * kmalloc has also been really deep into the internals of flask to get keystone converted | 16:18 | |
| kmalloc | i highly recommend flask-restful | 16:18 |
| kmalloc | over straight flask if you're doing REST APIs | 16:18 |
| dtantsur | I feel like our API are unrestful enough to not use flask-restful | 16:19 |
| dtantsur | don't remember for sure, but something made me not go that way | 16:19 |
| kmalloc | well, what i like about flask restful is it builds resource objects you then just implement http methods on | 16:19 |
| kmalloc | get/put/etc | 16:19 |
| Miouge | dtantsur and kmalloc thanks! I saw the “openstack versions show” but i’m not able to draw conclusions from that output | 16:19 |
| cdent | objectdispatch-- | 16:19 |
| kmalloc | Miouge: yeah, it's a lot of apriori knowledge or "go search the interwebs" | 16:19 |
| dtantsur | kmalloc: ah, this is exactly what I don't like :) I guess tastes differt | 16:19 |
| kmalloc | Miouge: i usually just ask. | 16:20 |
| kmalloc | dtantsur: ah, with the complexity of keystone's (sigh... double sigh) API, it made life a lot easier | 16:20 |
| dtantsur | I can imagine | 16:20 |
| kmalloc | though it has some weird edge cases, like the resource object isn't instantiated until the request is processed... | 16:20 |
| dtantsur | Ironic API is not THAT restful, unfortunately | 16:20 |
| kmalloc | the other benefit is flask-restful has nice hooks for swagger and/or openapi doc | 16:21 |
| kmalloc | but i can see ironic's apis being happier with straight flask | 16:21 |
| kmalloc | cdent: i'll have to poke at gabbi then :P | 16:21 |
| kmalloc | cdent: hehe | 16:21 |
| * kmalloc runs off to coffee more then do actual code work. | 16:22 | |
| *** dtantsur is now known as dtantsur|afk | 16:22 | |
| *** mnaser has quit IRC | 16:26 | |
| *** mnaser has joined #openstack-sdks | 16:26 | |
| *** jpich has quit IRC | 16:28 | |
| 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:31 |
| *** ttsiouts has quit IRC | 16:36 | |
| *** imacdonn has quit IRC | 16:42 | |
| *** imacdonn has joined #openstack-sdks | 16:43 | |
| kmalloc | that is the idea | 16:43 |
| kmalloc | you should be able to infer things | 16:43 |
| kmalloc | it's just much easier if you know what to expect :) | 16:44 |
| kmalloc | cdent: ah, gabbi is cool, i think i can couple it with the test_client context manager for great success | 16:50 |
| cdent | huzzah! | 16:51 |
| 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:51 |
| kmalloc | so super good stuff, thnx! | 16:52 |
| 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 |
| kmalloc | right, for cases we do those things it's going to be perfect | 16:53 |
| 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 |
| kmalloc | a lot of our tests are "do X and check response" | 16:53 |
| kmalloc | nah, we didn't change any of our tests (ok not many) when moving to flask | 16:54 |
| 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 |
| cdent | cool | 16:54 |
| kmalloc | in fact we have an outreachy project specifically to work on our test suite. | 16:55 |
| * kmalloc goes looking into extracting kestone middleware loader for oslo.middleware | 16:56 | |
| * elmiko starts cleaning up desk | 16:57 | |
| elmiko | don't know if i'll be around at 1800UTC, but if not i'll catch you next week edleafe o/ | 16:57 |
| edleafe | \o | 16:57 |
| elmiko | take care cdent o/ | 16:58 |
| cdent | elmiko: have you been fired? | 16:58 |
| *** jpena is now known as jpena|off | 16:58 | |
| elmiko | not that i know of | 16:58 |
| cdent | "cleaning desk" | 16:58 |
| elmiko | oh, lol, bad "office hours" joke | 16:59 |
| 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 ;) | 16:59 |
| *** cdent has quit IRC | 17:56 | |
| peschk_l | kmalloc, edleafe: I'm back | 18:12 |
| edleafe | I'm here | 18:13 |
| kmalloc | peschk_l: o/ | 18:13 |
| 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:14 |
| 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 |
| edleafe | peschk_l: why would an internal change require changing the API? | 18:15 |
| kmalloc | ^ | 18:16 |
| kmalloc | good question | 18:16 |
| peschk_l | edleafe: because there are a lot of things which our new storage interface supports, for example (re-)grouping | 18:17 |
| kmalloc | unless the API leaks implementation details, which then I do encourage fixing that :) | 18:17 |
| kmalloc | so how can i help you? :) i'm happy to answer questions re: flask or other things. | 18:17 |
| edleafe | ah, so you're adding new functionality? | 18:17 |
| peschk_l | edleafe: exactly | 18:18 |
| peschk_l | we would at least need to implement a new API endpoint | 18:18 |
| edleafe | Are you using microversions now? | 18:18 |
| peschk_l | no | 18:19 |
| 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 |
| peschk_l | releasing a microversion for each migrated resource | 18:20 |
| peschk_l | the thing is that we don't really know if microversions are used/supported in openstack right now | 18:21 |
| kmalloc | some projects use microversions | 18:21 |
| 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 |
| kmalloc | cdent has extracted things into a nice middleware for processing the request itself | 18:21 |
| peschk_l | kmalloc: yeah, I had a look at cdent's link, it look like like it could ease our work :) | 18:22 |
| edleafe | Microversions are used by nova, placement, ironic, and maybe more | 18:22 |
| kmalloc | microversions are explicitly NOT used by keystone (for example) | 18:22 |
| edleafe | So yeah, microversions are supported :) | 18:22 |
| kmalloc | so yeah depends on the project | 18:22 |
| kmalloc | there is no reason you should feel like microversions are a tool you should avoid unless you want to avoid them | 18:23 |
| 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 |
| kmalloc | if it makes things easier for you and your users, they can be good. | 18:23 |
| peschk_l | until we have no more resources in v1 | 18:23 |
| peschk_l | kmalloc: glad to hear that | 18:23 |
| edleafe | Ah. Well, there are many who say that dropping API support is a Very, Very Bad Thing | 18:24 |
| kmalloc | so with microversions you wouldn't be eliminating v1, people could fall back to using it | 18:24 |
| 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 |
| kmalloc | s/default/sane defaults | 18:24 |
| peschk_l | well the goal would beb to eliminate v1 after some time | 18:24 |
| peschk_l | *be | 18:24 |
| edleafe | microversions only apply within a major release | 18:25 |
| * kmalloc puts on the former TC/OpenStack leadership hat | 18:25 | |
| edleafe | Going from v1 to v2 is anything but micro | 18:25 |
| kmalloc | removing APIs is bad in general | 18:25 |
| 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:25 |
| edleafe | peschk_l: https://blog.leafe.com/api-longevity/ | 18:26 |
| kmalloc | edleafe: ++ | 18:26 |
| 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:26 |
| edleafe | Unless v1 is highly unstable or causes some other extreme issue, you really should keep it around | 18:27 |
| kmalloc | ++ | 18:27 |
| 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 |
| peschk_l | (thanks for the link btw) | 18:27 |
| kmalloc | i also highly recommend, whatever you do, not version your endpoints in the catalog | 18:28 |
| kmalloc | support v1/v2 (as you transition) on the same server/wsgi application | 18:28 |
| kmalloc | versioned endpoints are a bad idea. | 18:29 |
| 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 |
| edleafe | peschk_l: A general approach for creating the new API is along these lines: | 18:29 |
| edleafe | 1) create a new endpoint, labeled 'EXPERIMENTAL' | 18:29 |
| edleafe | 2) start adding more and more features to that endpoint | 18:29 |
| 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:29 |
| edleafe | 3) When you finally have a good, working version, change that version to 'CURRENT' and change the old version to 'SUPPORTED' | 18:30 |
| 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 |
| kmalloc | ++ | 18:31 |
| kmalloc | ^ that is what i was in the middle of typing before edleafe beat me to it | 18:31 |
| 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 |
| kmalloc | and at that point you can support microversions on v2 | 18:31 |
| kmalloc | and v1 is legacy, maintained for compat with old clients/users | 18:32 |
| kmalloc | you give all the shiny new things to v2/v2+microversions so folks are encouraged to use v2 | 18:32 |
| peschk_l | I see. Would you still add endpoint for new features on v2 only, and mark them as experimental ? | 18:32 |
| peschk_l | kmalloc: ok, got my answer :) | 18:32 |
| kmalloc | i would support in your service /v1 <current> | 18:32 |
| kmalloc | and /v2 <new> | 18:32 |
| kmalloc | and have / be a discovery doc | 18:33 |
| kmalloc | so folks can determine what is there (standard for openstack projects these days) | 18:33 |
| kmalloc | keystoneauth has a standard way of doing the discovery bits | 18:33 |
| kmalloc | (ignoring ironic's legacy stuff) | 18:33 |
| peschk_l | OK, I'll look into that | 18:34 |
| kmalloc | that way your endpoints aren't serviceV2 it is just "service" | 18:34 |
| kmalloc | and the user can see "oh service supports v2, i want to use v2" | 18:34 |
| kmalloc | vs needing to go to a totally different endpoint (service/port/host) for v2 | 18:34 |
| edleafe | And existing tools/SDKs can still work against v1 forever | 18:34 |
| kmalloc | just make sure v1 informs smart/sane defaults for the values that the user can't pass to the new backends | 18:35 |
| kmalloc | or the backends have sane defaults built in | 18:35 |
| kmalloc | that way new storage doesn't break if someone uses v1 | 18:35 |
| peschk_l | I see. But then the only way do distinguish between v1+v2 with 1 endpoint and v1+v2 with 4 endpoints and fixes would be the openstack release ? | 18:36 |
| kmalloc | in the discovery doc | 18:36 |
| kmalloc | so you'd look at Service X / and see it supports v1, or v1+v2 or v1+v2(and microversions on v2) | 18:37 |
| peschk_l | current v1 API is compatible with the v2 storage. However, v2 API features won't be compatible with the v1 storage | 18:37 |
| edleafe | peschk_l: if you ever have insomnia and need something to help you sleep, this is excellent reading: http://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.html#consuming-catalog | 18:37 |
| kmalloc | if you only ever implement new storage once v2 is there, the v1 stuff populates defaults to the storage, v2 allows greater depth of configuration | 18:38 |
| kmalloc | if someone is hitting an endpoint with only v1, theyn get current behavior | 18:38 |
| kmalloc | typically the way this is done is | 18:38 |
| kmalloc | 1) implement new storage, make v1 compat | 18:38 |
| kmalloc | 2) implement expirmental v2 api, v1 still works | 18:39 |
| kmalloc | 3) stable v2 api, v1 still works | 18:39 |
| peschk_l | edleafe: thx! (funny, it seems like you are providing a lot of links which I desperately looked for but just couldn't find) | 18:39 |
| kmalloc | and you have no fundamental incompatibilities | 18:39 |
| kmalloc | you can change the requirements for storage in future versions of the service | 18:39 |
| kmalloc | the API should abstract it out so the user can't tell the implementation details on the backend (a good API designed does that) | 18:40 |
| kmalloc | s/good API designed/well designed API | 18:40 |
| * kmalloc swears he knows proper english words and grammar. | 18:40 | |
| edleafe | peschk_l: Here's a good link to bookmark: http://specs.openstack.org/openstack/api-sig/#guidelines | 18:40 |
| *** bobh has quit IRC | 18:40 | |
| peschk_l | kmalloc: does this means that we'd need to backport every new v2 api feature to v1 until support for v1 storage is dropped ? | 18:42 |
| edleafe | peschk_l: no, not at all | 18:42 |
| kmalloc | iterate on storage and get it to where you want. | 18:42 |
| kmalloc | and just make v1 always use the new storage | 18:42 |
| kmalloc | with sane defaults | 18:43 |
| kmalloc | don't backport features, make it so v1 continues to work as expected | 18:43 |
| kmalloc | ideally the API and the storage backend should have little bearing on eachother | 18:43 |
| kmalloc | Users interact with the API, the service translates those interactions to something the storage system can understand | 18:43 |
| peschk_l | OK, that's what I understood earlier. This is how it has been implemented until now | 18:43 |
| kmalloc | so you'd have new shiny-storage and everyone would migrate to it | 18:44 |
| kmalloc | v1 just uses that | 18:44 |
| kmalloc | and then v2 features expose the new-awesome(tm) [YES TRADEMARKED!] things to the end users that the storage system can do | 18:44 |
| peschk_l | kmalloc: ok, thanks for the clarification :) | 18:45 |
| kmalloc | :) | 18:45 |
| kmalloc | hope that helps | 18:45 |
| kmalloc | now... wsme/pecan vs flask vs webob | 18:45 |
| kmalloc | all of that is independent of your API | 18:45 |
| kmalloc | those are tools/frameworks to build your service | 18:45 |
| kmalloc | you can convert or not | 18:45 |
| edleafe | peschk_l: Also, the 'Note' at the top of this page is useful for distinguishing the different API statuses: https://developer.openstack.org/api-guide/quick-start/ | 18:45 |
| kmalloc | there are also ways to layer compatibility in | 18:46 |
| kmalloc | if you want flask i can show you some ways to layer v1 in on top of v2 keeping the old stuff | 18:46 |
| kmalloc | but don't feel like you need to change out the framework just to do v2 | 18:46 |
| kmalloc | it is a LOT of work to swap frameworks/change that stuff out | 18:46 |
| kmalloc | fwiw, (and keystone has a huge api surface area) it was almost 100 commits and probably over 30,000 lines of code changed to get there | 18:47 |
| kmalloc | changing frameworks is VERY disruptive, but can be worth it in some cases | 18:47 |
| kmalloc | just keep in mind the technical cost of doing so | 18:48 |
| kmalloc | and plan for that separately from the implementation of the new API(s) | 18:48 |
| * kmalloc sunk 4+months of work into converting keystone. | 18:49 | |
| peschk_l | kmalloc: we were thinking about an "easy" way: serving two wsgi apps on /v1 and /v2. That way, we'd only need to modify the root controller | 18:49 |
| kmalloc | so i can show you a SUPER easy way | 18:50 |
| peschk_l | (don't worry, cloudkitty's whole codebase is probably smaller thant keystone's API) | 18:50 |
| peschk_l | *than | 18:50 |
| peschk_l | kmalloc: would be glad to hear about it | 18:50 |
| kmalloc | http://werkzeug.pocoo.org/docs/0.14/middlewares/#werkzeug.wsgi.DispatcherMiddleware | 18:51 |
| kmalloc | that middleware right there lets you say "all paths for prefix /XXX goes to app X and all prefixes that don't match fall through to the application" | 18:51 |
| kmalloc | you can have as many rules for matching and passing to apps as you want | 18:51 |
| kmalloc | werkzeug is super cool with the middlewares it provides | 18:52 |
| kmalloc | (werkzeug is the base for flask, but you can use it's middleware without flask) | 18:52 |
| peschk_l | actually, we were planning to use exactly this, but we were not sure if it was a prod-ready | 18:52 |
| kmalloc | keystone ran with it in rocky | 18:53 |
| kmalloc | we subclassed because we needed a LOT of extra stuff | 18:53 |
| kmalloc | but i have no concerns with stable werkzeug code in prod | 18:53 |
| kmalloc | in fact, keystone still uses it | 18:53 |
| kmalloc | and will for the foreseeable future | 18:53 |
| peschk_l | glad to hear that :) is keystone v2 still based on pecan ? | 18:53 |
| kmalloc | https://github.com/openstack/keystone/blob/cd8f7a503673de1cd603b2f5a66e4bbfe3085583/keystone/server/flask/application.py#L163-L171 | 18:54 |
| kmalloc | keystone v2 was based on raw webob | 18:54 |
| kmalloc | keystone v2 also has been deleted and no longer exists | 18:54 |
| kmalloc | i used that middleware to dispatch each of keystone's APIs for the transition to flask | 18:54 |
| kmalloc | so i moved /auth to flask and still dispatched code to the old webob v3 api for /projects | 18:54 |
| kmalloc | until /projects was converted | 18:55 |
| kmalloc | for example | 18:55 |
| kmalloc | peschk_l: you can see what we did here https://github.com/openstack/keystone/blob/stable/rocky/keystone/server/flask/application.py#L81 | 18:55 |
| kmalloc | we moved parts of our api to flask in smaller chunks | 18:56 |
| kmalloc | (master looks far different as you can see, since we run 100% on flask now) | 18:56 |
| * kmalloc has to run | 18:57 | |
| kmalloc | doctor appointment | 18:57 |
| kmalloc | be back in a few hours | 18:57 |
| peschk_l | kmalloc: I'll probably be sleeping when you return, but thank you very much for all the information, it's been a HUGE help :) | 18:58 |
| * edleafe has to go to meeting hell now | 18:58 | |
| kmalloc | happy to help! | 18:58 |
| kmalloc | edleafe: i don't envy you | 18:58 |
| peschk_l | edleafe are you still there ? | 18:58 |
| edleafe | yeah | 18:59 |
| edleafe | but about to disappear into several meetings | 18:59 |
| peschk_l | oh, didn't see you need to go too. Just for the record: I saw that paste is still maintained. Is this only for backward compatibility and should we plan to drop it, or can we stick with it ? | 19:00 |
| peschk_l | and in the case we need to move on: is there a recommendation from your side ? | 19:01 |
| * peschk_l wishes edleafe good luck for the meeting hell | 19:02 | |
| *** bobh has joined #openstack-sdks | 19:15 | |
| *** bobh has quit IRC | 19:20 | |
| *** bobh has joined #openstack-sdks | 19:31 | |
| *** lbragstad has quit IRC | 19:43 | |
| *** lbragstad has joined #openstack-sdks | 19:43 | |
| *** umbSublime has joined #openstack-sdks | 20:00 | |
| *** irclogbot_2 has joined #openstack-sdks | 20:02 | |
| *** mriedem has joined #openstack-sdks | 20:03 | |
| mriedem | who besides dean is an osc core that i can bug for reviews on this old bug fix? https://review.openstack.org/545946 | 20:04 |
| mriedem | amotoki: ^? | 20:08 |
| mordred | mriedem: looking | 20:21 |
| *** irclogbot_2 has quit IRC | 20:22 | |
| mriedem | i'm sure it'll be the best thing you've looked at all day | 20:22 |
| mordred | mriedem: I've been on a plane all day - so as long as it's better than Ocean's 8 - I'll be thrilled | 20:22 |
| mriedem | thanks | 20:23 |
| *** imacdonn has quit IRC | 20:31 | |
| *** irclogbot_2 has joined #openstack-sdks | 21:16 | |
| *** bobh has quit IRC | 21:16 | |
| *** bobh has joined #openstack-sdks | 21:51 | |
| *** bobh has quit IRC | 21:56 | |
| *** mriedem has quit IRC | 22:21 | |
| *** tosky has quit IRC | 22:45 | |
| kmalloc | peschk_l: i would plan on moving off paste. I am in process of writing a compat bit for oslo.middleware to load middleware and the app w/o paste | 23:09 |
| kmalloc | peschk_l: but paste is maintained minimally because we have projects leaning on it | 23:10 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!