Thursday, 2018-10-25

*** bobh has joined #openstack-sdks02:13
*** bobh has quit IRC03:32
*** lbragstad has quit IRC04:00
*** Luzi has joined #openstack-sdks06:00
*** tobiash_ has quit IRC06:03
*** tobiash has joined #openstack-sdks06:04
*** gildub has quit IRC06:22
*** maxbab has joined #openstack-sdks06:25
*** slaweq has joined #openstack-sdks06:35
*** gildub has joined #openstack-sdks06:38
*** jpena|off is now known as jpena07:15
*** madorn has quit IRC07:34
*** nmimi has joined #openstack-sdks07:43
*** jpich has joined #openstack-sdks08:00
*** ttsiouts has joined #openstack-sdks08:26
*** sc68cal has quit IRC08:26
*** sc68cal has joined #openstack-sdks08:27
*** e0ne has joined #openstack-sdks08:42
*** gildub has quit IRC08:55
*** gildub has joined #openstack-sdks08:58
*** ttsiouts has quit IRC09:02
*** ttsiouts has joined #openstack-sdks09:02
*** gildub has quit IRC09:07
*** dtantsur|afk is now known as dtantsur09:09
dtantsurmorning folks09:09
*** tosky has joined #openstack-sdks09:16
*** ttsiouts has quit IRC09:21
*** ttsiouts has joined #openstack-sdks09:22
nmimiHi all!My name is Nikos09:46
nmimiI have a task in sfc project, in which i have to replace SNAPS library with SDK and i am facing some difficulties...09:46
nmimiI 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
nmimiI have successfully deleted floating ips, instances, images, flavors, but when i try to delete router i get the following error:09:46
nmimiHttpException: HttpException: Unknown error09:47
nmimii have tried also :09:47
nmimiobj.remove_gateway(conn.session) & obj.remove_interface(conn.session) but i get the following error message:09:47
nmimiEndpointNotFound: Could not find requested endpoint in Service Catalog.09:47
nmimiAfter that errors, i have executed:09:47,
nmimiand the router has been deleted successfully.09:48
nmimiCould please someone tell me what i am doing wrong and i get these error messages?09:48
dtantsurnmimi: hi! maybe the problem is that the router is still connected to a subnet? I seem to recall you cannot delete connected routers09:54
dtantsur"Unknwon error" is not good, of course09:54
nmimiyes the first time i try to delete the router with command router.delete(conn.session) the subnet is still connected09:56
nmimibut i ahave tried also:09:57
nmimisorry wrong command09:57
nmimiand router.remove_gateway(conn.session)09:58
nmimibut i get the error messages09:58
dtantsurabout the endpoint not found?10:02
nmimiyes exactly10:02
dtantsurslaweq: I wonder if you have an idea ^^^10:03
*** gildub has joined #openstack-sdks10:03
slaweqdtantsur: checking10:04
slaweqdtantsur: I don't know why it's like that, maybe nmimi should open bug for that?10:06
nmimiok i will investigate it a bit more and if the error persists i will open a bug10:08
*** cdent has joined #openstack-sdks10:10
*** ttsiouts has quit IRC10:11
*** ttsiouts has joined #openstack-sdks11:04
*** jpena is now known as jpena|lunch11:34
*** jpena|lunch is now known as jpena12:33
*** ttsiouts has quit IRC12:47
*** ttsiouts has joined #openstack-sdks12:48
*** bobh has joined #openstack-sdks13:02
*** d0ugal has quit IRC13:33
*** lbragstad has joined #openstack-sdks13:33
*** d0ugal has joined #openstack-sdks13:34
*** tobberydberg has joined #openstack-sdks13:43
*** d0ugal has quit IRC13:49
*** d0ugal has joined #openstack-sdks13:51
*** Luzi has quit IRC13:57
*** ttsiouts has quit IRC14:24
*** ttsiouts has joined #openstack-sdks14:26
*** maxbab has quit IRC14: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 IRC14:55
*** tobberydberg has quit IRC14:56
*** Luzi has joined #openstack-sdks15:01
*** openstackgerrit has joined #openstack-sdks15:04
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Add disk and container format to image task test
*** jpena is now known as jpena|brb15:04
*** tobberydberg has joined #openstack-sdks15:05
mordreddtantsur, nmimi: the session argument to Resource objects is misleading. try router.remove_interface(
mordredwe really should rename that parameter, but MAN that'll be a big patch15:09
*** tobberydberg has quit IRC15:13
*** jpena|brb is now known as jpena15:15
dtantsuroh yeah15:21
*** tobberydberg has joined #openstack-sdks15:25
*** Luzi has quit IRC15:26
*** bobh has joined #openstack-sdks15:29
mordreddtantsur: are we having bifrost job issues again? I thought we'd fixed that15:31
-openstackstatus- NOTICE: The Zuul and Nodepool database transition is complete. Changes updated during the Zuul outage may need to be rechecked.15:32
openstackgerritMonty Taylor proposed openstack/openstacksdk master: Don't pass disk_format or container_format to image task upload
dtantsurmordred: did keystoneauth with the fix hit upper-constraints?15:33
mordredoh. upper-constraints. hrm. not sure ...15:34
dtantsurdo we have any docs on how to use keystoneauth1.loading.adapter.load_from_conf_options?15:34
dtantsurwhatever I do, it fails with  __init__() missing 1 required positional argument: 'session'15:34
*** bobh has quit IRC15:35
mordreddtantsur: they use it in nova15:35
dtantsurwe use it in ironic too, but that's part of tribal knowledge I don't posess..15:35
mordredoh maybe they don't15:35
mordredyeah they do - nova/utils.py15:36
mordreddtantsur: fwiw, I want to make an sdk equiv15:36
mordredbut 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 object15:37
dtantsurthat would be awesome15:37
mordredI started work on it a couple of days ago - will try oto get an initial thing up tmorrow15:38
*** bobh has joined #openstack-sdks15:39
*** e0ne has quit IRC15:59
edleafeAPI-SIG Office Hour has officially begun16:00
edleafepeschk_l: around?16:00
peschk_ledleafe yes, but unfortunately I don't have an access to my laptop right now, so I may need some time to type16:02
edleafeNo worries16:02
edleafeWill you have time later? I'll be around16:02
peschk_ledleafe: would 18H UTC be ok for you ?16:03
* cdent has a question about microversions16:03
edleafepeschk_l: That would be fine16:04
* edleafe shushes cdent 16:04
* cdent also wonders if elmiko returned from the uk16:04
peschk_ledleafe: perfect :) My questions would mainly be about flask and microversions16:05
mordredkmalloc might be helpful too16:05
mordredhe's been working on the flak transition in keystone16:05
kmallocwhat can i do for folks?16:05
edleafekmalloc: peschk_l has some questions, but isn't at a laptop for another two hours. Will you be around then?16:07
kmallocedleafe: sure!16:07
kmalloci'll be around for a couple hours. In ~3hrs i need to duck out for a couple hours (Doctor appt)16:07
cdentpeschk_l: you might find interesting/useful16:07
kmallocbut will be back when done16:07
kmallocpeschk_l: o/ I'll look for a ping from you a little later today16:08
kmalloccdent: i.. i ... wow that's a thing? neato16:09
peschk_lkmalloc, edleafe Nice, see you later then16:09
cdentkmalloc: dag nabbit, I only sent tons of mail about it once upon a time :)16:09
kmalloccdent: well.... i personally greatly dislike microversions16:09
kmallocso i probably blocked those emails from my brain16:09
kmallocdoesn't change that it's nice to see that packaged up16:09
kmallocand easily consumable16:10
elmikocdent: yes, i did make it back in one piece =)16:10
cdentyeah, that's basically why I did it: this is painful and annoying and a burden so let's make it not16:10
cdentelmiko: excellent16:10
kmallocand that reminds me, i need to re-prioritize my work to do that middleware extraction bit first16:10
kmalloci 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
elmikowow, seems like there is actually some topics today or just folks looking to get more guidance at a future date?16:11
MiougeCan the SDK identity which OpenStack release a given region is running (Pike/Queens/…)? Or is that a “Ask your administrator” type situation?16:12
dtantsurMiouge: the latter. to a great extent because some people mix-and-match versions of different components.16:13
edleafeelmiko: Yeah, peschk_l had a question, but we pushed it until 1800 UTC16:13
* dtantsur sighs at microversions16:13
elmikoedleafe: cool16:13
dtantsurfor the record: ironic-inspector uses flask and microversins (well, some flavor of them)16:14
kmallocMiouge: 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 administrator16:14
edleafedtantsur: Microversions cure all your ills!16:14
dtantsurand now I'm writing a proxy for BM API that will use flask and microversions16:14
dtantsuroh yeah, but how many do they add...16:14
kmallocin general though, it is much easier to just ask "what version"16:14
dtantsurso, I'm writing a proxy. instead of implementing one baremetal API, I need to implement 48 of them16:14
dtantsurwhat a time to be alive16:14
kmallocdtantsur: thankfully flask makes things super easy on that front to do fun things...16:15
kmallocs/fun/fun for some measure of fun/16:15
kmallocpersonally i love the before-request/after-request functions.16:15
kmallocelmiko: ^16:15
kmallocvs. full bore middleware16:15
kmallocalso... with app.test_client() <--- best test client thing ever :)16:16
elmikoi just like how dead simple it is to get a basic http server running16:16
dtantsurkmalloc: that's a good point, these hooks may help with micorversioning stuff16:16
kmallocdtantsur: absolutely.16:16
elmikoi've found the middleware pipeline to be really easy to extend as well16:16
kmallocway way simpler and you don't need to wrap app.wsgi_app (whatever you do do NOT wrap app directly with middleware)16:16
dtantsuryeah, I got running in a few hours, half of them was fighting with oslo.config and keystoneauth :D16:16
dtantsurkmalloc: mmm, why not? I'm quite sure we do it in a few places..16:17
kmallocdtantsur: i found out the hard way to wrap app.wsgi_app when i tried to do test_client16:17
dtantsurah, with tests?16:17
kmallocbasically wsgi_app is the *actual* application16:17
kmallocso if you wrap app.wsgi_app instead it exposes all the nice flask things on app stil16:17
kmalloclike test_client() and test_RequesT_context()16:18
* cdent clearly needs to convert kmalloc to gabbi16:18
dtantsurah, got it. makes sense indeed :)16:18
* kmalloc has also been really deep into the internals of flask to get keystone converted16:18
kmalloci highly recommend flask-restful16:18
kmallocover straight flask if you're doing REST APIs16:18
dtantsurI feel like our API are unrestful enough to not use flask-restful16:19
dtantsurdon't remember for sure, but something made me not go that way16:19
kmallocwell, what i like about flask restful is it builds resource objects you then just implement http methods on16:19
Miougedtantsur and kmalloc thanks! I saw the “openstack versions show” but i’m not able to draw conclusions from that output16:19
kmallocMiouge: yeah, it's a lot of apriori knowledge or "go search the interwebs"16:19
dtantsurkmalloc: ah, this is exactly what I don't like :) I guess tastes differt16:19
kmallocMiouge: i usually just ask.16:20
kmallocdtantsur: ah, with the complexity of keystone's (sigh... double sigh) API, it made life a lot easier16:20
dtantsurI can imagine16:20
kmallocthough it has some weird edge cases, like the resource object isn't instantiated until the request is processed...16:20
dtantsurIronic API is not THAT restful, unfortunately16:20
kmallocthe other benefit is flask-restful has nice hooks for swagger and/or openapi doc16:21
kmallocbut i can see ironic's apis being happier with straight flask16:21
kmalloccdent: i'll have to poke at gabbi then :P16:21
kmalloccdent: hehe16:21
* kmalloc runs off to coffee more then do actual code work.16:22
*** dtantsur is now known as dtantsur|afk16:22
*** mnaser has quit IRC16:26
*** mnaser has joined #openstack-sdks16:26
*** jpich has quit IRC16:28
Miougekmalloc: in my situation asking is not really an option, maybe I can infer stuff based on the nova doc then?
*** ttsiouts has quit IRC16:36
*** imacdonn has quit IRC16:42
*** imacdonn has joined #openstack-sdks16:43
kmallocthat is the idea16:43
kmallocyou should be able to infer things16:43
kmallocit's just much easier if you know what to expect :)16:44
kmalloccdent: ah, gabbi is cool, i think i can couple it with the test_client context manager for great success16:50
kmalloccdent: 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 easy16:51
kmallocso super good stuff, thnx!16:52
cdentkmalloc: 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 thing16:53
kmallocright, for cases we do those things it's going to be perfect16:53
cdentso 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 tests16:53
kmalloca lot of our tests are "do X and check response"16:53
kmallocnah, we didn't change any of our tests (ok not many) when moving to flask16:54
kmallocthat was part of the requirements, so moving to gabbi is totally doable and wont be undoing/redoing much of any work I already did16:54
kmallocin 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.middleware16:56
* elmiko starts cleaning up desk16:57
elmikodon't know if i'll be around at 1800UTC, but if not i'll catch you next week edleafe o/16:57
elmikotake care cdent o/16:58
cdentelmiko: have you been fired?16:58
*** jpena is now known as jpena|off16:58
elmikonot that i know of16:58
cdent"cleaning desk"16:58
elmikooh, lol, bad "office hours" joke16:59
elmikoi 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 IRC17:56
peschk_lkmalloc, edleafe: I'm back18:12
edleafeI'm here18:13
kmallocpeschk_l: o/18:13
peschk_labout 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 API18:14
peschk_lcurrently, 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 contributors18:15
edleafepeschk_l: why would an internal change require changing the API?18:15
kmallocgood question18:16
peschk_ledleafe: because there are a lot of things which our new storage interface supports, for example (re-)grouping18:17
kmallocunless the API leaks implementation details, which then I do encourage fixing that :)18:17
kmallocso how can i help you? :) i'm happy to answer questions re: flask or other things.18:17
edleafeah, so you're adding new functionality?18:17
peschk_ledleafe: exactly18:18
peschk_lwe would at least need to implement a new API endpoint18:18
edleafeAre you using microversions now?18:18
peschk_lgiven 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 resource18:20
peschk_lreleasing a microversion for each migrated resource18:20
peschk_lthe thing is that we don't really know if microversions are used/supported in openstack right now18:21
kmallocsome projects use microversions18:21
edleafeSo 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
kmalloccdent has extracted things into a nice middleware for processing the request itself18:21
peschk_lkmalloc: yeah, I had a look at cdent's link, it look like like it could ease our work :)18:22
edleafeMicroversions are used by nova, placement, ironic, and maybe more18:22
kmallocmicroversions are explicitly NOT used by keystone (for example)18:22
edleafeSo yeah, microversions are supported :)18:22
kmallocso yeah depends on the project18:22
kmallocthere is no reason you should feel like microversions are a tool you should avoid unless you want to avoid them18:23
peschk_ledleafe: 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.yy18:23
kmallocif it makes things easier for you and your users, they can be good.18:23
peschk_luntil we have no more resources in v118:23
peschk_lkmalloc: glad to hear that18:23
edleafeAh. Well, there are many who say that dropping API support is a Very, Very Bad Thing18:24
kmallocso with microversions you wouldn't be eliminating v1, people could fall back to using it18:24
kmallocyou 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 backend18:24
kmallocs/default/sane defaults18:24
peschk_lwell the goal would beb to eliminate v1 after some time18:24
edleafemicroversions only apply within a major release18:25
* kmalloc puts on the former TC/OpenStack leadership hat18:25
edleafeGoing from v1 to v2 is anything but micro18:25
kmallocremoving APIs is bad in general18:25
kmallocas someone who championed removal of an api in a major project, i highly recommend not doing that. it surprises users in bad ways18:25
kmallocedleafe: ++18:26
kmallocas 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 future18:26
edleafeUnless v1 is highly unstable or causes some other extreme issue, you really should keep it around18:27
peschk_ledleafe: 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 v218:27
peschk_l(thanks for the link btw)18:27
kmalloci also highly recommend, whatever you do, not version your endpoints in the catalog18:28
kmallocsupport v1/v2 (as you transition) on the same server/wsgi application18:28
kmallocversioned endpoints are a bad idea.18:29
peschk_lHonestly, v1 has some major issues, for example (and I'm ashamed), there is no way to paginate results, except with begin/end timestamps18:29
edleafepeschk_l: A general approach for creating the new API is along these lines:18:29
edleafe1) create a new endpoint, labeled 'EXPERIMENTAL'18:29
edleafe2) start adding more and more features to that endpoint18:29
peschk_lkmalloc: we weren't planning to manage the endpoints. versions would only have been "markers" for which endpoints are supported, and which are not18:29
edleafe3) When you finally have a good, working version, change that version to 'CURRENT' and change the old version to 'SUPPORTED'18:30
edleafeThis way users can opt into the new API if they wish at their own pace, knowing that it is subject to change18:31
kmalloc^ that is what i was in the middle of typing before edleafe beat me to it18:31
edleafeYou don't flip the switch until the new API is solid, and your can't see any more work needed on it18:31
kmallocand at that point you can support microversions on v218:31
kmallocand v1 is legacy, maintained for compat with old clients/users18:32
kmallocyou give all the shiny new things to v2/v2+microversions so folks are encouraged to use v218:32
peschk_lI see. Would you still add endpoint for new features on v2 only, and mark them as experimental ?18:32
peschk_lkmalloc: ok, got my answer :)18:32
kmalloci would support in your service /v1 <current>18:32
kmallocand /v2 <new>18:32
kmallocand have / be a discovery doc18:33
kmallocso folks can determine what is there (standard for openstack projects these days)18:33
kmallockeystoneauth has a standard way of doing the discovery bits18:33
kmalloc(ignoring ironic's legacy stuff)18:33
peschk_lOK, I'll look into that18:34
kmallocthat way your endpoints aren't serviceV2 it is just "service"18:34
kmallocand the user can see "oh service supports v2, i want to use v2"18:34
kmallocvs needing to go to a totally different endpoint (service/port/host) for v218:34
edleafeAnd existing tools/SDKs can still work against v1 forever18:34
kmallocjust make sure v1 informs smart/sane defaults for the values that the user can't pass to the new backends18:35
kmallocor the backends have sane defaults built in18:35
kmallocthat way new storage doesn't break if someone uses v118:35
peschk_lI 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
kmallocin the discovery doc18:36
kmallocso you'd look at Service X / and see it supports v1, or v1+v2 or v1+v2(and microversions on v2)18:37
peschk_lcurrent v1 API is compatible with the v2 storage. However, v2 API features won't be compatible with the v1 storage18:37
edleafepeschk_l: if you ever have insomnia and need something to help you sleep, this is excellent reading:
kmallocif you only ever implement new storage once v2 is there, the v1 stuff populates defaults to the storage, v2 allows greater depth of configuration18:38
kmallocif someone is hitting an endpoint with only v1, theyn get current behavior18:38
kmalloctypically the way this is done is18:38
kmalloc1) implement new storage, make v1 compat18:38
kmalloc2) implement expirmental v2 api, v1 still works18:39
kmalloc3) stable v2 api, v1 still works18:39
peschk_ledleafe: thx! (funny, it seems like you are providing a lot of links which I desperately looked for but just couldn't find)18:39
kmallocand you have no fundamental incompatibilities18:39
kmallocyou can change the requirements for storage in future versions of the service18:39
kmallocthe 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
kmallocs/good API designed/well designed API18:40
* kmalloc swears he knows proper english words and grammar.18:40
edleafepeschk_l: Here's a good link to bookmark:
*** bobh has quit IRC18:40
peschk_lkmalloc: 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
edleafepeschk_l: no, not at all18:42
kmallociterate on storage and get it to where you want.18:42
kmallocand just make v1 always use the new storage18:42
kmallocwith sane defaults18:43
kmallocdon't backport features, make it so v1 continues to work as expected18:43
kmallocideally the API and the storage backend should have little bearing on eachother18:43
kmallocUsers interact with the API, the service translates those interactions to something the storage system can understand18:43
peschk_lOK, that's what I understood earlier. This is how it has been implemented until now18:43
kmallocso you'd have new shiny-storage and everyone would migrate to it18:44
kmallocv1 just uses that18:44
kmallocand then v2 features expose the new-awesome(tm) [YES TRADEMARKED!] things to the end users that the storage system can do18:44
peschk_lkmalloc: ok, thanks for the clarification :)18:45
kmallochope that helps18:45
kmallocnow... wsme/pecan vs flask vs webob18:45
kmallocall of that is independent of your API18:45
kmallocthose are tools/frameworks to build your service18:45
kmallocyou can convert or not18:45
edleafepeschk_l: Also, the 'Note' at the top of this page is useful for distinguishing the different API statuses:
kmallocthere are also ways to layer compatibility in18:46
kmallocif you want flask i can show you some ways to layer v1 in on top of v2 keeping the old stuff18:46
kmallocbut don't feel like you need to change out the framework just to do v218:46
kmallocit is a LOT of work to swap frameworks/change that stuff out18:46
kmallocfwiw, (and keystone has a huge api surface area) it was almost 100 commits and probably over 30,000 lines of code changed to get there18:47
kmallocchanging frameworks is VERY disruptive, but can be worth it in some cases18:47
kmallocjust keep in mind the technical cost of doing so18:48
kmallocand 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_lkmalloc: 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 controller18:49
kmallocso i can show you a SUPER easy way18:50
peschk_l(don't worry, cloudkitty's whole codebase is probably smaller thant keystone's API)18:50
peschk_lkmalloc: would be glad to hear about it18:50
kmallocthat 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
kmallocyou can have as many rules for matching and passing to apps as you want18:51
kmallocwerkzeug is super cool with the middlewares it provides18:52
kmalloc(werkzeug is the base for flask, but you can use it's middleware without flask)18:52
peschk_lactually, we were planning to use exactly this, but we were not sure if it was a prod-ready18:52
kmallockeystone ran with it in rocky18:53
kmallocwe subclassed because we needed a LOT of extra stuff18:53
kmallocbut i have no concerns with stable werkzeug code in prod18:53
kmallocin fact, keystone still uses it18:53
kmallocand will for the foreseeable future18:53
peschk_lglad to hear that :) is keystone v2 still based on pecan ?18:53
kmallockeystone v2 was based on raw webob18:54
kmallockeystone v2 also has been deleted and no longer exists18:54
kmalloci used that middleware to dispatch each of keystone's APIs for the transition to flask18:54
kmallocso i moved /auth to flask and still dispatched code to the old webob v3 api for /projects18:54
kmallocuntil /projects was converted18:55
kmallocfor example18:55
kmallocpeschk_l: you can see what we did here
kmallocwe moved parts of our api to flask in smaller chunks18:56
kmalloc(master looks far different as you can see, since we run 100% on flask now)18:56
* kmalloc has to run18:57
kmallocdoctor appointment18:57
kmallocbe back in a few hours18:57
peschk_lkmalloc: 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 now18:58
kmallochappy to help!18:58
kmallocedleafe: i don't envy you18:58
peschk_ledleafe are you still there ?18:58
edleafebut about to disappear into several meetings18:59
peschk_loh, 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_land 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 hell19:02
*** bobh has joined #openstack-sdks19:15
*** bobh has quit IRC19:20
*** bobh has joined #openstack-sdks19:31
*** lbragstad has quit IRC19:43
*** lbragstad has joined #openstack-sdks19:43
*** umbSublime has joined #openstack-sdks20:00
*** irclogbot_2 has joined #openstack-sdks20:02
*** mriedem has joined #openstack-sdks20:03
mriedemwho besides dean is an osc core that i can bug for reviews on this old bug fix?
mriedemamotoki: ^?20:08
mordredmriedem: looking20:21
*** irclogbot_2 has quit IRC20:22
mriedemi'm sure it'll be the best thing you've looked at all day20:22
mordredmriedem: I've been on a plane all day - so as long as it's better than Ocean's 8 - I'll be thrilled20:22
*** imacdonn has quit IRC20:31
*** irclogbot_2 has joined #openstack-sdks21:16
*** bobh has quit IRC21:16
*** bobh has joined #openstack-sdks21:51
*** bobh has quit IRC21:56
*** mriedem has quit IRC22:21
*** tosky has quit IRC22:45
kmallocpeschk_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 paste23:09
kmallocpeschk_l: but paste is maintained minimally because we have projects leaning on it23:10

Generated by 2.15.3 by Marius Gedminas - find it at!