*** TravT has quit IRC | 00:27 | |
*** etoews has joined #openstack-sdks | 01:11 | |
*** wchrisj has quit IRC | 01:57 | |
openstackgerrit | Shaunak Kashyap proposed a change to stackforge/openstack-sdk-php: Initial directory structure, config and build instructions. https://review.openstack.org/92280 | 02:17 |
---|---|---|
*** TravT has joined #openstack-sdks | 03:29 | |
*** wchrisj has joined #openstack-sdks | 04:23 | |
*** wchrisj has quit IRC | 04:36 | |
*** wchrisj has joined #openstack-sdks | 04:39 | |
*** samchoi has quit IRC | 06:02 | |
*** stevemar has quit IRC | 06:49 | |
*** jamielennox is now known as jamielennox|away | 07:29 | |
*** TravT has quit IRC | 09:17 | |
*** etoews has quit IRC | 11:01 | |
*** etoews has joined #openstack-sdks | 11:02 | |
*** etoews_ has joined #openstack-sdks | 11:47 | |
*** etoews has quit IRC | 11:49 | |
*** etoews_ has quit IRC | 12:16 | |
*** jamie_h has joined #openstack-sdks | 12:17 | |
*** etoews has joined #openstack-sdks | 12:25 | |
*** terrylhowe has left #openstack-sdks | 12:58 | |
openstackgerrit | Shaunak Kashyap proposed a change to stackforge/openstack-sdk-php: Initial directory structure, config and build instructions. https://review.openstack.org/92280 | 13:13 |
*** bknudson has quit IRC | 13:23 | |
*** bknudson has joined #openstack-sdks | 13:46 | |
*** etoews has quit IRC | 13:47 | |
*** wchrisj has joined #openstack-sdks | 13:50 | |
*** TravT has joined #openstack-sdks | 14:32 | |
*** terrylhowe has joined #openstack-sdks | 14:33 | |
*** stevemar has joined #openstack-sdks | 14:35 | |
*** mhagedorn has quit IRC | 15:07 | |
*** mhagedorn has joined #openstack-sdks | 15:08 | |
*** mhagedorn has quit IRC | 15:10 | |
*** stevemar has quit IRC | 16:20 | |
*** stevemar has joined #openstack-sdks | 16:20 | |
wchrisj | elight: 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 |
wchrisj | elight: we could probably just refer to the branch in fog-core as a stopgap solution if necessary... | 16:29 |
elight | wchrisj: I’d suggest using the prefix_path stuff immediately. | 16:29 |
elight | wchrisj: It hasn’t been merged yet? I haven’t checked but krames gave it a thumbs up. | 16:29 |
wchrisj | elight: ok | 16:29 |
wchrisj | dont think so | 16:30 |
elight | I’m going to go ahead and merge it. The bug is on Travis’ side. | 16:30 |
elight | wchrisj: I hadn’t forgotten about the gist. been pulled two different ways since getting started today. | 16:30 |
elight | wchrisj: the simple and not pretty version: https://gist.github.com/elight/bf36c28188fdedbcb5f1 | 16:30 |
wchrisj | elight - understood | 16:30 |
elight | wchrisj: I didn’t rename anything. I made the module instance methods into module methods and invoked them from an example request. | 16:31 |
elight | wchrisj: If we went this route, clearly we’d want to rename things because RequestCommon.base_request just reads oddly. | 16:31 |
wchrisj | elight - so we are completely decoupling the request from the service? | 16:31 |
elight | wchrisj: Also would be reasonable to move admin_request into the same module, I believe. | 16:31 |
elight | wchrisj: This is what I was thinking about. As I said yesterday, this may be too extreme. | 16:32 |
elight | wchrisj: But… well… maybe not. ;-) | 16:32 |
elight | wchrisj: Services already do too damn much | 16:32 |
wchrisj | elight: I'll take a look; seems the service has some knowledge that would be useful and DRYer to utilize... lemme look at it | 16:32 |
elight | Yeah exactly | 16:32 |
wchrisj | I agree with the assessment re: Services | 16:32 |
elight | Service has too many responsibilities already. Let someone else worry about how to send requests to our OpenStack back ends. | 16:33 |
elight | wchrisj: 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 |
wchrisj | elight I tend to prefer manually... rubymine is TERRIFIC when a debugger is useful; outside of that, not so much IMO | 16:35 |
elight | wchrisj: I have too many people tell me how great IDEs are for refactoring. I’m accustomed to recursive search and replaces. ;-) | 16:36 |
wchrisj | elight: me too ;-) maybe old school ISNT always better... | 16:37 |
wchrisj | elight: So your way will necessitate each request to "know" about the underlying connection ivar... you ok with that? | 16:40 |
wchrisj | @connection | 16:40 |
wchrisj | elight: feels dirty to me | 16:40 |
wchrisj | elight: maybe not | 16:40 |
elight | I don’t see that. The only ivar is auth_token | 16:41 |
elight | That shouldn’t be owned by the service either. | 16:41 |
elight | So, yeah, there’s more to untangling this than I initially suspected. And I’m not surprised | 16:41 |
wchrisj | elight: "def self.base_request(service, params)" | 16:41 |
elight | wchrisj: One benefit to this kind of refactoring is it lays bare all of the behavior’s dependencies. | 16:41 |
wchrisj | the request will have to pass it | 16:41 |
wchrisj | yes | 16:41 |
elight | wchrisj: I have an idea…. | 16:42 |
elight | wchrisj: This might finally be the time for an OSC::Connection | 16:42 |
wchrisj | elight - move the connection into the service request? | 16:42 |
elight | Hmmm... | 16:43 |
wchrisj | elight - the service is already setting that up | 16:43 |
wchrisj | what is the role of the service then? elight: | 16:43 |
elight | wchrisj: The service is a mediator (http://en.wikipedia.org/wiki/Mediator_pattern) | 16:44 |
elight | or should be | 16:44 |
elight | but it’s a mediator that does more than just mediate right now | 16:44 |
wchrisj | elight: we will have a connection for each service... | 16:44 |
wchrisj | unique | 16:44 |
wchrisj | elight "but it’s a mediator that does more than just mediate right now" - agreed | 16:46 |
elight | each service already has a connection | 16:46 |
wchrisj | elight - ultimately, all the request stuff for each service should be self contained | 16:46 |
elight | doesn’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 |
elight | not necessarily a subclass though perhaps. | 16:47 |
wchrisj | elight - not sure if here is the place to put that stake in the ground tho | 16:47 |
elight | that this should be pervasive in fog? At least the rackspace/openstack/hp providers all define a #request method | 16:47 |
elight | per service | 16:47 |
wchrisj | what I was trying to say was one thought elight | 16:48 |
elight | And, yup, so does AWS compute | 16:48 |
wchrisj | would like to constrain all the request stuff for each service in its own layer/module/etc. versus being mixed into the service | 16:49 |
wchrisj | elight ^^ | 16:49 |
elight | yes | 16:49 |
elight | this was my motivation | 16:49 |
wchrisj | elight one more thing the service doesnt need resp for | 16:49 |
wchrisj | elight But that's a significant arch change | 16:49 |
elight | it is if we carry it beyond OSC | 16:49 |
wchrisj | and not sure this is the time/place before the summit elight: | 16:49 |
elight | Heh | 16:50 |
elight | wchrisj: I’m still not sure that before the summit was the right time for OSC! | 16:50 |
wchrisj | elight maybe | 16:50 |
wchrisj | haha | 16:50 |
wchrisj | good point - but I think it was elight | 16:50 |
wchrisj | we've made good progress and cleaned up a lot | 16:51 |
wchrisj | elight do you think we can make this change (mixin -> module) and leave requests where they are at ATM? | 16:52 |
wchrisj | elight ... mixed into the service... | 16:52 |
elight | I don’t see the point. | 16:53 |
elight | It’s ok. This doesn’t have to happen now. | 16:53 |
elight | Besides, I will be out of town for much of next week. | 16:53 |
wchrisj | me too | 16:53 |
elight | So I wouldn’t be in a good position to work on it | 16:53 |
elight | Ok | 16:53 |
elight | Then Summit | 16:53 |
elight | So I say let’s let it go for now | 16:53 |
wchrisj | and just merge what we have, just make sure it is based on the new change in core? elight: | 16:54 |
elight | yeah | 16:54 |
wchrisj | ok | 16:54 |
elight | wchrisj: Travis just went all green | 16:54 |
elight | wchrisj: I merged prefix_path | 16:54 |
wchrisj | sweet | 16:54 |
*** TravT has quit IRC | 16:55 | |
wchrisj | elight: so until Wes cuts a new gem, we need to ref github, correct? | 16:55 |
elight | yep | 16:55 |
wchrisj | ok | 16:55 |
wchrisj | elight: So in Compute, I would specify Fog::Core::Connection.new("http://172.16.0.2:58587", false, :path_prefix => "v2/<tenantid>") ????? | 17:08 |
wchrisj | elight: I know the port# is wrong | 17:08 |
wchrisj | elight: So is "path_prefix" merged with "connection_options", the params hash/3rd arg? | 17:09 |
elight | wchrisj: That’s how it ought to work, yeah | 17:14 |
wchrisj | elight: 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 |
wchrisj | elight moving forward... | 17:16 |
wchrisj | elight: 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 |
elight | Friday morning suits me fine. | 17:25 |
elight | ^^ wchrisj | 17:25 |
briancurtin | is 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 report | 17:39 |
*** wchrisj has quit IRC | 17:42 | |
briancurtin | that 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 weird | 17:43 |
* briancurtin reads https://testrepository.readthedocs.org/en/latest/ | 17:43 | |
*** jamie_h has quit IRC | 17:44 | |
*** jamielennox|away is now known as jamielennox | 18:05 | |
*** wchrisj has joined #openstack-sdks | 18:27 | |
wchrisj | elight: https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric | 18:41 |
briancurtin | python-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_UTC | 18:55 |
*** wchrisj_ has joined #openstack-sdks | 19:06 | |
briancurtin | terrylhowe: you around for the meeting? | 19:07 |
terrylhowe | just got back | 19:08 |
briancurtin | terrylhowe: 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-sdks | 19:16 | |
jamielennox | terrylhowe: 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 commited | 20:01 |
terrylhowe | okay, great | 20:01 |
terrylhowe | I started out changing things and it just seemed best at first to leave as much as is | 20:02 |
terrylhowe | I'm still working on some more tests I want to add to get better coverage, but there have been distractions lately | 20:02 |
jamielennox | terrylhowe: i think i mentioned previously though - the only thing i've found that the auth plugin structure has trouble with is forcing it to reauthenticate | 20:07 |
jamielennox | you do get_token() use the token and then get back a 401 error | 20:07 |
jamielennox | you've got no way to say to the plugins that you should invalidate your cache | 20:08 |
jamielennox | there 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 for | 20:09 |
terrylhowe | I'll have to mess with it, it looked like it should all work | 20:11 |
*** mhagedorn has joined #openstack-sdks | 20:13 | |
jamielennox | terrylhowe: it's a requirement i have for auth_token middleware, i'd just like to make sure that we arrive at the same solution | 20:13 |
terrylhowe | yeh, more motivation to minimize changes | 20:14 |
jamielennox | terrylhowe: 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 clients | 20:16 |
jamielennox | as in i'd love to do a keystonclient v2.0 but it makes sense to try and reuse a pattern that exists | 20:17 |
elight | wchrisj wchrisj_ yep saw it last week | 20:17 |
*** terrylhowe has quit IRC | 20:47 | |
*** bknudson has quit IRC | 20:48 | |
*** bknudson has joined #openstack-sdks | 20:49 | |
*** terrylhowe has joined #openstack-sdks | 20:49 | |
wchrisj | elight: krames: mhagedorn: - last call for the compute PR before I merge it... | 21:08 |
mhagedorn | go wchrisj go code like the wind | 21:09 |
*** stevemar has quit IRC | 21:25 | |
*** redrobot has quit IRC | 21:55 | |
*** electrichead_ has quit IRC | 21:58 | |
*** wchrisj has quit IRC | 22:07 | |
*** bknudson has quit IRC | 22:25 | |
*** mhagedorn has quit IRC | 22:30 | |
jamielennox | dtroyer: marconi just release a client 0.0.1 https://github.com/openstack/python-marconiclient | 22:33 |
dtroyer | I saw that…haven't looked yet to see which other one it was based on... | 22:34 |
jamielennox | on the up side it's another person who has independantly stumbled on the same design of seperating transport, auth and ditching managers | 22:34 |
*** mhagedorn has joined #openstack-sdks | 22:34 | |
jamielennox | dtroyer: it looks like it's from scratch | 22:34 |
dtroyer | really? well, we need to have a closer look | 22:34 |
*** TravT has joined #openstack-sdks | 22:36 | |
*** TravT has quit IRC | 22:36 | |
*** redrobot has joined #openstack-sdks | 22:36 | |
*** redrobot is now known as Guest49525 | 22:36 | |
*** Guest49525 is now known as electrichead | 22:37 | |
terrylhowe | has a kind of message model with those request/response classes | 22:38 |
jamielennox | terrylhowe: yea, i'm not sure why they do that rather than just use requests | 22:39 |
jamielennox | because it doesn't appear like the request objects should be public | 22:39 |
terrylhowe | creates a lot of interdependencies | 22:40 |
jamielennox | terrylhowe: ? | 22:40 |
jamielennox | depending on requests? | 22:40 |
terrylhowe | well, that message class is all over is all | 22:40 |
jamielennox | i considered abstracting requests so that it was never exported such that you could replace requests with something else - but i don't know what else | 22:41 |
terrylhowe | it would be tough to integrate into OSC for one thing | 22:41 |
jamielennox | the only reason i would like to replace requests is to do things like OCSP and such | 22:41 |
jamielennox | terrylhowe: i don't think so, Request appears to be purely an internal abstraction, it still returns objects | 22:42 |
jamielennox | i have an OSC plugin for another client that works in a similar Resource orientated way and it's fine | 22:42 |
terrylhowe | maybe. I was just thinking OSC would have to call these methods and pass a message, but maybe they could be treated as private | 22:45 |
terrylhowe | oh right, the message on queue is a resource, duh. I thought it was a base class for the lower level request/response | 22:46 |
jamielennox | i don't think so https://github.com/openstack/python-marconiclient/blob/master/marconiclient/queues/v1/client.py shows the entry points | 22:47 |
terrylhowe | cool, yeh | 22:48 |
terrylhowe | I heard they weren't using rabbitmq as a backend though, something slower | 22:48 |
terrylhowe | I haven't been paying much attention though | 22:48 |
jamielennox | terrylhowe: yea, my understanding is that it's not that low level | 22:49 |
jamielennox | it's essentially a REST-ful pub/sub rather than actually messaging | 22:50 |
elight | wchrisj_: 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 redrobot | 23:20 | |
*** mhagedorn has quit IRC | 23:20 | |
*** bknudson has joined #openstack-sdks | 23:40 | |
*** bknudson has left #openstack-sdks | 23:42 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!