| *** rgbkrk has quit IRC | 00:10 | |
| *** rgbkrk has joined #openstack-sdks | 00:20 | |
| *** rgbkrk has quit IRC | 00:26 | |
| *** samchoi has quit IRC | 00:28 | |
| *** samchoi has joined #openstack-sdks | 03:00 | |
| *** samchoi has quit IRC | 05:27 | |
| *** wchrisj has quit IRC | 06:54 | |
| *** jamieh has joined #openstack-sdks | 09:36 | |
| *** jamieh is now known as Guest94414 | 09:36 | |
| *** terrylhowe has quit IRC | 11:03 | |
| *** terrylhowe has joined #openstack-sdks | 11:03 | |
| *** bknudson has quit IRC | 12:57 | |
| *** bknudson has joined #openstack-sdks | 13:21 | |
| *** shaunak is now known as ycombinator | 13:33 | |
| ycombinator | sorry mfer, I need to fix my configuration so its always ycombinator | 13:34 |
|---|---|---|
| *** wchrisj has joined #openstack-sdks | 13:43 | |
| *** ycombinator has quit IRC | 13:54 | |
| *** ycombinator has joined #openstack-sdks | 13:54 | |
| *** mfer has joined #openstack-sdks | 14:11 | |
| wchrisj | elight: krames: just did a brain dump into the fog summit wiki... lol | 15:04 |
| elight | wchrisj: I should’ve sat down with this sooner. This spike was faster than I expected. https://gist.github.com/elight/9665804 | 15:11 |
| elight | wchrisj: Most of that is window dressing | 15:11 |
| elight | wchrisj: It’s the DI of the Authenticator in the initializer and the delegation via method_missing that are the important parts. | 15:12 |
| elight | wchrisj: For that matter, all of the OpenStack models and collections go away... | 15:12 |
| elight | wchrisj: We’d only define our own models if we have to provide more behavior than OpenStack. The interesting question, for us both, is whether we can simple inherit from the OpenStackCommon models. I believe inheritance is the right way to go there. | 15:13 |
| mfer | morning folks | 15:14 |
| wchrisj | morning mfer: | 15:16 |
| wchrisj | elight: that's VERY cool | 15:16 |
| wchrisj | agree on use of inheritance - great use case for it here | 15:16 |
| mfer | if y'all didn't know... it's the International Day of Happiness... https://en.wikipedia.org/wiki/International_Day_of_Happiness | 15:16 |
| mfer | somehow I find it to be bad planning that this is the first day of the NCAA tournament. | 15:17 |
| *** Guest94414 is now known as jamie_h | 15:21 | |
| wchrisj | elight: krames: on a serious note, take a gander at the fog summit updates I made earlier. I would appreciate any comments if my thoughts weren't clear. Also don't mind if any of my stuff would be better served consolidated with earlier comments. I'm clearly the greenest member of this group... :-) | 15:24 |
| elight | wchrisj: No worries! It’s a brainstorming page. There are no wrong ideas. | 15:24 |
| *** krames has joined #openstack-sdks | 15:45 | |
| *** jnoller has joined #openstack-sdks | 15:47 | |
| *** samchoi has joined #openstack-sdks | 15:48 | |
| mfer | jamie_h ycombinator got a minute? | 15:59 |
| ycombinator | sure | 15:59 |
| mfer | i was hoping one of you could approve https://blueprints.launchpad.net/openstack-sdk-php/+spec/psr-4 | 15:59 |
| * mfer wants to get everyone looped in on all the things | 15:59 | |
| ycombinator | mfer: I think I just approved it | 16:00 |
| mfer | not that I see | 16:00 |
| mfer | oh wait | 16:00 |
| jamie_h | mfer i just did | 16:00 |
| jamie_h | i think | 16:00 |
| mfer | yeah.... can you change the approver to your name as well | 16:00 |
| mfer | then i can blame you for it later | 16:01 |
| mfer | :) | 16:01 |
| mfer | yayz... i see it now | 16:01 |
| jamie_h | ycombinator sorry i think i removed you as approver by accident, can you re-add yourself? | 16:02 |
| mfer | hahahahaha | 16:02 |
| ycombinator | lol | 16:02 |
| ycombinator | sure | 16:02 |
| mfer | ah, this is fun | 16:02 |
| jamie_h | not like we do technology or anything :) | 16:02 |
| jamie_h | mfer so is the next step for this a gerrit review or something? or will you add code later? | 16:03 |
| mfer | jamie_h the next step is that i'll write the code and then submit it for review | 16:04 |
| mfer | the review will be in gerrit | 16:04 |
| mfer | reviews have two parts... code review and approval of the change | 16:04 |
| ycombinator | mfer: how will the gerrit review be associated with this BP? | 16:04 |
| mfer | magic and knowledge | 16:05 |
| jamie_h | ycombinator i think you reference the ID in a commit or something | 16:05 |
| jamie_h | mfer are we all voting members on gerrit? | 16:05 |
| mfer | that's about it. and i'll be using a branch name that reflects the blueprint name | 16:05 |
| mfer | jamie_h yes. that's why i asked for your handle the other day | 16:05 |
| mfer | i added you and ycombinator as core members to the project along with samchoi and myself | 16:06 |
| jamie_h | mfer do all members need to +1 for a change to be merged? | 16:06 |
| mfer | no. | 16:07 |
| mfer | there are code reviews. You need to have a +2 total on that and each of us can give it either +1 or +2. | 16:07 |
| mfer | then there is approval which is separate | 16:08 |
| mfer | each of us has the power to approve | 16:08 |
| mfer | just because something has good code doesn't mean it should go in | 16:08 |
| *** rgbkrk has joined #openstack-sdks | 16:09 | |
| samchoi | so mfer: you think we shouldn't be leaving +2's then? +1's exclusively to force two developers to have a look? | 16:10 |
| mfer | samchoi that's likely a good idea yes... unless something is just so obvious it doesn't need two people. i'd also like to see two reviewers. one person shouldn't code review +2 and approve | 16:13 |
| mfer | each thing should have at least 2 sets of eyes on it | 16:13 |
| *** rgbkrk has quit IRC | 16:13 | |
| *** rgbkrk has joined #openstack-sdks | 16:14 | |
| *** rgbkrk_ has joined #openstack-sdks | 16:16 | |
| *** rgbkrk has quit IRC | 16:18 | |
| *** jnoller has quit IRC | 16:20 | |
| *** rgbkrk_ has quit IRC | 16:37 | |
| *** rgbkrk has joined #openstack-sdks | 16:37 | |
| *** krames has quit IRC | 16:48 | |
| *** Celm has joined #openstack-sdks | 17:15 | |
| *** jamie_h has quit IRC | 18:06 | |
| *** jamie_h has joined #openstack-sdks | 18:14 | |
| *** krames has joined #openstack-sdks | 18:16 | |
| *** krames has quit IRC | 18:23 | |
| wchrisj | dtroyer: are you on a mac or linux? | 18:23 |
| *** krames has joined #openstack-sdks | 18:24 | |
| *** jnoller has joined #openstack-sdks | 18:33 | |
| dtroyer | wchrisj: mac air…and literally 3 minutes ago had to defend that because I don't have a CD drive to play music. ;) | 18:36 |
| wchrisj | lol | 18:36 |
| wchrisj | do you use python 2.7.5 (system install) or do you brew your won python? | 18:37 |
| wchrisj | own | 18:37 |
| dtroyer | I try to stick to the system python just because (Lion, 2.7.1) but py33 is via homebrew | 18:37 |
| wchrisj | I recently upgraded to Mavericks on my air, and have been having issues; just wondering if I should abandon system python and brew the latest 2.7.x version | 18:38 |
| wchrisj | dtroyer: I've tried to stick with the system version myself to reduce complexity | 18:39 |
| dtroyer | it's working mostly-well for me, all of the unit tests I run locally work, but little of that is server-side stuff | 18:39 |
| wchrisj | me too | 18:40 |
| wchrisj | sorry to pull you away - thanks! | 18:40 |
| dtroyer | np, I actually was about to come defend^H^H^H^H^Hmention a new review to start adding the low-level sdk bits: https://review.openstack.org/#/c/81882/ | 18:41 |
| briancurtin | dtroyer: good timing, Alex_Gaynor and i were talking about moving forward earlier (also griping about CI) | 18:46 |
| Alex_Gaynor | dtroyer: Getting lunch in a minute, will review afterwards | 18:47 |
| dtroyer | that is heavily based on jamielennox's session.Session, but as a subclass, which seems cleaner to me for what I want out of it | 18:47 |
| dtroyer | I'm working on a general discovery lib now... | 18:48 |
| *** samchoi has quit IRC | 18:55 | |
| *** rgbkrk has quit IRC | 19:00 | |
| wchrisj | looks good dtroyer: will review later this afternoon | 19:34 |
| *** jamielennox is now known as jamielennox|away | 19:48 | |
| *** krames_ has joined #openstack-sdks | 20:06 | |
| *** krames has quit IRC | 20:08 | |
| *** jamie_h has quit IRC | 20:44 | |
| *** jamielennox|away is now known as jamielennox | 20:55 | |
| jamielennox | dtroyer: my changes to keystoneclient discovery: https://review.openstack.org/#/c/81146/ | 20:56 |
| jamielennox | it's not completely generalized yet but that will make it a lot easier to do | 20:57 |
| dtroyer | jamielennox: cool… I've had my head in discovery all afternoon so it's fresh ;) | 20:58 |
| jamielennox | dtroyer: i made the mistake in the initial discovery code of making it create the client for us, that splits out the querying part of discovery | 20:58 |
| dtroyer | also, https://review.openstack.org/#/c/81882/ is my take on session.Session as a requests.Session subclass. I poached a bunch if it from yours…there are a couple of things you might be in a better position to answer, mostly the redirect handling | 20:59 |
| jamielennox | dtroyer: yep i just saw that from this channel | 21:01 |
| jamielennox | i don't mind the based on requests.Session | 21:01 |
| jamielennox | i did it the other way so that a single request.Session could be shared amongst many session.Session | 21:02 |
| jamielennox | thinking primarily of the horizon case where it might be juggling multiple plugins and therefore session objects | 21:02 |
| jamielennox | but honestly it doesn't really matter | 21:02 |
| dtroyer | this doesn't really change that (except maybe the auth header), just changes the naming a bit? | 21:02 |
| jamielennox | it shouldn't change it at all | 21:03 |
| dtroyer | I've got the multiple context problem too, so that's certainly in mind | 21:03 |
| jamielennox | dtroyer: i have an idea about multiple contexts | 21:03 |
| jamielennox | i've had it in mind for a while | 21:03 |
| jamielennox | i was thinking that you could maintain a dictionary of pluginname -> plugin and then instead of saying authenticated=True you could do authenticated='plugin_name' | 21:04 |
| jamielennox | then you just need to instantiate clients with the plugin_name they should use | 21:04 |
| jamielennox | it would really only be useful to heat and horizon | 21:05 |
| terrylhowe | sounds nice | 21:05 |
| jamielennox | everyone else would just keep the same current pattern and we would have a 'default' plugin | 21:05 |
| terrylhowe | jamielennox, what was the comment on line 124? | 21:05 |
| jamielennox | 124 # NOTE(jamielennox): We handle redirection manually because the | 21:05 |
| jamielennox | 125 # requests lib follows some browser patterns where it will redirect | 21:05 |
| jamielennox | 126 # POSTs as GETs for certain statuses which is not want we want for an | 21:05 |
| jamielennox | 127 # API. See: https://en.wikipedia.org/wiki/Post/Redirect/Get | 21:05 |
| terrylhowe | oh, I see, I was looking for a note in gerrit | 21:06 |
| jamielennox | there was a specific test case in keystoneclient that a 305 redirect should work as normal (i don't know where that requirement came from) | 21:07 |
| jamielennox | i can't remember exactly which statuses would get changed to a GET though | 21:07 |
| jamielennox | dtroyer: also wchrisj and i were talking the other day, is there any chance we could just depend on keystoneclient for a while and import the current session object? | 21:08 |
| jamielennox | i think bickering over the transport layer is a waste of the -sdks time, we really need to start looking at how we are going to manage the managers and do things like api abstraction | 21:09 |
| jamielennox | when that is all figured out someone can write a transport layer that makes more sense for the SDK | 21:09 |
| dtroyer | kslcient brings in other stuff I don't want…if you're talking about porting the existing code into the openstack namespace, sure | 21:09 |
| jamielennox | there are deps there but i don't see that this will be a long term requirement | 21:10 |
| dtroyer | getting rid of the back-compat stuff is also high, because if it is there it will be used | 21:10 |
| dtroyer | I have a review to do that already, it's about 2 weeks out of date though | 21:10 |
| jamielennox | yea, i just think time is better spent here on the higher level concepts | 21:11 |
| dtroyer | sure…except I really need a good base sooner than later | 21:11 |
| jamielennox | ok | 21:11 |
| dtroyer | I'll let someone else worry about the high-level api | 21:12 |
| *** jamielennox is now known as jamielennox|away | 21:22 | |
| *** mfer has quit IRC | 21:25 | |
| *** krames_ has quit IRC | 21:27 | |
| dtroyer | jamielennox|away: you made private the bits that aren't tied to Identity/Keystone? We're still coming at this from different angles, but it's getting more acute ;) Even if its inside keystoneclient, I'd love to see a lib-like discovery base that can be used elsewhere. I don't think we can assume that the service catalog handlers are the only consumers of this | 21:42 |
| *** jnoller has quit IRC | 23:05 | |
| *** jamielennox|away is now known as jamielennox | 23:08 | |
| jamielennox | dtroyer: yes and no, the original discovery object inherits that so all those methods still become public | 23:10 |
| jamielennox | my point with it is though once i get all this stuff handled by the session object - what's the real need for other services to be doing there own discovery? | 23:11 |
| jamielennox | i don't mind making it available and usable - but if a service is doing there own discovery they are doing it wrong | 23:12 |
| dtroyer | endpoint/token auth without a service catalog | 23:12 |
| dtroyer | you're right in a high-level api…I'm working in the weeds now | 23:13 |
| jamielennox | dtroyer: why would you use endpoint/token and want to communicate with any service other than that endpoint? | 23:14 |
| dtroyer | you don't, but you still may need/want to do the api version discovery. I'd rather not have two complete code paths to handle that case | 23:15 |
| *** bknudson has quit IRC | 23:16 | |
| jamielennox | dtroyer: yea, absolutely | 23:16 |
| jamielennox | i'm not trying to hide it back there - it still is available via the old discovery interface | 23:16 |
| jamielennox | and public | 23:17 |
| dtroyer | as soon as I figure out WTF Rax is doing in their versions response that is screwing it up I'll push up my current working stuff. | 23:17 |
| jamielennox | and there are always exceptions to the rule but i can't imagine what you are trying to do with endpoint/token auth and trying to communicate with different services - it means the endpoint is wrong | 23:17 |
| dtroyer | endpoint/token is used today in a lot of places to avoid the overhead of the identity round-trip on each cli call | 23:19 |
| dtroyer | once cached tokens are around that's ease a bit, but I still don't see it going away | 23:19 |
| jamielennox | i don't see it going away - but i don't know if it's worth going to extra effort to support that case | 23:28 |
| jamielennox | if people are using the endpoint/token to avoid the auth trip they probably don't want the discovery trip either - you can typically assume that they know the endpoint they want to talk to | 23:29 |
| dtroyer | I'll let you make that assumption all day at the high-level | 23:29 |
| dtroyer | I don't want it to be cut off in the low level | 23:29 |
| jamielennox | that's fair | 23:31 |
| terrylhowe | the way I cached with fog is I saved the auth token and the service catalog | 23:36 |
| terrylhowe | sure did help performance | 23:36 |
| jamielennox | terrylhowe: CLI or library? | 23:37 |
| dtroyer | That's exactly what we'll do within the libs I'm thinking at a CLI level here… | 23:37 |
| jamielennox | dtroyer: within the libs? | 23:37 |
| dtroyer | inside any given client | 23:37 |
| dtroyer | inside the sdk itself | 23:37 |
| terrylhowe | It was CLI, but I made changes in Fog to make it work | 23:37 |
| jamielennox | ... why? | 23:37 |
| dtroyer | anything that hangs on to a context | 23:37 |
| dtroyer | phrasing maybe? | 23:38 |
| terrylhowe | I would kind of think it would be nice if the SDK would do that type of caching optionally | 23:38 |
| jamielennox | dtroyer: i was thinking that i would define some way of serializing/unserializing a session with auth plugins and then the CLI could deal with caching | 23:38 |
| jamielennox | i don't like the keyring dependency on keystoneclient at the moment - i don't see the point | 23:38 |
| jamielennox | maybe not serializing the session - i don't think that's needed, but at least the auth plugins which would include the service catalog | 23:39 |
| dtroyer | I don't like that specific one either, but the general idea of a local cache of auth info (token, sc, etc) is needed | 23:40 |
| dtroyer | yup | 23:40 |
| dtroyer | slo-typer | 23:40 |
| dtroyer | I would like the sdk to define the hooks needed to get that, plus some of the id caching that some clients do today, but the I/O for those is an app-level problem | 23:41 |
| jamielennox | yep, i absolutely agree that we need some form of cache i just see that blurring the lines of app/lib to put that in the python-*clients | 23:41 |
| dtroyer | I'm not thinking of those ;) | 23:42 |
| jamielennox | ok -sdk then | 23:42 |
| jamielennox | i guess if the cache object is abstractable then people can do whatever kind of caching they like and pass that object in | 23:43 |
| dtroyer | I think the sdk needs an abstract cache class for the app to subclass and hand;e the put/get of the cache | 23:43 |
| dtroyer | again, slo-typer | 23:43 |
| jamielennox | i had a review that did that for keystoneclient | 23:43 |
| jamielennox | i think i let it go | 23:43 |
| dtroyer | let's look at it again when we get to the auth layer here | 23:44 |
| jamielennox | https://review.openstack.org/#/c/42254/ | 23:44 |
| dtroyer | heh, we've nearly doubled the review count since then! | 23:44 |
| jamielennox | at the moment i'm picking my battles with keystoneclient, somethings just aren't worth the time it takes to get reviews so i let that one go | 23:45 |
| dtroyer | I've been watching…another reason I'm not keen on trying to put everything there first. not because the input isn't worth it, but because it's not a priority with (all of) the keystone cores | 23:46 |
| jamielennox | wow, that was august | 23:47 |
| jamielennox | review count has exploded | 23:47 |
| terrylhowe | jamielennox, that keyring cache looks good to me | 23:49 |
| terrylhowe | I kind of like the idea of having the cache all in the SDK, but I'm definitely not fighting that one | 23:49 |
| jamielennox | terrylhowe: a lot has changed since then, it won't necessarily transfer to the session-based client | 23:49 |
| terrylhowe | as long as it is possible to cache | 23:49 |
| jamielennox | but that's a specific to keystoneclient problem for now | 23:50 |
| dtroyer | I'm off to dinner... | 23:50 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!