Thursday, 2014-03-20

*** rgbkrk has quit IRC00:10
*** rgbkrk has joined #openstack-sdks00:20
*** rgbkrk has quit IRC00:26
*** samchoi has quit IRC00:28
*** samchoi has joined #openstack-sdks03:00
*** samchoi has quit IRC05:27
*** wchrisj has quit IRC06:54
*** jamieh has joined #openstack-sdks09:36
*** jamieh is now known as Guest9441409:36
*** terrylhowe has quit IRC11:03
*** terrylhowe has joined #openstack-sdks11:03
*** bknudson has quit IRC12:57
*** bknudson has joined #openstack-sdks13:21
*** shaunak is now known as ycombinator13:33
ycombinatorsorry mfer, I need to fix my configuration so its always ycombinator13:34
*** wchrisj has joined #openstack-sdks13:43
*** ycombinator has quit IRC13:54
*** ycombinator has joined #openstack-sdks13:54
*** mfer has joined #openstack-sdks14:11
wchrisjelight: krames: just did a brain dump into the fog summit wiki... lol15:04
elightwchrisj: I should’ve sat down with this sooner. This spike was faster than I expected.
elightwchrisj: Most of that is window dressing15:11
elightwchrisj: It’s the DI of the Authenticator in the initializer and the delegation via method_missing that are the important parts.15:12
elightwchrisj: For that matter, all of the OpenStack models and collections go away...15:12
elightwchrisj: 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
mfermorning folks15:14
wchrisjmorning mfer:15:16
wchrisjelight: that's VERY cool15:16
wchrisjagree on use of inheritance - great use case for it here15:16
mferif y'all didn't know... it's the International Day of Happiness...
mfersomehow 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_h15:21
wchrisjelight: 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
elightwchrisj: No worries! It’s a brainstorming page. There are no wrong ideas.15:24
*** krames has joined #openstack-sdks15:45
*** jnoller has joined #openstack-sdks15:47
*** samchoi has joined #openstack-sdks15:48
mferjamie_h ycombinator got a minute?15:59
mferi was hoping one of you could approve
* mfer wants to get everyone looped in on all the things15:59
ycombinatormfer: I think I just approved it16:00
mfernot that I see16:00
mferoh wait16:00
jamie_hmfer i just did16:00
jamie_hi think16:00
mferyeah.... can you change the approver to your name as well16:00
mferthen i can blame you for it later16:01
mferyayz... i see it now16:01
jamie_hycombinator sorry i think i removed you as approver by accident, can you re-add yourself?16:02
mferah, this is fun16:02
jamie_hnot like we do technology or anything :)16:02
jamie_hmfer so is the next step for this a gerrit review or something? or will you add code later?16:03
mferjamie_h the next step is that i'll write the code and then submit it for review16:04
mferthe review will be in gerrit16:04
mferreviews have two parts... code review and approval of the change16:04
ycombinatormfer: how will the gerrit review be associated with this BP?16:04
mfermagic and knowledge16:05
jamie_hycombinator i think you reference the ID in a commit or something16:05
jamie_hmfer are we all voting members on gerrit?16:05
mferthat's about it. and i'll be using a branch name that reflects the blueprint name16:05
mferjamie_h yes. that's why i asked for your handle the other day16:05
mferi added you and ycombinator as core members to the project along with samchoi and myself16:06
jamie_hmfer do all members need to +1 for a change to be merged?16:06
mferthere 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
mferthen there is approval which is separate16:08
mfereach of us has the power to approve16:08
mferjust because something has good code doesn't mean it should go in16:08
*** rgbkrk has joined #openstack-sdks16:09
samchoiso mfer: you think we shouldn't be leaving +2's then? +1's exclusively to force two developers to have a look?16:10
mfersamchoi 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 approve16:13
mfereach thing should have at least 2 sets of eyes on it16:13
*** rgbkrk has quit IRC16:13
*** rgbkrk has joined #openstack-sdks16:14
*** rgbkrk_ has joined #openstack-sdks16:16
*** rgbkrk has quit IRC16:18
*** jnoller has quit IRC16:20
*** rgbkrk_ has quit IRC16:37
*** rgbkrk has joined #openstack-sdks16:37
*** krames has quit IRC16:48
*** Celm has joined #openstack-sdks17:15
*** jamie_h has quit IRC18:06
*** jamie_h has joined #openstack-sdks18:14
*** krames has joined #openstack-sdks18:16
*** krames has quit IRC18:23
wchrisjdtroyer: are you on a mac or linux?18:23
*** krames has joined #openstack-sdks18:24
*** jnoller has joined #openstack-sdks18:33
dtroyerwchrisj: mac air…and literally 3 minutes ago had to defend that because I don't have a CD drive to play music.  ;)18:36
wchrisjdo you use python 2.7.5 (system install) or do you brew your won python?18:37
dtroyerI try to stick to the system python just because (Lion, 2.7.1) but py33 is via homebrew18:37
wchrisjI 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 version18:38
wchrisjdtroyer: I've tried to stick with the system version myself to reduce complexity18:39
dtroyerit's working mostly-well for me, all of the unit tests I run locally work, but little of that is server-side stuff18:39
wchrisjme too18:40
wchrisjsorry to pull you away - thanks!18:40
dtroyernp, I actually was about to come defend^H^H^H^H^Hmention a new review to start adding the low-level sdk bits:
briancurtindtroyer: good timing, Alex_Gaynor and i were talking about moving forward earlier (also griping about CI)18:46
Alex_Gaynordtroyer: Getting lunch in a minute, will review afterwards18:47
dtroyerthat is heavily based on jamielennox's session.Session, but as a subclass, which seems cleaner to me for what I want out of it18:47
dtroyerI'm working on a general discovery lib now...18:48
*** samchoi has quit IRC18:55
*** rgbkrk has quit IRC19:00
wchrisjlooks good dtroyer: will review later this afternoon19:34
*** jamielennox is now known as jamielennox|away19:48
*** krames_ has joined #openstack-sdks20:06
*** krames has quit IRC20:08
*** jamie_h has quit IRC20:44
*** jamielennox|away is now known as jamielennox20:55
jamielennoxdtroyer: my changes to keystoneclient discovery:
jamielennoxit's not completely generalized yet but that will make it a lot easier to do20:57
dtroyerjamielennox:  cool… I've had my head in discovery all afternoon so it's fresh ;)20:58
jamielennoxdtroyer: i made the mistake in the initial discovery code of making it create the client for us, that splits out the querying part of discovery20:58
dtroyeralso, 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 handling20:59
jamielennoxdtroyer: yep i just saw that from this channel21:01
jamielennoxi don't mind the based on requests.Session21:01
jamielennoxi did it the other way so that a single request.Session could be shared amongst many session.Session21:02
jamielennoxthinking primarily of the horizon case where it might be juggling multiple plugins and therefore session objects21:02
jamielennoxbut honestly it doesn't really matter21:02
dtroyerthis doesn't really change that (except maybe the auth header), just changes the naming a bit?21:02
jamielennoxit shouldn't change it at all21:03
dtroyerI've got the multiple context problem too, so that's certainly in mind21:03
jamielennoxdtroyer: i have an idea about multiple contexts21:03
jamielennoxi've had it in mind for a while21:03
jamielennoxi 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
jamielennoxthen you just need to instantiate clients with the plugin_name they should use21:04
jamielennoxit would really only be useful to heat and horizon21:05
terrylhowesounds nice21:05
jamielennoxeveryone else would just keep the same current pattern and we would have a 'default' plugin21:05
terrylhowejamielennox, what was the comment on line 124?21:05
jamielennox124        # NOTE(jamielennox): We handle redirection manually because the21:05
jamielennox125        # requests lib follows some browser patterns where it will redirect21:05
jamielennox126        # POSTs as GETs for certain statuses which is not want we want for an21:05
jamielennox127        # API. See:
terrylhoweoh, I see, I was looking for a note in gerrit21:06
jamielennoxthere 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
jamielennoxi can't remember exactly which statuses would get changed to a GET though21:07
jamielennoxdtroyer: 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
jamielennoxi 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 abstraction21:09
jamielennoxwhen that is all figured out someone can write a transport layer that makes more sense for the SDK21:09
dtroyerkslcient brings in other stuff I don't want…if you're talking about porting the existing code into the openstack namespace, sure21:09
jamielennoxthere are deps there but i don't see that this will be a long term requirement21:10
dtroyergetting rid of the back-compat stuff is also high, because if it is there it will be used21:10
dtroyerI have a review to do that already, it's about 2 weeks out of date though21:10
jamielennoxyea, i just think time is better spent here on the higher level concepts21:11
dtroyersure…except I really need a good base sooner than later21:11
dtroyerI'll let someone else worry about the high-level api21:12
*** jamielennox is now known as jamielennox|away21:22
*** mfer has quit IRC21:25
*** krames_ has quit IRC21:27
dtroyerjamielennox|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 this21:42
*** jnoller has quit IRC23:05
*** jamielennox|away is now known as jamielennox23:08
jamielennoxdtroyer: yes and no, the original discovery object inherits that so all those methods still become public23:10
jamielennoxmy 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
jamielennoxi don't mind making it available and usable - but if a service is doing there own discovery they are doing it wrong23:12
dtroyerendpoint/token auth without a service catalog23:12
dtroyeryou're right in a high-level api…I'm working in the weeds now23:13
jamielennoxdtroyer: why would you use endpoint/token and want to communicate with any service other than that endpoint?23:14
dtroyeryou 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 case23:15
*** bknudson has quit IRC23:16
jamielennoxdtroyer: yea, absolutely23:16
jamielennoxi'm not trying to hide it back there - it still is available via the old discovery interface23:16
jamielennoxand public23:17
dtroyeras 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
jamielennoxand 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 wrong23:17
dtroyerendpoint/token is used today in a lot of places to avoid the overhead of the identity round-trip on each cli call23:19
dtroyeronce cached tokens are around that's ease a bit, but I still don't see it going away23:19
jamielennoxi don't see it going away - but i don't know if it's worth going to extra effort to support that case23:28
jamielennoxif 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 to23:29
dtroyerI'll let you make that assumption all day at the high-level23:29
dtroyerI don't want it to be cut off in the low level23:29
jamielennoxthat's fair23:31
terrylhowethe way I cached with fog is I saved the auth token and the service catalog23:36
terrylhowesure did help performance23:36
jamielennoxterrylhowe: CLI or library?23:37
dtroyerThat's exactly what we'll do within the libs  I'm thinking at a CLI level here…23:37
jamielennoxdtroyer: within the libs?23:37
dtroyerinside any given client23:37
dtroyerinside the sdk itself23:37
terrylhoweIt was CLI, but I made changes in Fog to make it work23:37
jamielennox... why?23:37
dtroyeranything that hangs on to a context23:37
dtroyerphrasing maybe?23:38
terrylhoweI would kind of think it would be nice if the SDK would do that type of caching optionally23:38
jamielennoxdtroyer: i was thinking that i would define some way of serializing/unserializing a session with auth plugins and then the CLI could deal with caching23:38
jamielennoxi don't like the keyring dependency on keystoneclient at the moment - i don't see the point23:38
jamielennoxmaybe not serializing the session - i don't think that's needed, but at least the auth plugins which would include the service catalog23:39
dtroyerI don't like that specific one either, but the general idea of a local cache of auth info (token, sc, etc) is needed23:40
dtroyerI 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 problem23:41
jamielennoxyep, 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-*clients23:41
dtroyerI'm not thinking of those ;)23:42
jamielennoxok -sdk then23:42
jamielennoxi guess if the cache object is abstractable then people can do whatever kind of caching they like and pass that object in23:43
dtroyerI think the sdk needs an abstract cache class for the app to subclass and hand;e the put/get of the cache23:43
dtroyeragain, slo-typer23:43
jamielennoxi had a review that did that for keystoneclient23:43
jamielennoxi think i let it go23:43
dtroyerlet's look at it again when we get to the auth layer here23:44
dtroyerheh, we've nearly doubled the review count since then!23:44
jamielennoxat 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 go23:45
dtroyerI'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 cores23:46
jamielennoxwow, that was august23:47
jamielennoxreview count has exploded23:47
terrylhowejamielennox, that keyring cache looks good to me23:49
terrylhoweI kind of like the idea of having the cache all in the SDK, but I'm definitely not fighting that one23:49
jamielennoxterrylhowe: a lot has changed since then, it won't necessarily transfer to the session-based client23:49
terrylhoweas long as it is possible to cache23:49
jamielennoxbut that's a specific to keystoneclient problem for now23:50
dtroyerI'm off to dinner...23:50

Generated by 2.14.0 by Marius Gedminas - find it at!