Tuesday, 2014-04-15

*** wchrisj has joined #openstack-sdks00:02
*** wchrisj has quit IRC00:10
*** mhagedorn has quit IRC00:21
*** etoews has quit IRC00:38
*** mhagedorn has joined #openstack-sdks00:46
*** mhagedorn has quit IRC00:51
*** mhagedorn has joined #openstack-sdks00:56
*** mhagedorn has quit IRC00:56
*** ekarlso has quit IRC01:11
*** ekarlso has joined #openstack-sdks01:13
*** ekarlso has quit IRC01:13
*** ekarlso has joined #openstack-sdks01:18
*** mhagedorn has joined #openstack-sdks01:53
*** wchrisj has joined #openstack-sdks03:55
*** etoews has joined #openstack-sdks04:03
*** etoews has quit IRC04:08
*** wchrisj has quit IRC04:11
*** mhagedorn has quit IRC04:43
*** jamielennox is now known as jamielennox|away06:07
*** etoews has joined #openstack-sdks06:08
*** etoews has quit IRC06:12
*** al_ex has joined #openstack-sdks06:46
*** etoews has joined #openstack-sdks07:09
*** etoews has quit IRC07:14
*** Alex_Gaynor has quit IRC08:32
*** Alex_Gaynor has joined #openstack-sdks08:37
*** etoews has joined #openstack-sdks09:11
*** etoews has quit IRC09:15
*** masahito has joined #openstack-sdks10:42
*** etoews has joined #openstack-sdks10:56
*** etoews has quit IRC11:00
*** etoews has joined #openstack-sdks11:57
*** etoews has quit IRC12:04
*** etoews has joined #openstack-sdks12:31
*** krames has joined #openstack-sdks12:37
*** Alex_Gaynor has quit IRC12:53
*** Alex_Gaynor has joined #openstack-sdks13:06
*** krames has quit IRC13:18
*** krames has joined #openstack-sdks13:18
*** mhagedorn has joined #openstack-sdks13:23
*** bknudson has joined #openstack-sdks13:26
*** mfer has joined #openstack-sdks13:35
*** wchrisj has joined #openstack-sdks13:59
elightwchrisj mhagedorn krames: we should avoid doing this if at all possible in OSC: Going into town for14:10
elightThis will eat up more memory, by loading more classes and creating more methods, than are needed.14:11
elightMost users will only need one version of Identity and, probably, any given service.14:11
elightmhagedorn: Yeppers14:11
elightI’ll add that to ServiceDiscovery.14:11
mhagedornelight +114:11
wchrisjMakes sense, now that you bring it up. funny how you have to constantly consider patterns you've seen and used in the past and whether they make sense or not in the present circumstances.14:13
elightOnly noticed when I ran into trying to load my StorageV1 and found it wasn’t there yet.14:13
wchrisjmakes particular sense to do the requires inside of discovery14:14
wchrisjelight So what are your feelings of having to always set a version? ok with it?14:14
wchrisjmore consistent to always do it14:15
elightIt a nuisance with respect to Identity14:15
elightBecause Identity is used by every other service14:15
elightOtherwise, yeah, I’d be fine with it14:15
elightI hate special cases...14:16
wchrisjme too14:16
elightOooh using require_relative in the specs14:17
elightThat’ll fail against 1.8.714:17
wchrisjyeah - we are aware of that ugliness14:18
wchrisjI didnt reallize when we started writing specs that that was an issue14:18
wchrisjhavent cleaned it up yet14:18
wchrisjMike and I are aware of it IOW...14:19
*** dolphm is now known as dolphem14:31
*** mhagedorn has quit IRC14:32
*** mhagedorn has joined #openstack-sdks14:38
mhagedornelight can you repost that gist?  colloquy shut down and lost all the context...14:47
elightirccloud is your friend14:48
mhagedornelgith yeah ,yeah :)14:48
mhagedornI am not supposed to eat donuts either14:48
elightHorse. Water. ‘buff said. ;-) ;-)14:49
mhagedornyeah crap.. doing the same silly move in hptng.. sigh14:49
mhagedornelight… pardon my 1st cup of coffee brain here..(and the afore mentioned loss of context).. is this dynamic require the domain of fog-core or OSC::ServiceDiscovery… guessing the latter14:52
elightI’m working on it14:53
elightPR soon-ish14:53
elightGoing to shake things up a little bit. Service versions seem to me like they should be akin to plugins: self-registering14:53
elightServiceDiscovery ideally shouldn’t need all of this hard-coded information.14:53
elightLet the Service tell SD what it needs to know14:53
elightThat way we centralize information about the service in… the service!14:54
mhagedornelight works for me…. FWIW in my implementation I didnt create the SD class directly ‘cause I didnt want my HPTNG Identity proxy to know about it…15:07
mhagedornelight.. i.e. I let the Fog::Identity magic do the right thing15:07
mhagedornelight your way is more performant however15:08
mhagedornelight.. not sure what the higher good is on that point.. encapsulation of SD or raw performance…. not sure15:09
*** mhagedorn has quit IRC15:28
*** mhagedorn_ has joined #openstack-sdks15:29
*** al_ex has quit IRC15:30
*** etoews_ has joined #openstack-sdks15:32
*** etoews has quit IRC15:35
elightmhagedorn_: Encapsulating ServiceDiscovery? How do you hook into it then?  We are dependent upon it still, right?15:37
elightmhagedorn_: If we’re dependent upon it, I like having the dependency be explicitly.15:37
elightmhagedorn_ wchrisj krames; So here’s sort of what I’m thinking https://github.com/fog-openstack-tng/fog_openstack_tng/pull/2215:38
elightmhagedorn_ wchrisj krames: Made several changes to make ServiceDiscovery more unit testable15:38
briancurtinbeen busy with pycon so i didn't send out the email, but python-openstacksdk meeting at 19:00 UTC again today (currently catching up on review)15:42
*** sharwell_ has joined #openstack-sdks15:45
mhagedorn_elight.. for example  https://gist.github.com/mwhagedorn/1074351715:56
mhagedorn_elight techinally the only dependency I am exposing is on Fog::OSC::Identity… leaving the mysteries of servicediscovery encapsulated15:57
mhagedorn_elight mainly because I dont have to know about SD at this point15:58
mhagedorn_but its open for discussion15:58
elightmhagedorn_: Ok, I think I know why this feels odd to me. Hp/RackspaceTng::Identity creates IdentityVx < Fog::OSC::IdentityVx.  But now there’s a dependency on Fog::OSC::Identity when what we’re truly dependent on is ServiceDiscovery.16:07
elightmhagedorn_: That’s a mouthful16:07
elightmhagedorn_: Short version: using OSC::Identity doesn’t seem to add any benefit other than obscure the dependency on SD16:08
elightBecause OSC::Identity just turns around and calls SD.16:08
*** samchoi has joined #openstack-sdks16:08
mhagedorn_eliight.. its true but HpTng::Identity doesnt know or care ‘bout that16:09
elightmhagedorn_: It’s all a matter of agreeing upon “what is our API into OSC"16:09
mhagedorn_yeah… can go eitther way… your way is more peformant… I just like the encapsulation16:10
elightmhagedorn_: OSC::Identity et al may be a little less chatty but is it enough so to justify another layer of indirection? I’m not sure...16:10
elightmhagedorn_: Honestly not thinking about performance. Thinking about number of dependencies.16:10
elightOSC::Identity is useful as an API to vanilla Keystone, yes. But for this? Not so sure.16:12
mhagedorn_well.. at this point at least.. I am shielded from having to know HOW i get my service instance instantiated16:13
mhagedorn_and… at this point at least HPTng only supports really one request...16:14
elightmhagedorn_: Sort of? ServiceDiscovery, from the outside, isn’t really the “how".  That’s the implementation.16:14
elightmhagedorn_: Heh. No different here (re: one request) only because I’m trying to see how other services would consume Identity: see https://github.com/fog-openstack-tng/fog_openstack_tng/pull/2316:15
elightCC krames wchrisj ^^16:15
mhagedorn_elight… yeah honestly will know more when compute/swift start to get implemented for OSC16:16
elightThat’s what I started doing. And it feels weird….16:16
elightmhagedorn_: https://github.com/fog-openstack-tng/fog_openstack_tng/pull/23 >.<16:16
mhagedorn_will look at16:17
elightReally? I don’t like it….16:17
elight Oops I meant https://github.com/fog-openstack-tng/fog_openstack_tng/blob/storage/lib/fog/openstackcommon/services/storage_v1.rb#L35-L4316:17
mhagedorn_elight… imagine you are gonna have to introspect service catalog on identity to get you CDN urls as well16:19
mhagedorn_(not sure how rax does CDN, think hp does it differently)16:19
kramesit looks good to me16:23
kramesthat example doesn't look at the endpoints though16:23
kramesis that going to come later or am I missing something?16:23
elightkrames: http://verysmartbrothas.com/images/Do-not-think-it-means.jpeg?c0764716:24
elightkrames: Haven’t even thought about endpoints for Storage yet. Was more concerned with what it would look like to consume Identity in another service.16:24
mhagedorn_krames.. yeah the service catalog will have to be referenced for swift too.. duh16:24
mhagedorn_brain is slow16:24
elights/what it would look like/how it would work/16:25
mhagedorn_so it would be like @idenitity.service_catalog.find(“swift”)16:25
mhagedorn_(pseudo code)16:25
mhagedorn_although active record style finders might be cool on SC :)16:26
*** bknudson has quit IRC16:41
mhagedorn_krames need to get your take today on setting up tests against production endpoints (aka not devstack).. for jenkins16:49
*** Guest5337 is now known as sivel17:10
*** sivel has quit IRC17:10
*** sivel has joined #openstack-sdks17:10
*** etoews has joined #openstack-sdks17:13
*** etoews_ has quit IRC17:16
*** bknudson has joined #openstack-sdks17:27
*** bknudson has quit IRC17:32
*** bknudson has joined #openstack-sdks17:46
*** mfer has quit IRC17:51
*** mfer has joined #openstack-sdks17:51
wchrisjelight Just catching up on the discussion. The decision to use OSC::Identity was based on the need/desire to factory up a specific version of the Identity service. If we can sidestep that, and use the SD to get that, I think that would be OK by me... need to think about that and possible side effects...17:53
mhagedorn_wchrisj.. its not sidestepping the proxy class. thats still needed…. the question is how much does the subclass need to know17:55
wchrisjThe language used above seemed to me to clearly indicate no need for the proxy class. elight krames mhagedorn17:56
*** jamielennox|away is now known as jamielennox18:01
*** dolphem is now known as dolphm18:01
wchrisjelight What were you thinking when you noted this:18:03
wchrisj[12:08:02]  <elight> mhagedorn_: Short version: using OSC::Identity doesn’t seem to add any benefit other than obscure the dependency on SD18:03
wchrisj[12:08:12]  <elight> Because OSC::Identity just turns around and calls SD.18:03
wchrisjelight I'm not agreeing/disagreeing - just trying to understand the intent...18:04
*** krames has quit IRC18:08
*** krames has joined #openstack-sdks18:09
*** mhagedorn_ has quit IRC18:18
kramesmhagedorn_ I sent you an email about jenkins18:19
wchrisjelight krames mhagedorn Did you guys see the name change? OSC is now OpenStackCore... I like it!18:19
wchrisj... and the repo has now been moved.18:19
*** mhagedorn has joined #openstack-sdks18:19
kramesme too18:19
wchrisjgiven our vendor extensions, that makes perfect sense.18:20
krameswchrisj is the name of the gem going to be fog-openstack-core ?18:20
wchrisjI would assume so krames; it follows convention.18:20
wchrisjWe need to pick a timeframe and get the name sync'd up internally.18:23
wchrisjelight krames mhagedorn ^^18:23
wchrisjI can open a PR to get that done quick enough18:23
wchrisjkrames elight mhagedorn Done - https://github.com/fog/fog-openstack-core/pull/2418:42
wchrisjtests pass18:42
wchrisjMay as well get on this train ASAP18:43
krameswchrisj I don't know if he told you, but elight is taking a half day today18:44
wchrisjkrames Thanks - did not know that.18:45
*** wchrisj_ has joined #openstack-sdks18:50
mhagedornkrames thanks for the email re:jenkins will read and ponder18:55
kramesmhagedorn sure!18:55
briancurtinfyi python-openstacksdk meeting in #openstack-meeting-3 in 5 minutes18:56
dtroyerI think it is time to re-visit the etherpad where a lot of this was laid out a while ago.20:02
jamielennoxwchrisj, dtroyer: i don't know how auth isn't considered part of that20:02
wchrisjI think the auth-token IS a part of session20:03
dtroyerauth is part of transport, but not what is called session here20:03
terrylhowethe current session is more of a transport to me, but I assumed it was going to become a session20:03
dtroyerjamielennox: if you owned the requests module and it was part of this project would you put the auth in there?20:03
terrylhoweby adding auth to it20:03
jamielennoxok, i get that i mixed my layers - or maybe my layer naming20:03
wchrisjI wouldnt20:04
jamielennoxdtroyer: possibly20:04
jamielennoxi understand keeping them conceptually different - but in reality these are all objects people need to pass around20:04
dtroyerI figured that.  ;)20:05
dtroyerits hard to see with none of the next layer up defined, I think the next layer is more like ksc's session with the auth and session as attributes20:05
jamielennoxsession needs to get certain things from auth, what is the alternative AuthedSession(session, auth) ?20:05
*** thurloat has quit IRC20:07
dtroyernaming is going to kill us20:07
dtroyerI should have called it barney20:07
wchrisjIn all seriousness, I think session should contain a few things: token (id + expiration), tenant/project info, user info, service catalog.20:08
wchrisjTHAT should get passed around.20:08
dtroyerso maybe I should get the glossary we started and the etherpad from a while back into shape and into the repo so we can use them as references?20:08
jamielennoxwchrisj: which session? because that is keystoneclient's session20:08
wchrisjGood call :-) jamielennox20:09
jamielennoxdtroyer: i think so, the problem is also how it relates to KSC and others because these are mostly components from there20:09
dtroyerI agree, we will have something like that, it should be the top of the 'transport' layer, and not be called session20:09
wchrisjI guess I'm struggling with having additional functionality inside session; maybe I'm wrong there...20:09
jamielennoxdtroyer: if you have something different i'd love to hear it because there is still time for me to rename it before i push it to the other clients20:09
jamielennox(rename in a backwards compatible way)20:10
wchrisjIt just feels odd to have the session actually doing stuff20:10
wchrisjthe session class/object20:10
dtroyermaby that's another word we should just not use because it is too overloaded?20:11
jamielennoxwchrisj: ok same question then, what do we call that next layer up that hanles auth and tokens and such20:11
*** thurloat has joined #openstack-sdks20:11
wchrisjone suggestion earlier was "context"...20:11
wchrisjnot sure about that20:11
dtroyerI like that but wasn't sure if that was meant for the really high-level stuff.  maybe it's the same?20:11
terrylhoweI always think of a context as something you pass a state machine20:12
jamielennoxwchrisj: maybe, feels weird to do things THROUGH a context20:12
wchrisjfeels better to do things against a context?20:12
wchrisjjamielennox ^^20:13
wchrisjor within a context?20:13
jamielennoxwchrisj: it's the same comment as terrylhowe, a context is something you pass20:13
jamielennoxa bunch of data that comes out from a library that is expected to be passed back in20:13
wchrisjyeah, exactly20:13
wchrisjI'm suggesting we not do anything THROUGH the context20:14
wchrisjit's purely information20:14
wchrisjjamielennox Is that too drastic a departure from existing idioms?20:15
jamielennoxwchrisj: just trying to digest what it would change20:16
jamielennoxso where is the entry point to making HTTP calls/20:17
jamielennoxif transport and auth are part of the context20:17
jamielennoxwhat do you ask to do a get()?20:17
jamielennoxsomething needs to combine those20:17
wchrisjwhat does the get look like at the layer you are describing?20:18
jamielennoxsession.get('/path/to', service_type='identity', interface='public')20:19
jamielennoxservice_type and interface are handled by the auth plugin20:19
jamielennoxactually it doesn't look like that anymore20:19
jamielennoxsession.get('/path/to', endpoint_filter={'service_type': 'identity', 'interface': 'public'})20:19
jamielennoxthat's what was making me think of context.get()20:21
jamielennoxotherwise you would still need a module level get(context, '/path/to', ...)20:21
wchrisjso are we talking about the get from the perspective of the Identity service, above the base layer in resource.py?20:22
*** mhagedorn has quit IRC20:22
jamielennoxumm, i use 'identity' by default in example as i know it best - but i think we are talking about anyone who wants to make a http call20:23
jamielennoxthe Resource.get_by_id etc can always be overloaded or people need to add new methods with their own resource specific calls20:24
wchrisjis the resource.py class the 'base' class that each service will depend on?20:24
jamielennoxeach resource from each class20:24
wchrisjresource  = identity/keystone, nova/compute, etc. ????20:25
jamielennoxbut having the resource object know how to disect a context to pull out the auth plugin and figure out the base url etc feels worse than combining it in session20:25
jamielennoxno, a resource is a User or a Group or a Project20:25
jamielennoxthere is no concept of service groupings at this point20:26
wchrisjahh, ok. d'oh20:26
wchrisjit's all identity here20:26
wchrisjbut the approach is generally applicable20:26
terrylhoweI think the keystone session pretty much has what we need, I just think things could be put in a couple related classes so there aren't so many moving parts20:26
jamielennoxterrylhowe: i have no problem doing that - or if you want to have a go yourself i'll review20:27
terrylhoweI don't have a specific plan just seems like20:28
jamielennoxSo i had always considered requests' Session to be the transport layer and keystoneclient's Session one above - which means i should have found a better name but i still don't know what it is20:29
jamielennoxthat's why you can pass a requests' Session to keystoneclient Session20:29
jamielennoxand that's one of the major diversions between my and dtroyer's session. His is a subclass, mine is a parameter20:30
terrylhoweit has an X-Auth-Token, so it must be a session20:30
terrylhoweObviously, when you first use one, you might not have one or some requests don't require one20:31
jamielennoxi don't follow20:32
terrylhoweYeh, I guess in the keystoneclient version, it would be better to call that parameter a transport20:32
wchrisjI actually prefer composing session (param) vs subclassing it FWIW jamielennox20:33
jamielennoxterrylhowe: indeed - i get sick of distinguishing between a keystoneclient.session and a requests.session20:33
terrylhowea bit confusing20:33
terrylhoweI kind of like the hasa over isa, but I could live either way20:33
jamielennoxwchrisj: me too - but in my case as i say i do it because i'm trying to be a layer above, that i then handle redirects there really blurs the lines20:34
wchrisjyeah, but it sets you up well if/when you dont have to handle those redirects. that's an ugliness associated with Requests20:34
wchrisjhate that20:35
wchrisjjamielennox - out of curiosity, do you think we should encapulate Requests somehow, and insulate the SDK from that ugliness? or is that your intent with session?20:36
wchrisjI think my issue is that session might be trying to be/do too much at present20:37
jamielennoxwchrisj: i'm not trying to hide requests, but you should never need to use it with Sesion20:39
dtroyerwchrisj: that is mostly what I was doing with the openstack.session.Session() class.  It does jamielennox's redirection handling, plus debug/logging and common JSON handling  It's named Session only because that's what requests named it.  I _really_ should have named it barney20:40
wchrisjI'm just thinking that my general approach when I have a component that isn't doing what it should do is to encapsulate it and insulate the rest of the project from that bad behavior.20:40
wchrisjdtroyer +1 for barney!!!20:41
dtroyerjamielennox's ks.session does a lot more, and we need that layer, but continuing to call it 'session' is madness.  that's why I wonder if we shouldn't rename both of them?20:41
wchrisjwould suit me just fine20:41
wchrisjeven if for a period of time just to let the functionality settle out20:42
wchrisjand that way we can call a shovel a shovel, and a hammer a hammer and everyone is clear20:42
dtroyerif we did, it would be permanent.  backward-comapt this early in a project is the devil's work20:42
wchrisjahh, good to know20:43
jamielennoxso maybe we look at our own Transport class20:43
jamielennoxwhich is what openstack.Session is now20:43
jamielennoxdefine an ABC that has one method .request()20:44
jamielennoxthe default implementation of that is a requests.Session object wrapped with some redirect handling logic20:44
jamielennoxor simply a requests.Session as it implements the same interface20:45
dtroyeropenstack.Session already does your redirection20:45
jamielennoxthen we remove the notion of passing requests arguments through - all parameters are defined by Transport20:45
jamielennox(though they will be remarkably similar to what requests uses)20:46
jamielennoxdtroyer: right, but i mean take most of that and call it Transport20:46
dtroyerI just proposed a basic glossary…when we get this figured out let's get the terminology in there so we can refer to it ;)20:47
dtroyerso openstack.Session -> openstack.Transport ?20:47
wchrisjThere is one in etherpad20:47
dtroyerand keystoneclient.Session -> openstack.Session ?20:47
jamielennoxthen we keep the name Session for something that operates with a transport object and an auth object that is passed around20:47
dtroyerwchrisj: I stole the easy ones from there20:47
wchrisjsounding better20:47
dtroyerto start20:47
terrylhowesounds good dtroyer20:48
jamielennoxso yes openstack.Session -> openstack.Transport20:48
jamielennoxkeystoneclient.Session is split into keystoneclient.Session and keystoneclient.Transport20:48
dtroyerok, I can live with that.20:48
jamielennoxhowever the public API for keystoneclient.Session won't really change20:48
wchrisjWould like to see it, but it sounds better20:49
jamielennoxbecause you can still call session.get() it just does some auth stuff and then redirects to transport.request()20:49
dtroyerI'll do a rename proposal tonight if I can stay awake long enough20:49
wchrisjdtroyer - rename in what project?20:49
wchrisjthis one or keystone?20:50
wchrisjand what is being renamed?20:50
jamielennoxat this point just Session -> Transport20:51
dtroyeropenstack.Session -> openstack.Transport20:51
jamielennoxthen we can build a Session object that handles auth on top20:51
dtroyerfeel free to −2 it if it says barney instead...20:51
wchrisj(sorry - newb question) is the rename proposal just a new patch set?20:51
jamielennoxOSI wise i still feel this is all transport layer and that we need to consider a presentation layer on top of (the new) Session20:52
dtroyerspecifically, a new review actually, not another patch set on a merged review20:52
dtroyerjamielennox: agreed:  https://etherpad.openstack.org/p/unified-sdk-notes20:52
dtroyertha'ts the next thing to get written up and into the repo oce a critical mass of folk agree20:53
jamielennoxthat's what i was trying to do with: https://review.openstack.org/#/c/86237/ - naming is a bitch though20:53
dtroyermyclient = openstack.bitch.RandomClassName(length=22)20:54
jamielennoxi like it20:54
jamielennoxi ended up with binding - but that is already a term used by keystone that i don't want to confuse20:55
dtroyerit has other meanings (sockets for one) that I tried to apply to it20:55
wchrisj"... there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."20:55
dtroyeractually, rms would say that is the correct count ;)20:56
wchrisjok, ok - I'll bite - what is rms?20:56
wchrisjor who?20:56
jamielennoxRichard Stallman20:56
dtroyerRichard Stallman, Mr GNU, who famously starts counting with zero20:57
jamielennoxno idea what the M stands for - or really want to know20:57
wchrisjgood to know20:57
dtroyeramongst other things he is famous^H^H^H^H^Hnotorious for20:57
dtroyerthe sad thing is when I go back to audio-land I have to remind myself what 'rms' really means...20:58
jamielennoxthe pool of available TLAs is becoming exhausted20:58
dtroyerTLAv6 will fix that20:59
terrylhoweI like the session as a layer, but I'm not 100% convinced presentation should be a layer in a strict OSI sense21:00
terrylhoweIt would probably at least be nice to have some sort of presentation class though21:01
jamielennoxok, for presentation (as in that review) what i'm thinking is the Accept header and some appropriate decoding based on that and parameters that are required for a lot of calls21:01
*** wchrisj_ has quit IRC21:01
jamielennoxso JSON presentation sets an accept and returns an object21:01
jamielennoxbut also there is a lot of stuff like service_type that is common to a big subsection of objects21:02
jamielennoxlike everything in identity needs to set service_type='identity'21:02
jamielennoxi am going to need that object for keystoneclient to make it easier to port other clients anyway21:02
jamielennoxi'm just trying to figure out if it makes sense here as well21:02
dtroyerdo you see using subclasses for those?21:03
dtroyeror just specialized facory methods?21:03
jamielennoxdtroyer: i was thinking a wrapper object21:04
jamielennox1:M session to presentation21:04
jamielennoxwchrisj: did you get approval for the summit?21:05
wchrisjyou bet21:05
dtroyerjust so you know, the most productive session at the summit is Friday night in the hotel bar…21:06
wchrisjafter the summit?21:06
jamielennoxdtroyer: by friday night of HK i was exhausted and struggling to keep everything in my head21:06
wchrisjbrain dead by that time21:06
dtroyerjamielennox: that's why we solved all of the world's problems there21:06
jamielennoxthat's true - everything get's boiled down to the simplest possible solution at that time21:07
terrylhoweI'm flying out Friday, I'll have to G+ in21:09
terrylhoweAnyway, I've got to run21:09
wchrisjlater terrylhowe21:10
jamielennoxterrylhowe: cya21:13
*** bknudson has quit IRC21:33
*** bknudson has joined #openstack-sdks21:37
*** mfer has quit IRC21:46
*** etoews has quit IRC22:35
*** bknudson has quit IRC22:41
dtroyerI've re-worked the Client Tools program proposal as OpenStackClient only for now as it looks like none of the SDK projects are far enough along to get TC approval.  But you may still be interested in the proposal as it is written with the adition of the SDK projects in mind: https://etherpad.openstack.org/p/client-program22:45
*** etoews has joined #openstack-sdks22:45
dtroyerFeedback welcome, specifically on the mission statement, description and deliverables.22:45
dtroyerI am including the SDK text here but it will be omitted in the final proposal.22:45
*** etoews has quit IRC22:50
*** etoews has joined #openstack-sdks23:19
*** openstackstatus has quit IRC23:32
*** openstackstatus has joined #openstack-sdks23:33
*** mordred has quit IRC23:58
*** mordred has joined #openstack-sdks23:58
*** ChanServ changes topic to "Restarting gerrit really quick to fix replication issue"23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!