| *** wchrisj has joined #openstack-sdks | 00:02 | |
| *** wchrisj has quit IRC | 00:10 | |
| *** mhagedorn has quit IRC | 00:21 | |
| *** etoews has quit IRC | 00:38 | |
| *** mhagedorn has joined #openstack-sdks | 00:46 | |
| *** mhagedorn has quit IRC | 00:51 | |
| *** mhagedorn has joined #openstack-sdks | 00:56 | |
| *** mhagedorn has quit IRC | 00:56 | |
| *** ekarlso has quit IRC | 01:11 | |
| *** ekarlso has joined #openstack-sdks | 01:13 | |
| *** ekarlso has quit IRC | 01:13 | |
| *** ekarlso has joined #openstack-sdks | 01:18 | |
| *** mhagedorn has joined #openstack-sdks | 01:53 | |
| *** wchrisj has joined #openstack-sdks | 03:55 | |
| *** etoews has joined #openstack-sdks | 04:03 | |
| *** etoews has quit IRC | 04:08 | |
| *** wchrisj has quit IRC | 04:11 | |
| *** mhagedorn has quit IRC | 04:43 | |
| *** jamielennox is now known as jamielennox|away | 06:07 | |
| *** etoews has joined #openstack-sdks | 06:08 | |
| *** etoews has quit IRC | 06:12 | |
| *** al_ex has joined #openstack-sdks | 06:46 | |
| *** etoews has joined #openstack-sdks | 07:09 | |
| *** etoews has quit IRC | 07:14 | |
| *** Alex_Gaynor has quit IRC | 08:32 | |
| *** Alex_Gaynor has joined #openstack-sdks | 08:37 | |
| *** etoews has joined #openstack-sdks | 09:11 | |
| *** etoews has quit IRC | 09:15 | |
| *** masahito has joined #openstack-sdks | 10:42 | |
| *** etoews has joined #openstack-sdks | 10:56 | |
| *** etoews has quit IRC | 11:00 | |
| *** etoews has joined #openstack-sdks | 11:57 | |
| *** etoews has quit IRC | 12:04 | |
| *** etoews has joined #openstack-sdks | 12:31 | |
| *** krames has joined #openstack-sdks | 12:37 | |
| *** Alex_Gaynor has quit IRC | 12:53 | |
| *** Alex_Gaynor has joined #openstack-sdks | 13:06 | |
| *** krames has quit IRC | 13:18 | |
| *** krames has joined #openstack-sdks | 13:18 | |
| *** mhagedorn has joined #openstack-sdks | 13:23 | |
| *** bknudson has joined #openstack-sdks | 13:26 | |
| *** mfer has joined #openstack-sdks | 13:35 | |
| *** wchrisj has joined #openstack-sdks | 13:59 | |
| elight | wchrisj mhagedorn krames: we should avoid doing this if at all possible in OSC: Going into town for | 14:10 |
|---|---|---|
| elight | Er... | 14:10 |
| elight | https://gist.github.com/elight/10735840 | 14:10 |
| elight | This will eat up more memory, by loading more classes and creating more methods, than are needed. | 14:11 |
| elight | Most users will only need one version of Identity and, probably, any given service. | 14:11 |
| mhagedorn | elight…dynamically? | 14:11 |
| elight | mhagedorn: Yeppers | 14:11 |
| elight | I’ll add that to ServiceDiscovery. | 14:11 |
| mhagedorn | elight +1 | 14:11 |
| wchrisj | Makes 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 |
| elight | Only noticed when I ran into trying to load my StorageV1 and found it wasn’t there yet. | 14:13 |
| wchrisj | aha | 14:14 |
| wchrisj | makes particular sense to do the requires inside of discovery | 14:14 |
| wchrisj | elight So what are your feelings of having to always set a version? ok with it? | 14:14 |
| wchrisj | more consistent to always do it | 14:15 |
| elight | It a nuisance with respect to Identity | 14:15 |
| wchrisj | yeah | 14:15 |
| elight | Because Identity is used by every other service | 14:15 |
| elight | Otherwise, yeah, I’d be fine with it | 14:15 |
| elight | I hate special cases... | 14:16 |
| wchrisj | me too | 14:16 |
| elight | Oooh using require_relative in the specs | 14:17 |
| elight | That’ll fail against 1.8.7 | 14:17 |
| wchrisj | yeah - we are aware of that ugliness | 14:18 |
| wchrisj | I didnt reallize when we started writing specs that that was an issue | 14:18 |
| wchrisj | havent cleaned it up yet | 14:18 |
| wchrisj | Mike and I are aware of it IOW... | 14:19 |
| elight | kk | 14:20 |
| *** dolphm is now known as dolphem | 14:31 | |
| *** mhagedorn has quit IRC | 14:32 | |
| *** mhagedorn has joined #openstack-sdks | 14:38 | |
| mhagedorn | elight can you repost that gist? colloquy shut down and lost all the context... | 14:47 |
| elight | https://gist.github.com/elight/10735840 | 14:48 |
| elight | irccloud is your friend | 14:48 |
| mhagedorn | elgith yeah ,yeah :) | 14:48 |
| mhagedorn | I am not supposed to eat donuts either | 14:48 |
| elight | Horse. Water. ‘buff said. ;-) ;-) | 14:49 |
| elight | nuff | 14:49 |
| elight | ack | 14:49 |
| mhagedorn | :) | 14:49 |
| mhagedorn | yeah crap.. doing the same silly move in hptng.. sigh | 14:49 |
| mhagedorn | elight… 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 latter | 14:52 |
| elight | Yep | 14:53 |
| elight | latter | 14:53 |
| elight | I’m working on it | 14:53 |
| elight | PR soon-ish | 14:53 |
| mhagedorn | kk | 14:53 |
| elight | Going to shake things up a little bit. Service versions seem to me like they should be akin to plugins: self-registering | 14:53 |
| elight | ServiceDiscovery ideally shouldn’t need all of this hard-coded information. | 14:53 |
| elight | Let the Service tell SD what it needs to know | 14:53 |
| elight | That way we centralize information about the service in… the service! | 14:54 |
| mhagedorn | elight 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 |
| mhagedorn | elight.. i.e. I let the Fog::Identity magic do the right thing | 15:07 |
| mhagedorn | elight your way is more performant however | 15:08 |
| mhagedorn | elight.. not sure what the higher good is on that point.. encapsulation of SD or raw performance…. not sure | 15:09 |
| *** mhagedorn has quit IRC | 15:28 | |
| *** mhagedorn_ has joined #openstack-sdks | 15:29 | |
| *** al_ex has quit IRC | 15:30 | |
| *** etoews_ has joined #openstack-sdks | 15:32 | |
| *** etoews has quit IRC | 15:35 | |
| elight | mhagedorn_: Encapsulating ServiceDiscovery? How do you hook into it then? We are dependent upon it still, right? | 15:37 |
| elight | mhagedorn_: If we’re dependent upon it, I like having the dependency be explicitly. | 15:37 |
| elight | explicit | 15:37 |
| elight | mhagedorn_ wchrisj krames; So here’s sort of what I’m thinking https://github.com/fog-openstack-tng/fog_openstack_tng/pull/22 | 15:38 |
| elight | mhagedorn_ wchrisj krames: Made several changes to make ServiceDiscovery more unit testable | 15:38 |
| briancurtin | been 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-sdks | 15:45 | |
| mhagedorn_ | elight.. for example https://gist.github.com/mwhagedorn/10743517 | 15:56 |
| mhagedorn_ | elight techinally the only dependency I am exposing is on Fog::OSC::Identity… leaving the mysteries of servicediscovery encapsulated | 15:57 |
| mhagedorn_ | elight mainly because I dont have to know about SD at this point | 15:58 |
| mhagedorn_ | but its open for discussion | 15:58 |
| elight | mhagedorn_: 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 |
| elight | mhagedorn_: That’s a mouthful | 16:07 |
| elight | mhagedorn_: Short version: using OSC::Identity doesn’t seem to add any benefit other than obscure the dependency on SD | 16:08 |
| elight | Because OSC::Identity just turns around and calls SD. | 16:08 |
| *** samchoi has joined #openstack-sdks | 16:08 | |
| mhagedorn_ | eliight.. its true but HpTng::Identity doesnt know or care ‘bout that | 16:09 |
| elight | mhagedorn_: 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 encapsulation | 16:10 |
| elight | mhagedorn_: 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 |
| elight | mhagedorn_: Honestly not thinking about performance. Thinking about number of dependencies. | 16:10 |
| elight | OSC::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 instantiated | 16:13 |
| mhagedorn_ | and… at this point at least HPTng only supports really one request... | 16:14 |
| mhagedorn_ | #create_token | 16:14 |
| elight | mhagedorn_: Sort of? ServiceDiscovery, from the outside, isn’t really the “how". That’s the implementation. | 16:14 |
| elight | mhagedorn_: 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/23 | 16:15 |
| elight | CC krames wchrisj ^^ | 16:15 |
| mhagedorn_ | elight… yeah honestly will know more when compute/swift start to get implemented for OSC | 16:16 |
| elight | That’s what I started doing. And it feels weird…. | 16:16 |
| mhagedorn_ | :) | 16:16 |
| elight | mhagedorn_: https://github.com/fog-openstack-tng/fog_openstack_tng/pull/23 >.< | 16:16 |
| mhagedorn_ | kewl | 16:17 |
| mhagedorn_ | will look at | 16:17 |
| elight | Really? 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-L43 | 16:17 |
| mhagedorn_ | elight… imagine you are gonna have to introspect service catalog on identity to get you CDN urls as well | 16:19 |
| mhagedorn_ | (not sure how rax does CDN, think hp does it differently) | 16:19 |
| krames | it looks good to me | 16:23 |
| krames | that example doesn't look at the endpoints though | 16:23 |
| krames | is that going to come later or am I missing something? | 16:23 |
| elight | krames: http://verysmartbrothas.com/images/Do-not-think-it-means.jpeg?c07647 | 16:24 |
| elight | ;-) | 16:24 |
| elight | krames: 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.. duh | 16:24 |
| krames | gotcha! | 16:24 |
| mhagedorn_ | brain is slow | 16:24 |
| elight | s/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 IRC | 16:41 | |
| mhagedorn_ | krames need to get your take today on setting up tests against production endpoints (aka not devstack).. for jenkins | 16:49 |
| *** Guest5337 is now known as sivel | 17:10 | |
| *** sivel has quit IRC | 17:10 | |
| *** sivel has joined #openstack-sdks | 17:10 | |
| *** etoews has joined #openstack-sdks | 17:13 | |
| *** etoews_ has quit IRC | 17:16 | |
| *** bknudson has joined #openstack-sdks | 17:27 | |
| *** bknudson has quit IRC | 17:32 | |
| *** bknudson has joined #openstack-sdks | 17:46 | |
| *** mfer has quit IRC | 17:51 | |
| *** mfer has joined #openstack-sdks | 17:51 | |
| wchrisj | elight 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 know | 17:55 |
| wchrisj | The language used above seemed to me to clearly indicate no need for the proxy class. elight krames mhagedorn | 17:56 |
| *** jamielennox|away is now known as jamielennox | 18:01 | |
| *** dolphem is now known as dolphm | 18:01 | |
| wchrisj | elight 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 SD | 18:03 |
| wchrisj | [12:08:12] <elight> Because OSC::Identity just turns around and calls SD. | 18:03 |
| wchrisj | elight I'm not agreeing/disagreeing - just trying to understand the intent... | 18:04 |
| *** krames has quit IRC | 18:08 | |
| *** krames has joined #openstack-sdks | 18:09 | |
| *** mhagedorn_ has quit IRC | 18:18 | |
| krames | mhagedorn_ I sent you an email about jenkins | 18:19 |
| wchrisj | elight 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-sdks | 18:19 | |
| krames | me too | 18:19 |
| wchrisj | w00t | 18:19 |
| wchrisj | given our vendor extensions, that makes perfect sense. | 18:20 |
| krames | wchrisj is the name of the gem going to be fog-openstack-core ? | 18:20 |
| wchrisj | I would assume so krames; it follows convention. | 18:20 |
| wchrisj | We need to pick a timeframe and get the name sync'd up internally. | 18:23 |
| wchrisj | elight krames mhagedorn ^^ | 18:23 |
| wchrisj | I can open a PR to get that done quick enough | 18:23 |
| krames | k | 18:24 |
| wchrisj | krames elight mhagedorn Done - https://github.com/fog/fog-openstack-core/pull/24 | 18:42 |
| wchrisj | tests pass | 18:42 |
| wchrisj | May as well get on this train ASAP | 18:43 |
| wchrisj | ;-) | 18:43 |
| krames | wchrisj I don't know if he told you, but elight is taking a half day today | 18:44 |
| wchrisj | krames Thanks - did not know that. | 18:45 |
| *** wchrisj_ has joined #openstack-sdks | 18:50 | |
| mhagedorn | krames thanks for the email re:jenkins will read and ponder | 18:55 |
| krames | mhagedorn sure! | 18:55 |
| briancurtin | fyi python-openstacksdk meeting in #openstack-meeting-3 in 5 minutes | 18:56 |
| dtroyer | I think it is time to re-visit the etherpad where a lot of this was laid out a while ago. | 20:02 |
| jamielennox | wchrisj, dtroyer: i don't know how auth isn't considered part of that | 20:02 |
| wchrisj | I think the auth-token IS a part of session | 20:03 |
| dtroyer | auth is part of transport, but not what is called session here | 20:03 |
| terrylhowe | the current session is more of a transport to me, but I assumed it was going to become a session | 20:03 |
| dtroyer | jamielennox: if you owned the requests module and it was part of this project would you put the auth in there? | 20:03 |
| terrylhowe | by adding auth to it | 20:03 |
| jamielennox | ok, i get that i mixed my layers - or maybe my layer naming | 20:03 |
| wchrisj | no | 20:03 |
| wchrisj | I wouldnt | 20:04 |
| jamielennox | dtroyer: possibly | 20:04 |
| jamielennox | i understand keeping them conceptually different - but in reality these are all objects people need to pass around | 20:04 |
| dtroyer | I figured that. ;) | 20:05 |
| dtroyer | its 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 attributes | 20:05 |
| jamielennox | session needs to get certain things from auth, what is the alternative AuthedSession(session, auth) ? | 20:05 |
| *** thurloat has quit IRC | 20:07 | |
| dtroyer | naming is going to kill us | 20:07 |
| jamielennox | yea | 20:07 |
| dtroyer | I should have called it barney | 20:07 |
| wchrisj | In all seriousness, I think session should contain a few things: token (id + expiration), tenant/project info, user info, service catalog. | 20:08 |
| wchrisj | THAT should get passed around. | 20:08 |
| dtroyer | so 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 |
| jamielennox | wchrisj: which session? because that is keystoneclient's session | 20:08 |
| wchrisj | Good call :-) jamielennox | 20:09 |
| jamielennox | dtroyer: i think so, the problem is also how it relates to KSC and others because these are mostly components from there | 20:09 |
| dtroyer | I agree, we will have something like that, it should be the top of the 'transport' layer, and not be called session | 20:09 |
| wchrisj | I guess I'm struggling with having additional functionality inside session; maybe I'm wrong there... | 20:09 |
| jamielennox | dtroyer: 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 clients | 20:09 |
| jamielennox | (rename in a backwards compatible way) | 20:10 |
| wchrisj | It just feels odd to have the session actually doing stuff | 20:10 |
| wchrisj | the session class/object | 20:10 |
| dtroyer | maby that's another word we should just not use because it is too overloaded? | 20:11 |
| jamielennox | wchrisj: ok same question then, what do we call that next layer up that hanles auth and tokens and such | 20:11 |
| *** thurloat has joined #openstack-sdks | 20:11 | |
| wchrisj | one suggestion earlier was "context"... | 20:11 |
| wchrisj | not sure about that | 20:11 |
| dtroyer | I like that but wasn't sure if that was meant for the really high-level stuff. maybe it's the same? | 20:11 |
| terrylhowe | I always think of a context as something you pass a state machine | 20:12 |
| jamielennox | wchrisj: maybe, feels weird to do things THROUGH a context | 20:12 |
| wchrisj | feels better to do things against a context? | 20:12 |
| wchrisj | jamielennox ^^ | 20:13 |
| wchrisj | or within a context? | 20:13 |
| jamielennox | wchrisj: it's the same comment as terrylhowe, a context is something you pass | 20:13 |
| jamielennox | a bunch of data that comes out from a library that is expected to be passed back in | 20:13 |
| wchrisj | yeah, exactly | 20:13 |
| wchrisj | I'm suggesting we not do anything THROUGH the context | 20:14 |
| wchrisj | it's purely information | 20:14 |
| wchrisj | jamielennox Is that too drastic a departure from existing idioms? | 20:15 |
| jamielennox | wchrisj: just trying to digest what it would change | 20:16 |
| wchrisj | ok | 20:16 |
| jamielennox | so where is the entry point to making HTTP calls/ | 20:17 |
| jamielennox | if transport and auth are part of the context | 20:17 |
| jamielennox | what do you ask to do a get()? | 20:17 |
| jamielennox | something needs to combine those | 20:17 |
| wchrisj | what does the get look like at the layer you are describing? | 20:18 |
| jamielennox | session.get('/path/to', service_type='identity', interface='public') | 20:19 |
| jamielennox | service_type and interface are handled by the auth plugin | 20:19 |
| jamielennox | actually it doesn't look like that anymore | 20:19 |
| jamielennox | session.get('/path/to', endpoint_filter={'service_type': 'identity', 'interface': 'public'}) | 20:19 |
| jamielennox | that's what was making me think of context.get() | 20:21 |
| jamielennox | otherwise you would still need a module level get(context, '/path/to', ...) | 20:21 |
| wchrisj | so 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 IRC | 20:22 | |
| jamielennox | umm, 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 call | 20:23 |
| jamielennox | the Resource.get_by_id etc can always be overloaded or people need to add new methods with their own resource specific calls | 20:24 |
| wchrisj | is the resource.py class the 'base' class that each service will depend on? | 20:24 |
| jamielennox | each resource from each class | 20:24 |
| wchrisj | resource = identity/keystone, nova/compute, etc. ???? | 20:25 |
| jamielennox | but 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 session | 20:25 |
| jamielennox | no, a resource is a User or a Group or a Project | 20:25 |
| jamielennox | there is no concept of service groupings at this point | 20:26 |
| wchrisj | ahh, ok. d'oh | 20:26 |
| wchrisj | it's all identity here | 20:26 |
| wchrisj | but the approach is generally applicable | 20:26 |
| wchrisj | understood | 20:26 |
| terrylhowe | I 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 parts | 20:26 |
| jamielennox | terrylhowe: i have no problem doing that - or if you want to have a go yourself i'll review | 20:27 |
| terrylhowe | I don't have a specific plan just seems like | 20:28 |
| jamielennox | So 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 is | 20:29 |
| jamielennox | that's why you can pass a requests' Session to keystoneclient Session | 20:29 |
| jamielennox | and that's one of the major diversions between my and dtroyer's session. His is a subclass, mine is a parameter | 20:30 |
| terrylhowe | it has an X-Auth-Token, so it must be a session | 20:30 |
| terrylhowe | Obviously, when you first use one, you might not have one or some requests don't require one | 20:31 |
| jamielennox | i don't follow | 20:32 |
| terrylhowe | Yeh, I guess in the keystoneclient version, it would be better to call that parameter a transport | 20:32 |
| wchrisj | I actually prefer composing session (param) vs subclassing it FWIW jamielennox | 20:33 |
| jamielennox | terrylhowe: indeed - i get sick of distinguishing between a keystoneclient.session and a requests.session | 20:33 |
| terrylhowe | a bit confusing | 20:33 |
| terrylhowe | I kind of like the hasa over isa, but I could live either way | 20:33 |
| jamielennox | wchrisj: 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 lines | 20:34 |
| wchrisj | yeah, but it sets you up well if/when you dont have to handle those redirects. that's an ugliness associated with Requests | 20:34 |
| wchrisj | hate that | 20:35 |
| wchrisj | jamielennox - 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 |
| wchrisj | I think my issue is that session might be trying to be/do too much at present | 20:37 |
| jamielennox | wchrisj: i'm not trying to hide requests, but you should never need to use it with Sesion | 20:39 |
| wchrisj | ok | 20:39 |
| dtroyer | wchrisj: 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 barney | 20:40 |
| wchrisj | I'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 |
| wchrisj | dtroyer +1 for barney!!! | 20:41 |
| dtroyer | jamielennox'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 |
| wchrisj | would suit me just fine | 20:41 |
| wchrisj | even if for a period of time just to let the functionality settle out | 20:42 |
| wchrisj | and that way we can call a shovel a shovel, and a hammer a hammer and everyone is clear | 20:42 |
| dtroyer | if we did, it would be permanent. backward-comapt this early in a project is the devil's work | 20:42 |
| wchrisj | ahh, good to know | 20:43 |
| jamielennox | so maybe we look at our own Transport class | 20:43 |
| jamielennox | which is what openstack.Session is now | 20:43 |
| jamielennox | define an ABC that has one method .request() | 20:44 |
| jamielennox | the default implementation of that is a requests.Session object wrapped with some redirect handling logic | 20:44 |
| jamielennox | or simply a requests.Session as it implements the same interface | 20:45 |
| dtroyer | openstack.Session already does your redirection | 20:45 |
| jamielennox | then we remove the notion of passing requests arguments through - all parameters are defined by Transport | 20:45 |
| jamielennox | (though they will be remarkably similar to what requests uses) | 20:46 |
| jamielennox | dtroyer: right, but i mean take most of that and call it Transport | 20:46 |
| dtroyer | I 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 |
| wchrisj | +1 | 20:47 |
| dtroyer | so openstack.Session -> openstack.Transport ? | 20:47 |
| wchrisj | There is one in etherpad | 20:47 |
| dtroyer | and keystoneclient.Session -> openstack.Session ? | 20:47 |
| jamielennox | then we keep the name Session for something that operates with a transport object and an auth object that is passed around | 20:47 |
| dtroyer | wchrisj: I stole the easy ones from there | 20:47 |
| wchrisj | sounding better | 20:47 |
| dtroyer | to start | 20:47 |
| wchrisj | :-) | 20:47 |
| terrylhowe | sounds good dtroyer | 20:48 |
| jamielennox | so yes openstack.Session -> openstack.Transport | 20:48 |
| jamielennox | keystoneclient.Session is split into keystoneclient.Session and keystoneclient.Transport | 20:48 |
| dtroyer | ok, I can live with that. | 20:48 |
| jamielennox | however the public API for keystoneclient.Session won't really change | 20:48 |
| wchrisj | Would like to see it, but it sounds better | 20:49 |
| jamielennox | because you can still call session.get() it just does some auth stuff and then redirects to transport.request() | 20:49 |
| dtroyer | I'll do a rename proposal tonight if I can stay awake long enough | 20:49 |
| wchrisj | lol | 20:49 |
| wchrisj | dtroyer - rename in what project? | 20:49 |
| wchrisj | this one or keystone? | 20:50 |
| dtroyer | sdk | 20:50 |
| wchrisj | and what is being renamed? | 20:50 |
| wchrisj | session? | 20:51 |
| jamielennox | at this point just Session -> Transport | 20:51 |
| dtroyer | openstack.Session -> openstack.Transport | 20:51 |
| wchrisj | ok | 20:51 |
| jamielennox | then we can build a Session object that handles auth on top | 20:51 |
| dtroyer | feel 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 |
| dtroyer | yes | 20:52 |
| wchrisj | ok | 20:52 |
| jamielennox | OSI wise i still feel this is all transport layer and that we need to consider a presentation layer on top of (the new) Session | 20:52 |
| dtroyer | specifically, a new review actually, not another patch set on a merged review | 20:52 |
| wchrisj | GTK | 20:52 |
| dtroyer | jamielennox: agreed: https://etherpad.openstack.org/p/unified-sdk-notes | 20:52 |
| dtroyer | tha'ts the next thing to get written up and into the repo oce a critical mass of folk agree | 20:53 |
| jamielennox | that's what i was trying to do with: https://review.openstack.org/#/c/86237/ - naming is a bitch though | 20:53 |
| dtroyer | myclient = openstack.bitch.RandomClassName(length=22) | 20:54 |
| wchrisj | lolol | 20:54 |
| jamielennox | i like it | 20:54 |
| jamielennox | i ended up with binding - but that is already a term used by keystone that i don't want to confuse | 20:55 |
| dtroyer | it has other meanings (sockets for one) that I tried to apply to it | 20:55 |
| wchrisj | "... there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." | 20:55 |
| dtroyer | actually, rms would say that is the correct count ;) | 20:56 |
| jamielennox | lol | 20:56 |
| wchrisj | ok, ok - I'll bite - what is rms? | 20:56 |
| wchrisj | or who? | 20:56 |
| jamielennox | Richard Stallman | 20:56 |
| wchrisj | aha | 20:57 |
| dtroyer | Richard Stallman, Mr GNU, who famously starts counting with zero | 20:57 |
| jamielennox | no idea what the M stands for - or really want to know | 20:57 |
| wchrisj | good to know | 20:57 |
| dtroyer | amongst other things he is famous^H^H^H^H^Hnotorious for | 20:57 |
| dtroyer | the sad thing is when I go back to audio-land I have to remind myself what 'rms' really means... | 20:58 |
| jamielennox | the pool of available TLAs is becoming exhausted | 20:58 |
| dtroyer | TLAv6 will fix that | 20:59 |
| jamielennox | hahaha | 20:59 |
| terrylhowe | I like the session as a layer, but I'm not 100% convinced presentation should be a layer in a strict OSI sense | 21:00 |
| terrylhowe | It would probably at least be nice to have some sort of presentation class though | 21:01 |
| jamielennox | ok, 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 calls | 21:01 |
| *** wchrisj_ has quit IRC | 21:01 | |
| terrylhowe | yeh | 21:01 |
| jamielennox | so JSON presentation sets an accept and returns an object | 21:01 |
| wchrisj | agreed | 21:02 |
| jamielennox | but also there is a lot of stuff like service_type that is common to a big subsection of objects | 21:02 |
| jamielennox | like everything in identity needs to set service_type='identity' | 21:02 |
| jamielennox | i am going to need that object for keystoneclient to make it easier to port other clients anyway | 21:02 |
| jamielennox | i'm just trying to figure out if it makes sense here as well | 21:02 |
| dtroyer | do you see using subclasses for those? | 21:03 |
| dtroyer | or just specialized facory methods? | 21:03 |
| jamielennox | dtroyer: i was thinking a wrapper object | 21:04 |
| jamielennox | 1:M session to presentation | 21:04 |
| jamielennox | wchrisj: did you get approval for the summit? | 21:05 |
| wchrisj | yep! | 21:05 |
| jamielennox | excellent | 21:05 |
| wchrisj | you bet | 21:05 |
| dtroyer | just so you know, the most productive session at the summit is Friday night in the hotel bar… | 21:06 |
| wchrisj | ha! | 21:06 |
| wchrisj | after the summit? | 21:06 |
| jamielennox | dtroyer: by friday night of HK i was exhausted and struggling to keep everything in my head | 21:06 |
| wchrisj | brain dead by that time | 21:06 |
| dtroyer | jamielennox: that's why we solved all of the world's problems there | 21:06 |
| jamielennox | that's true - everything get's boiled down to the simplest possible solution at that time | 21:07 |
| terrylhowe | I'm flying out Friday, I'll have to G+ in | 21:09 |
| terrylhowe | Anyway, I've got to run | 21:09 |
| wchrisj | later terrylhowe | 21:10 |
| jamielennox | terrylhowe: cya | 21:13 |
| *** bknudson has quit IRC | 21:33 | |
| *** bknudson has joined #openstack-sdks | 21:37 | |
| *** mfer has quit IRC | 21:46 | |
| *** etoews has quit IRC | 22:35 | |
| *** bknudson has quit IRC | 22:41 | |
| dtroyer | I'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-program | 22:45 |
| *** etoews has joined #openstack-sdks | 22:45 | |
| dtroyer | Feedback welcome, specifically on the mission statement, description and deliverables. | 22:45 |
| dtroyer | I am including the SDK text here but it will be omitted in the final proposal. | 22:45 |
| *** etoews has quit IRC | 22:50 | |
| *** etoews has joined #openstack-sdks | 23:19 | |
| *** openstackstatus has quit IRC | 23:32 | |
| *** openstackstatus has joined #openstack-sdks | 23:33 | |
| *** mordred has quit IRC | 23:58 | |
| *** mordred has joined #openstack-sdks | 23: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!
