| *** mhagedorn_ has joined #openstack-sdks | 01:17 | |
| *** mhagedorn has quit IRC | 01:18 | |
| *** mhagedorn_ is now known as mhagedorn | 01:18 | |
| *** wchrisj has quit IRC | 03:43 | |
| *** dolphm has quit IRC | 04:25 | |
| *** briancurtin has quit IRC | 04:25 | |
| *** briancurtin has joined #openstack-sdks | 04:26 | |
| *** dolphm has joined #openstack-sdks | 04:27 | |
| *** mhagedorn_ has joined #openstack-sdks | 05:23 | |
| *** mhagedorn has quit IRC | 05:24 | |
| *** mhagedorn_ is now known as mhagedorn | 05:24 | |
| *** samchoi has quit IRC | 07:02 | |
| *** wchrisj has joined #openstack-sdks | 12:04 | |
| wchrisj | elight: krames: mhagedorn: g+ hangout invite sent for the meeting this afternoon. | 12:19 |
|---|---|---|
| *** krames has quit IRC | 12:33 | |
| *** bknudson has joined #openstack-sdks | 13:03 | |
| *** mfer has joined #openstack-sdks | 13:04 | |
| *** krames has joined #openstack-sdks | 13:07 | |
| *** bknudson has quit IRC | 13:23 | |
| krames | got it! | 13:28 |
| *** mhagedorn has quit IRC | 13:43 | |
| *** etoews has joined #openstack-sdks | 13:52 | |
| *** mhagedorn has joined #openstack-sdks | 13:54 | |
| *** etoews_ has joined #openstack-sdks | 13:56 | |
| *** etoews has quit IRC | 13:57 | |
| *** etoews_ has quit IRC | 14:03 | |
| *** etoews has joined #openstack-sdks | 14:05 | |
| *** rgbkrk has joined #openstack-sdks | 14:31 | |
| wchrisj | elight: 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 |
| wchrisj | elight: krames: mhagedorn: It "feels" more appropriate given our new focus on versioning of all services. | 14:57 |
| *** mhagedorn has quit IRC | 14:57 | |
| elight | wchrisj: +1 | 15:00 |
| wchrisj | elight: krames: mhagedorn: FWIW - It will minimize the url wrangling overall and is consistent with the way the docs present the urls. | 15:02 |
| krames | wchrisj +1 | 15:04 |
| wchrisj | elight: krames: mhagedorn: - Coolio | 15:04 |
| *** mhagedorn has joined #openstack-sdks | 15:07 | |
| *** wchrisj has quit IRC | 15:18 | |
| mfer | jamie_h ycombinator who wants to start up the G+? I can. Will Glen be joining us today? | 15:30 |
| *** bknudson has joined #openstack-sdks | 15:30 | |
| jamie_h | shaunak won't be able to attend today, glen's in a meeting but will be free in ~10 mins | 15:32 |
| mfer | jamie_h https://plus.google.com/hangouts/_/72cpjimaiess46o8d7qdvtmel0?hl=en | 15:32 |
| *** wchrisj has joined #openstack-sdks | 15:52 | |
| wchrisj | elight: 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 |
| mhagedorn | wchrisj…. expired tokens would do that I think | 15:55 |
| mhagedorn | maybe to reauthorize credentials? | 15:56 |
| wchrisj | but what has changed between attempts? Doesnt look like anything changed... mhagedorn: | 15:56 |
| elight | wchrisj has it right, IIRC | 15:57 |
| mhagedorn | not sure of the context, but if you had an Auth header in the last request…. | 15:57 |
| wchrisj | seems silly to do a retry if nothing has changed | 15:57 |
| mhagedorn | I was talking about requests in general…YMMV | 15:58 |
| glenc | \o | 15:59 |
| elight | o/ | 15:59 |
| mfer | jamie_h no worries on the issues. that's too bad | 15:59 |
| jamie_h | g+ hates my wifi | 15:59 |
| mfer | glenc 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 today | 16:00 |
| wchrisj | elight: krames: mhagedorn: The only scenario that might make sense is if there are network issues, and a simple retry is necessary on a regular basis | 16:00 |
| jamie_h | mfer okay, sounds good | 16:00 |
| mfer | glenc 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 |
| glenc | We can do that, I think | 16:01 |
| mfer | so, we're likely looking at the fall before we can do that | 16:01 |
| *** mhagedorn has quit IRC | 16:01 | |
| jamie_h | one 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 discussed | 16:01 |
| mfer | jamie_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 |
| mfer | all the tests pass for object storage and identity v2 now. so, as we go we can keep the tests passing as well | 16:03 |
| jamie_h | okay, 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 implementation | 16:03 |
| glenc | Is there any intent/hope to maintain backwards compatibility? | 16:04 |
| mfer | glenc no | 16:04 |
| jamie_h | the API should probably achieve the same things, but with different method signatures etc. | 16:04 |
| mfer | what we move to should be much better than anything either of us had before | 16:05 |
| * mfer has high hopes | 16:05 | |
| glenc | We should probably document that decision; I'll add it to the wiki if you like | 16:05 |
| mfer | sure | 16:05 |
| *** mhagedorn has joined #openstack-sdks | 16:05 | |
| *** wchrisj has quit IRC | 16:05 | |
| mfer | jamie_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 reviewer | 16:06 |
| jamie_h | shall we take a rain check on the repo decision until shaunak is here? | 16:06 |
| jamie_h | and sam | 16:06 |
| *** wchrisj has joined #openstack-sdks | 16:07 | |
| jamie_h | mfer can you link me to the gerrit review? | 16:08 |
| glenc | jamie_h see https://wiki.openstack.org/wiki/OpenStack-SDK-PHP#Requirements (Gerrit reviews link at bottom) | 16:08 |
| mfer | jamie_h https://review.openstack.org/#/q/status:open+project:stackforge/openstack-sdk-php,n,z and this link is on the PHP SDK wiki page | 16:09 |
| glenc | (thinking aloud) it might be easier to get other folks involved if we start clean | 16:10 |
| jamie_h | i've reviewed 82924 and 82897 with comments and gave a neutral vote | 16:10 |
| *** wchrisj has quit IRC | 16:12 | |
| jamie_h | for 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 |
| glenc | mfer 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 |
| glenc | If you think it's good, approve it, jamie_h | 16:13 |
| jamie_h | glenc nope | 16:13 |
| mfer | my 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 |
| glenc | Yes. But if we're not committed to backwards compatibility, we'll spend a ton of time refactoring, rewriting tests, etc. | 16:17 |
| glenc | mfer I may give you a call to discuss when I get a chance | 16:18 |
| mfer | glenc please | 16:19 |
| glenc | ok, I gotta run ... | 16:19 |
| *** wchrisj has joined #openstack-sdks | 16:36 | |
| mhagedorn | krames, 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)…. etc | 16:41 |
| mhagedorn | krames, 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::Identity | 16:43 |
| mhagedorn | crud | 16:43 |
| mhagedorn | would be so cool | 16:43 |
| elight | mhagedorn: auth’ing in initialize fail | 16:44 |
| elight | mhagedorn: den wonderful fog (anti-)patterns | 16:45 |
| elight | dem | 16:45 |
| wchrisj | mhagedorn: but the underlying OSC needs to be able to skip normal auth and JUST do the vendor auth... | 16:45 |
| wchrisj | that's the whole point of injectiing the vendor auth | 16:45 |
| wchrisj | mhagedorn: ^^ | 16:45 |
| elight | I’m hoping we won’t also need to be able to inject Discovery... | 16:46 |
| elight | Because it could possibly be different by provider ... | 16:46 |
| wchrisj | elight: ugh | 16:46 |
| elight | But there may be a need to inject both | 16:46 |
| elight | wchrisj: If we’re all using URL and doing it the same way for right now, maybe not. | 16:46 |
| elight | wchrisj: Not sure... | 16:46 |
| elight | wchrisj: I know, later OpenStack won’t use URL (and I approve of this) | 16:47 |
| wchrisj | eliht: cant happen too soon for me | 16:47 |
| wchrisj | elight: ^^ | 16:47 |
| *** samchoi has joined #openstack-sdks | 17:01 | |
| *** wchrisj has quit IRC | 17:05 | |
| mhagedorn | wchrisj, elight guess gonna have to inject the widget that handles the auth differences | 17:12 |
| *** etoews has quit IRC | 17:18 | |
| mfer | jamie_h fyi, guzzle4 + streams package implements the http messages fig proposal and they said it was semi-safe to move forward with that api | 17:27 |
| mfer | ycombinator samchoi ^^ | 17:28 |
| jamie_h | mfer awesome | 17:29 |
| mfer | jamie_h the missing element is that the interface defines messages (requests and responses) but not the client interface | 17:35 |
| jamie_h | mfer for the HTTP client? i think they had to start small, because one client can do so much | 17:37 |
| jamie_h | maybe it's a good thing: gives us more flexibility to decide what we think is the best fit for our project | 17:37 |
| jamie_h | and not implement methods we won't use, etc | 17:37 |
| mfer | that also means we need to have our own client interface for now | 17:38 |
| mfer | i'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 swift | 17:42 |
| jamie_h | hmm | 17:45 |
| jamie_h | mfer maybe a separate method for each HTTP method? | 17:46 |
| jamie_h | we should probably draw up a list of a basic interface | 17:47 |
| *** etoews has joined #openstack-sdks | 18:54 | |
| *** jamielennox is now known as jamielennox|away | 18:54 | |
| *** wchrisj has joined #openstack-sdks | 19:14 | |
| *** etoews has quit IRC | 19:19 | |
| *** etoews has joined #openstack-sdks | 19:19 | |
| wchrisj | dtroyer: 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 |
| wchrisj | dtroyer: { | 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 |
| wchrisj | } | 19:20 |
| dtroyer | hmmm, 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-auth | 19:21 |
| wchrisj | that was the only scenario that made sense to me too | 19:22 |
| dtroyer | for password isn't almost a don't-cate, but for LDAP or OAuth it may be a bigger deal to re-auth | 19:22 |
| wchrisj | Might dolphm: know for sure? | 19:22 |
| dtroyer | he should, if not him, stevemar or ayoung will for sure | 19:22 |
| bknudson | it's for rescoping a token | 19:22 |
| bknudson | I believe horizon uses it | 19:23 |
| dtroyer | or wait for bknudson to show up here ;) | 19:23 |
| wchrisj | ahh bknudson: that makes sense ;-) | 19:23 |
| wchrisj | I'll ping one of the guys on that team and ask | 19:23 |
| wchrisj | so, for a general purpose SDK, it's prob not a strong use case? correct? bknudson: dtroyer: | 19:24 |
| wchrisj | meaning, not a core function | 19:24 |
| mfer | wchrisj dtroyer that's for rescoping tokens. and we use that feature in production systems. | 19:24 |
| bknudson | I wouldn't focus on it as a core function | 19:24 |
| *** etoews has quit IRC | 19:24 | |
| wchrisj | mfer: rescoping befoe they expire, or rescoping to a diff tenant, or both? | 19:25 |
| bknudson | seems like it's pretty easy to write general function that takes a user/token and an optional scope | 19:25 |
| mfer | wchrisj both | 19:25 |
| wchrisj | mfer: interesting | 19:25 |
| wchrisj | mfer: So for a long running process, that might be a good approach to take... | 19:26 |
| mfer | or if you're caching tokens | 19:26 |
| mfer | or if you are operating on an account and switching between tokens | 19:26 |
| mfer | apps that use an SDK could do a lot of things | 19:27 |
| bknudson | the token generated from an existing token will have the same expiration | 19:27 |
| wchrisj | cool | 19:27 |
| *** etoews has joined #openstack-sdks | 19:27 | |
| mfer | here's a simple use case. you built a custom dashboard/console for an account and need to look at all the projects | 19:27 |
| bknudson | I think | 19:27 |
| mfer | i'm aware of numerous apps written to do this | 19:27 |
| wchrisj | I'v never seen use cases around why this approach was in there... | 19:27 |
| wchrisj | great to understand this | 19:27 |
| *** rgbkrk has quit IRC | 19:48 | |
| elight | wchrisj mhagedorn: 5 minutes? | 19:57 |
| wchrisj | headed that way elight: | 19:57 |
| mfer | dtroyer 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 |
| dtroyer | hell no | 20:21 |
| mfer | dtroyer the PHP work I'd done so far had a general exception and then exceptions for transport level things that bypass the calling method | 20:22 |
| dtroyer | one 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 level | 20:22 |
| mfer | is there a good way to handle these in your experience | 20:22 |
| dtroyer | in 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 |
| mfer | what kinds of exceptions have you found to be useful if they were all combined? | 20:24 |
| dtroyer | of course, there may be some Python magic that can be applied, I'm certainly not a guru there | 20:24 |
| dtroyer | as a user I want to know the difference between 'connection refused' and 'connection timed out' as they are very different events. every lib needs those | 20:25 |
| dtroyer | more commonly, though, it is handling HTTP response codes…the exiting libs don't all necessarily even do the same thing there today | 20:27 |
| mfer | outside the transport layer stuff... what's useful? | 20:27 |
| mfer | ok | 20:27 |
| mfer | in the app you want to get the HTTP based exceptions... right? | 20:27 |
| dtroyer | sometimes I do. sometimes I want a default handler to take care of them as my purpose doesn't care | 20:27 |
| dtroyer | so the SDK needs to do both at least in the high-level apis | 20:28 |
| mfer | so, your your app you don't want to try/catch everything? what pattern would you want instead? | 20:30 |
| dtroyer | again, 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 example | 20:32 |
| mfer | how would you have an SDK handle both cases? | 20:36 |
| dtroyer | the '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 |
| dtroyer | I 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 time | 20:40 |
| mfer | dtroyer thanks. this was useful | 20:53 |
| mfer | i'm off folks. have a good night | 21:02 |
| *** mfer has quit IRC | 21:02 | |
| *** wchrisj has quit IRC | 21:11 | |
| *** jamielennox|away is now known as jamielennox | 21:35 | |
| *** krames has quit IRC | 21:47 | |
| *** etoews has quit IRC | 21:53 | |
| *** dhellmann is now known as dhellmann_ | 22:03 | |
| *** bknudson has quit IRC | 22:09 | |
| *** etoews has joined #openstack-sdks | 22:22 | |
| *** etoews has quit IRC | 22:27 | |
| *** dhellmann_ is now known as dhellmann | 22:31 | |
| *** dhellmann is now known as dhellmann_ | 22:41 | |
| *** bknudson has joined #openstack-sdks | 23:05 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!