Tuesday, 2014-05-06

*** TravT has quit IRC00:27
*** etoews has joined #openstack-sdks01:11
*** wchrisj has quit IRC01:57
openstackgerritShaunak Kashyap proposed a change to stackforge/openstack-sdk-php: Initial directory structure, config and build instructions.  https://review.openstack.org/9228002:17
*** TravT has joined #openstack-sdks03:29
*** wchrisj has joined #openstack-sdks04:23
*** wchrisj has quit IRC04:36
*** wchrisj has joined #openstack-sdks04:39
*** samchoi has quit IRC06:02
*** stevemar has quit IRC06:49
*** jamielennox is now known as jamielennox|away07:29
*** TravT has quit IRC09:17
*** etoews has quit IRC11:01
*** etoews has joined #openstack-sdks11:02
*** etoews_ has joined #openstack-sdks11:47
*** etoews has quit IRC11:49
*** etoews_ has quit IRC12:16
*** jamie_h has joined #openstack-sdks12:17
*** etoews has joined #openstack-sdks12:25
*** terrylhowe has left #openstack-sdks12:58
openstackgerritShaunak Kashyap proposed a change to stackforge/openstack-sdk-php: Initial directory structure, config and build instructions.  https://review.openstack.org/9228013:13
*** bknudson has quit IRC13:23
*** bknudson has joined #openstack-sdks13:46
*** etoews has quit IRC13:47
*** wchrisj has joined #openstack-sdks13:50
*** TravT has joined #openstack-sdks14:32
*** terrylhowe has joined #openstack-sdks14:33
*** stevemar has joined #openstack-sdks14:35
*** mhagedorn has quit IRC15:07
*** mhagedorn has joined #openstack-sdks15:08
*** mhagedorn has quit IRC15:10
*** stevemar has quit IRC16:20
*** stevemar has joined #openstack-sdks16:20
wchrisjelight: Do we want to merge the initial compute PR, or wait and refactor to take into the account the change you made to fog-core?16:28
wchrisjelight: we could probably just refer to the branch in fog-core as a stopgap solution if necessary...16:29
elightwchrisj: I’d suggest using the prefix_path stuff immediately.16:29
elightwchrisj: It hasn’t been merged yet?  I haven’t checked but krames gave it a thumbs up.16:29
wchrisjelight: ok16:29
wchrisjdont think so16:30
elightI’m going to go ahead and merge it. The bug is on Travis’ side.16:30
elightwchrisj: I hadn’t forgotten about the gist. been pulled two different ways since getting started today.16:30
elightwchrisj: the simple and not pretty version: https://gist.github.com/elight/bf36c28188fdedbcb5f116:30
wchrisjelight - understood16:30
elightwchrisj: I didn’t rename anything. I made the module instance methods into module methods and invoked them from an example request.16:31
elightwchrisj: If we went this route, clearly we’d want to rename things because RequestCommon.base_request just reads oddly.16:31
wchrisjelight - so we are completely decoupling the request from the service?16:31
elightwchrisj: Also would be reasonable to move admin_request into the same module, I believe.16:31
elightwchrisj: This is what I was thinking about. As I said yesterday, this may be too extreme.16:32
elightwchrisj: But… well… maybe not. ;-)16:32
elightwchrisj: Services already do too damn much16:32
wchrisjelight: I'll take a look; seems the service has some knowledge that would be useful and DRYer to utilize... lemme look at it16:32
elightYeah exactly16:32
wchrisjI agree with the assessment re: Services16:32
elightService has too many responsibilities already. Let someone else worry about how to send requests to our OpenStack back ends.16:33
elightwchrisj: feels like the kind of refactoring where RubyMine could be useful. It’d be a minor nuisance to do it in emacs or vim.16:33
wchrisjelight I tend to prefer manually... rubymine is TERRIFIC when a debugger is useful; outside of that, not so much IMO16:35
elightwchrisj: I have too many people tell me how great IDEs are for refactoring. I’m accustomed to recursive search and replaces. ;-)16:36
wchrisjelight: me too ;-)   maybe old school ISNT always better...16:37
wchrisjelight: So your way will necessitate each request to "know" about the underlying connection ivar... you ok with that?16:40
wchrisj@connection16:40
wchrisjelight: feels dirty to me16:40
wchrisjelight: maybe not16:40
elightI don’t see that. The only ivar is auth_token16:41
elightThat shouldn’t be owned by the service either.16:41
elightSo, yeah, there’s more to untangling this than I initially suspected. And I’m not surprised16:41
wchrisjelight: "def self.base_request(service, params)"16:41
elightwchrisj: One benefit to this kind of refactoring is it lays bare all of the behavior’s dependencies.16:41
wchrisjthe request will have to pass it16:41
wchrisjyes16:41
elightwchrisj: I have an idea….16:42
elightwchrisj: This might finally be the time for an OSC::Connection16:42
wchrisjelight - move the connection into the service request?16:42
elightHmmm...16:43
wchrisjelight - the service is already setting that up16:43
wchrisjwhat is the role of the service then? elight:16:43
elightwchrisj: The service is a mediator (http://en.wikipedia.org/wiki/Mediator_pattern)16:44
elightor should be16:44
elightbut it’s a mediator that does more than just mediate right now16:44
wchrisjelight: we will have a connection for each service...16:44
wchrisjunique16:44
wchrisjelight "but it’s a mediator that does more than just mediate right now" - agreed16:46
elighteach service already has a connection16:46
wchrisjelight - ultimately, all the request stuff for each service should be self contained16:46
elightdoesn’t seem like a stretch to create a Fog::Core::Connection wrapper class that adds our base_request and admin_request behaviors, does it?16:46
elightnot necessarily a subclass though perhaps.16:47
wchrisjelight - not sure if here is the place to put that stake in the ground tho16:47
elightthat this should be pervasive in fog? At least the rackspace/openstack/hp providers all define a #request method16:47
elightper service16:47
wchrisjwhat I was trying to say was one thought elight16:48
elightAnd, yup, so does AWS compute16:48
wchrisjwould like to constrain all the request stuff for each service in its own layer/module/etc. versus being mixed into the service16:49
wchrisjelight ^^16:49
elightyes16:49
elightthis was my motivation16:49
wchrisjelight one more thing the service doesnt need resp for16:49
wchrisjelight But that's a significant arch change16:49
elightit is if we carry it beyond OSC16:49
wchrisjand not sure this is the time/place before the summit elight:16:49
elightHeh16:50
elightwchrisj: I’m still not sure that before the summit was the right time for OSC!16:50
wchrisjelight maybe16:50
wchrisjhaha16:50
wchrisjgood point - but I think it was elight16:50
wchrisjwe've made good progress and cleaned up a lot16:51
wchrisjelight do you think we can make this change (mixin -> module) and leave requests where they are at ATM?16:52
wchrisjelight ... mixed into the service...16:52
elightI don’t see the point.16:53
elightIt’s ok. This doesn’t have to happen now.16:53
elightBesides, I will be out of town for much of next week.16:53
wchrisjme too16:53
elightSo I wouldn’t be in a good position to work on it16:53
elightOk16:53
elightThen Summit16:53
elightSo I say let’s let it go for now16:53
wchrisjand just merge what we have, just make sure it is based on the new change in core? elight:16:54
elightyeah16:54
wchrisjok16:54
elightwchrisj: Travis just went all green16:54
elightwchrisj: I merged prefix_path16:54
wchrisjsweet16:54
*** TravT has quit IRC16:55
wchrisjelight: so until Wes cuts a new gem, we need to ref github, correct?16:55
elightyep16:55
wchrisjok16:55
wchrisjelight: So in Compute, I would specify Fog::Core::Connection.new("http://172.16.0.2:58587", false, :path_prefix => "v2/<tenantid>")  ?????17:08
wchrisjelight: I know the port# is wrong17:08
wchrisjelight: So is "path_prefix" merged with "connection_options", the params hash/3rd arg?17:09
elightwchrisj: That’s how it ought to work, yeah17:14
wchrisjelight: My last comment on this (I promise) is that I still strongly feel that given all the services we are called to support, and the disparate ways they do things, that this isnt nearly as clear as base_url + full path to the resource in the request.17:15
wchrisjelight moving forward...17:16
wchrisjelight: any opposition to another friday meeting this week? I had something come up tomorrow offsite (school related); if not, you guys can meet w/o me...17:21
elightFriday morning suits me fine.17:25
elight^^ wchrisj17:25
briancurtinis anyone in the python-openstacksdk familiar with how coverage  is run? I'm trying to figure out why it's trying to import "openstacksdk", which isn't a thing, and then coverage succeeds with nothing to report17:39
*** wchrisj has quit IRC17:42
briancurtinthat name only seems to exist in the repo as "python-openstacksdk", so i'm not seeing how it's discovering that or how it's configured or anything else. kind of weird17:43
* briancurtin reads https://testrepository.readthedocs.org/en/latest/17:43
*** jamie_h has quit IRC17:44
*** jamielennox|away is now known as jamielennox18:05
*** wchrisj has joined #openstack-sdks18:27
wchrisjelight: https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric18:41
briancurtinpython-openstacksdk meeting over in #openstack-meeting-3 in 5 min - agenda at https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-05-06_1900_UTC18:55
*** wchrisj_ has joined #openstack-sdks19:06
briancurtinterrylhowe: you around for the meeting?19:07
terrylhowejust got back19:08
briancurtinterrylhowe: we're currently talking about https://review.openstack.org/#/c/90301/ -- (had just started to talk about your "example code for presentation" but jumped back)19:10
*** electrichead_ has joined #openstack-sdks19:16
jamielennoxterrylhowe: i've been wanting to fix up service catalog and accessinfo for a long time so i'm happy to do those after it's commited20:01
terrylhoweokay, great20:01
terrylhoweI started out changing things and it just seemed best at first to leave as much as is20:02
terrylhoweI'm still working on some more tests I want to add to get better coverage, but there have been distractions lately20:02
jamielennoxterrylhowe: i think i mentioned previously though - the only thing i've found that the auth plugin structure has trouble with is forcing it to reauthenticate20:07
jamielennoxyou do get_token() use the token and then get back a 401 error20:07
jamielennoxyou've got no way to say to the plugins that you should invalidate your cache20:08
jamielennoxthere are a number of ways i can see to do it, either with an invalidate() method or a get_token(reauth=Ttrue) but neither of them are as clean as i was hoping for20:09
terrylhoweI'll have to mess with it, it looked like it should all work20:11
*** mhagedorn has joined #openstack-sdks20:13
jamielennoxterrylhowe: it's a requirement i have for auth_token middleware, i'd just like to make sure that we arrive at the same solution20:13
terrylhoweyeh, more motivation to minimize changes20:14
jamielennoxterrylhowe: and i'm taking this as an opportunity to define a fresh baase client layer that i would eventually hope could be pulled out and used by other clients20:16
jamielennoxas in i'd love to do a keystonclient v2.0 but it makes sense to try and reuse a pattern that exists20:17
elight wchrisj wchrisj_ yep saw it last week20:17
*** terrylhowe has quit IRC20:47
*** bknudson has quit IRC20:48
*** bknudson has joined #openstack-sdks20:49
*** terrylhowe has joined #openstack-sdks20:49
wchrisjelight: krames: mhagedorn: - last call for the compute PR before I merge it...21:08
mhagedorngo wchrisj go   code like the wind21:09
*** stevemar has quit IRC21:25
*** redrobot has quit IRC21:55
*** electrichead_ has quit IRC21:58
*** wchrisj has quit IRC22:07
*** bknudson has quit IRC22:25
*** mhagedorn has quit IRC22:30
jamielennoxdtroyer: marconi just release a client 0.0.1 https://github.com/openstack/python-marconiclient22:33
dtroyerI saw that…haven't looked yet to see which other one it was based on...22:34
jamielennoxon the up side it's another person who has independantly stumbled on the same design of seperating transport, auth and ditching managers22:34
*** mhagedorn has joined #openstack-sdks22:34
jamielennoxdtroyer: it looks like it's from scratch22:34
dtroyerreally?  well, we need to have a closer look22:34
*** TravT has joined #openstack-sdks22:36
*** TravT has quit IRC22:36
*** redrobot has joined #openstack-sdks22:36
*** redrobot is now known as Guest4952522:36
*** Guest49525 is now known as electrichead22:37
terrylhowehas a kind of message model with those request/response classes22:38
jamielennoxterrylhowe: yea, i'm not sure why they do that rather than just use requests22:39
jamielennoxbecause it doesn't appear like the request objects should be public22:39
terrylhowecreates a lot of interdependencies22:40
jamielennoxterrylhowe: ?22:40
jamielennoxdepending on requests?22:40
terrylhowewell, that message class is all over is all22:40
jamielennoxi considered abstracting requests so that it was never exported such that you could replace requests with something else - but i don't know what else22:41
terrylhoweit would be tough to integrate into OSC for one thing22:41
jamielennoxthe only reason i would like to replace requests is to do things like OCSP and such22:41
jamielennoxterrylhowe: i don't think so, Request appears to be purely an internal abstraction, it still returns objects22:42
jamielennoxi have an OSC plugin for another client that works in a similar Resource orientated way and it's fine22:42
terrylhowemaybe.  I was just thinking OSC would have to call these methods and pass a message, but maybe they could be treated as private22:45
terrylhoweoh right, the message on queue is a resource, duh.  I thought it was a base class for the lower level request/response22:46
jamielennoxi don't think so https://github.com/openstack/python-marconiclient/blob/master/marconiclient/queues/v1/client.py shows the entry points22:47
terrylhowecool, yeh22:48
terrylhoweI heard they weren't using rabbitmq as a backend though, something slower22:48
terrylhoweI haven't been paying much attention though22:48
jamielennoxterrylhowe: yea, my understanding is that it's not that low level22:49
jamielennoxit's essentially a REST-ful pub/sub rather than actually messaging22:50
elightwchrisj_: Do we need a meeting Friday? mhagedorn doesn’t see the need. I don’t see anything we need to discuss. It’d be a shame to have a meeting just to have a meeting.22:54
*** electrichead is now known as redrobot_22:57
*** redrobot_ is now known as redrobot23:20
*** mhagedorn has quit IRC23:20
*** bknudson has joined #openstack-sdks23:40
*** bknudson has left #openstack-sdks23:42

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