Wednesday, 2014-03-26

*** mhagedorn_ has joined #openstack-sdks01:17
*** mhagedorn has quit IRC01:18
*** mhagedorn_ is now known as mhagedorn01:18
*** wchrisj has quit IRC03:43
*** dolphm has quit IRC04:25
*** briancurtin has quit IRC04:25
*** briancurtin has joined #openstack-sdks04:26
*** dolphm has joined #openstack-sdks04:27
*** mhagedorn_ has joined #openstack-sdks05:23
*** mhagedorn has quit IRC05:24
*** mhagedorn_ is now known as mhagedorn05:24
*** samchoi has quit IRC07:02
*** wchrisj has joined #openstack-sdks12:04
wchrisjelight: krames: mhagedorn: g+ hangout invite sent for the meeting this afternoon.12:19
*** krames has quit IRC12:33
*** bknudson has joined #openstack-sdks13:03
*** mfer has joined #openstack-sdks13:04
*** krames has joined #openstack-sdks13:07
*** bknudson has quit IRC13:23
kramesgot it!13:28
*** mhagedorn has quit IRC13:43
*** etoews has joined #openstack-sdks13:52
*** mhagedorn has joined #openstack-sdks13:54
*** etoews_ has joined #openstack-sdks13:56
*** etoews has quit IRC13:57
*** etoews_ has quit IRC14:03
*** etoews has joined #openstack-sdks14:05
*** rgbkrk has joined #openstack-sdks14:31
wchrisjelight: krames: mhagedorn: Am considering editing the request classes to  include the full path past the host for sake of simplicity of codebase overall. Ex: create_token.rb would reflect   :path => '/v2.0/tokens'    versus the way it is now:   :path => '/tokens'    Anyone have a strong feeling about this?14:55
wchrisjelight: krames: mhagedorn: It "feels" more appropriate given our new focus on versioning of all services.14:57
*** mhagedorn has quit IRC14:57
elightwchrisj: +115:00
wchrisjelight: krames: mhagedorn: FWIW - It will minimize the url wrangling overall and is consistent with the way the docs present the urls.15:02
krameswchrisj +115:04
wchrisjelight: krames: mhagedorn: - Coolio15:04
*** mhagedorn has joined #openstack-sdks15:07
*** wchrisj has quit IRC15:18
mferjamie_h ycombinator who wants to start up the G+? I can. Will Glen be joining us today?15:30
*** bknudson has joined #openstack-sdks15:30
jamie_hshaunak won't be able to attend today, glen's in a meeting but will be free in ~10 mins15:32
*** wchrisj has joined #openstack-sdks15:52
wchrisjelight: krames: mhagedorn: Looking at the Rax auth code in fog, why do we retry on a 401? Why would it fail initially and work on retry?15:54
mhagedornwchrisj…. expired tokens would do that I think15:55
mhagedornmaybe to reauthorize credentials?15:56
wchrisjbut what has changed between attempts? Doesnt look like anything changed... mhagedorn:15:56
elightwchrisj has it right, IIRC15:57
mhagedornnot sure of the context, but if you had an Auth header in the last request….15:57
wchrisjseems silly to do a retry if nothing has changed15:57
mhagedornI was talking about requests in general…YMMV15:58
mferjamie_h no worries on the issues. that's too bad15:59
jamie_hg+ hates my wifi15:59
mferglenc jamie_h I hope to have new transport layer code in place before i go to the conference and I'll dig into the PSR for that today16:00
wchrisjelight: krames: mhagedorn: The only scenario that might make sense is if there are network issues, and a simple retry is necessary on a regular basis16:00
jamie_hmfer okay, sounds good16:00
mferglenc jamie_h speaking of FIG, I chatted Larry. If we want to join it we'll need a release and to become involved in the list first.16:01
glencWe can do that, I think16:01
mferso, we're likely looking at the fall before we can do that16:01
*** mhagedorn has quit IRC16:01
jamie_hone question shaunak and I had was whether we're going to refactor the existing code in the stackforge repo, or start from fresh using some of the ideas we've discussed16:01
mferjamie_h i was hoping to migrate the current code because we can use it as a learning exercise in using all the tools.16:02
mferall the tests pass for object storage and identity v2 now. so, as we go we can keep the tests passing as well16:03
jamie_hokay, i see the benefit in that. i was just concerned that a major internal refactoring (i.e to use guzzle transport layer, etc.) would be harder than a greenfield implementation16:03
glencIs there any intent/hope to maintain backwards compatibility?16:04
mferglenc no16:04
jamie_hthe API should probably achieve the same things, but with different method signatures etc.16:04
mferwhat we move to should be much better than anything either of us had before16:05
* mfer has high hopes16:05
glencWe should probably document that decision; I'll add it to the wiki if you like16:05
*** mhagedorn has joined #openstack-sdks16:05
*** wchrisj has quit IRC16:05
mferjamie_h can you take a look at the 3 review we have now and code review them. i'll tie off with Sam about being a second reviewer16:06
jamie_hshall we take a rain check on the repo decision until shaunak is here?16:06
jamie_hand sam16:06
*** wchrisj has joined #openstack-sdks16:07
jamie_hmfer can you link me to the gerrit review?16:08
glencjamie_h see (Gerrit reviews link at bottom)16:08
mferjamie_h,n,z and this link is on the PHP SDK wiki page16:09
glenc(thinking aloud) it might be easier to get other folks involved if we start clean16:10
jamie_hi've reviewed 82924 and 82897 with comments and gave a neutral vote16:10
*** wchrisj has quit IRC16:12
jamie_hfor the CONTRIBUTING review, glen's already reviewed with a +1. if I agree with it now (which I do), can I also approve it - or should that be another process?16:13
glencmfer jamie_h I have to run to my next meeting; any other decisions need to be made today? I'll work with shaunak on getting the weekly meeting set up.16:13
glencIf you think it's good, approve it, jamie_h16:13
jamie_hglenc nope16:13
mfermy concern with going entirely clean is whose version of clean do we go with? we can talk about this later but we need to keep it in mind.16:15
glencYes. But if we're not committed to backwards compatibility, we'll spend a ton of time refactoring, rewriting tests, etc.16:17
glencmfer I may give you a call to discuss when I get a chance16:18
mferglenc please16:19
glencok, I gotta run ...16:19
*** wchrisj has joined #openstack-sdks16:36
mhagedornkrames, elight, wchrisj… is it going too far off the reservation in fog to use normal fog request semantics to create authenticate requests that are custom to a provider (extension layer stuff)… Chris suggested this and I think its an interesting idea.. i.e. use request(hp_authenticate_with_username_password)…. etc16:41
mhagedornkrames, elight, wchrisj…… just answered my own question… cant do that currently ‘cause there would be no way to stop the default auth from happening when you create an instance of OSC::Identity16:43
mhagedornwould be so cool16:43
elightmhagedorn: auth’ing in initialize fail16:44
elightmhagedorn: den wonderful fog (anti-)patterns16:45
wchrisjmhagedorn: but the underlying OSC needs to be able to skip normal auth and JUST do the vendor auth...16:45
wchrisjthat's the whole point of injectiing the vendor auth16:45
wchrisjmhagedorn: ^^16:45
elightI’m hoping we won’t also need to be able to inject Discovery...16:46
elightBecause it could possibly be different by provider ...16:46
wchrisjelight: ugh16:46
elightBut there may be a need to inject both16:46
elightwchrisj: If we’re all using URL and doing it the same way for right now, maybe not.16:46
elightwchrisj: Not sure...16:46
elightwchrisj: I know, later OpenStack won’t use URL (and I approve of this)16:47
wchrisjeliht: cant happen too soon for me16:47
wchrisjelight: ^^16:47
*** samchoi has joined #openstack-sdks17:01
*** wchrisj has quit IRC17:05
mhagedornwchrisj, elight guess gonna have to inject the widget that handles the auth differences17:12
*** etoews has quit IRC17:18
mferjamie_h fyi, guzzle4 + streams package implements the http messages fig proposal and they said it was semi-safe to move forward with that api17:27
mferycombinator samchoi ^^17:28
jamie_hmfer awesome17:29
mferjamie_h the missing element is that the interface defines messages (requests and responses) but not the client interface17:35
jamie_hmfer for the HTTP client? i think they had to start small, because one client can do so much17:37
jamie_hmaybe it's a good thing: gives us more flexibility to decide what we think is the best fit for our project17:37
jamie_hand not implement methods we won't use, etc17:37
mferthat also means we need to have our own client interface for now17:38
mferi'm also trying to figure out what should be a sane default and something that should be easy for an appliation to implement to do something different. like using the guzzle async commands. i could see that being useful for swift17:42
jamie_hmfer maybe a separate method for each HTTP method?17:46
jamie_hwe should probably draw up a list of a basic interface17:47
*** etoews has joined #openstack-sdks18:54
*** jamielennox is now known as jamielennox|away18:54
*** wchrisj has joined #openstack-sdks19:14
*** etoews has quit IRC19:19
*** etoews has joined #openstack-sdks19:19
wchrisjdtroyer: I'm looking at the Keystone v2 docs, and wondering: under what circumstances would a user want to auth with a tenant name and token?19:20
wchrisjdtroyer: {19:20
wchrisj   "auth": {19:20
wchrisj      "tenantName": "demo",19:20
wchrisj      "token": {19:20
wchrisj         "id": "cbc36478b0bd8e67e89469c7749d4127"19:20
wchrisj      }19:20
wchrisj   }19:20
dtroyerhmmm, I first said never, but that may be how you can re-scope a token, ie get one with a different tenant without having to jump through the entire re-auth19:21
wchrisjthat was the only scenario that made sense to me too19:22
dtroyerfor password isn't almost a don't-cate, but for LDAP or OAuth it may be a bigger deal to re-auth19:22
wchrisjMight dolphm: know for sure?19:22
dtroyerhe should, if not him, stevemar or ayoung will for sure19:22
bknudsonit's for rescoping a token19:22
bknudsonI believe horizon uses it19:23
dtroyeror wait for bknudson to show up here ;)19:23
wchrisjahh bknudson: that makes sense ;-)19:23
wchrisjI'll ping one of the guys on that team and ask19:23
wchrisjso, for a general purpose SDK, it's prob not a strong use case? correct? bknudson: dtroyer:19:24
wchrisjmeaning, not a core function19:24
mferwchrisj dtroyer that's for rescoping tokens. and we use that feature in production systems.19:24
bknudsonI wouldn't focus on it as a core function19:24
*** etoews has quit IRC19:24
wchrisjmfer: rescoping befoe they expire, or rescoping to a diff tenant, or both?19:25
bknudsonseems like it's pretty easy to write  general function that takes a user/token and an optional scope19:25
mferwchrisj both19:25
wchrisjmfer: interesting19:25
wchrisjmfer: So for a long running process, that might be a good approach to take...19:26
mferor if you're caching tokens19:26
mferor if you are operating on an account and switching between tokens19:26
mferapps that use an SDK could do a lot of things19:27
bknudsonthe token generated from an existing token will have the same expiration19:27
*** etoews has joined #openstack-sdks19:27
mferhere's a simple use case. you built a custom dashboard/console for an account and need to look at all the projects19:27
bknudsonI think19:27
mferi'm aware of numerous apps written to do this19:27
wchrisjI'v never seen use cases around why this approach was in there...19:27
wchrisjgreat to understand this19:27
*** rgbkrk has quit IRC19:48
elightwchrisj mhagedorn: 5 minutes?19:57
wchrisjheaded that way elight:19:57
mferdtroyer i noticed that each python has its own exceptions. from your experience working with all these clients, has the way each package done its own exceptions been useful?20:14
dtroyerhell no20:21
mferdtroyer the PHP work I'd done so far had a general exception and then exceptions for transport level things that bypass the calling method20:22
dtroyerone of the early consolidation effors was to get those together, but still, each lib has its own exceptions, so in OSC I have to map them if I want to handle them on a common level20:22
mferis there a good way to handle these in your experience20:22
dtroyerin Python they have to come from the same namespace/module to be the same…a single common exceptions module is what is required.20:23
mferwhat kinds of exceptions have you found to be useful if they were all combined?20:24
dtroyerof course, there may be some Python magic that can be applied, I'm certainly not a guru there20:24
dtroyeras a user I want to know the difference between 'connection refused' and 'connection timed out' as they are very different events.  every lib needs those20:25
dtroyermore commonly, though, it is handling HTTP response codes…the exiting libs don't all necessarily even do the same thing there today20:27
mferoutside the transport layer stuff... what's useful?20:27
mferin the app you want to get the HTTP based exceptions... right?20:27
dtroyersometimes I do.  sometimes I want a default handler to take care of them as my purpose doesn't care20:27
dtroyerso the SDK needs to do both at least in the high-level apis20:28
mferso, your your app you don't want to try/catch everything? what pattern would you want instead?20:30
dtroyeragain, it depends on the app.  in OSC I do want to handle most things.  but I've also written apps where I don't care as much why something failed, just to know to retry for example20:32
mferhow would you have an SDK handle both cases?20:36
dtroyerthe 'handle it for me' case is nebulous, but a simple handler could take care of it.  Really, what I don't want is for that to be the only option or the default.20:38
dtroyerI would assume a default handler would also only apply to the high-level APIs, again, I don't necessarily know what those will look like.  That seems to be were the contention in design lies most of the time20:40
mferdtroyer thanks. this was useful20:53
mferi'm off folks. have a good night21:02
*** mfer has quit IRC21:02
*** wchrisj has quit IRC21:11
*** jamielennox|away is now known as jamielennox21:35
*** krames has quit IRC21:47
*** etoews has quit IRC21:53
*** dhellmann is now known as dhellmann_22:03
*** bknudson has quit IRC22:09
*** etoews has joined #openstack-sdks22:22
*** etoews has quit IRC22:27
*** dhellmann_ is now known as dhellmann22:31
*** dhellmann is now known as dhellmann_22:41
*** bknudson has joined #openstack-sdks23:05

Generated by 2.14.0 by Marius Gedminas - find it at!