*** briancurtin has quit IRC | 00:32 | |
*** briancurtin has joined #openstack-sdks | 00:34 | |
*** rgbkrk has joined #openstack-sdks | 01:14 | |
*** briancurtin has quit IRC | 01:15 | |
*** briancurtin has joined #openstack-sdks | 01:23 | |
*** savushkinas has quit IRC | 02:17 | |
*** bknudson has quit IRC | 03:14 | |
*** rgbkrk has quit IRC | 04:40 | |
*** briancurtin has quit IRC | 05:20 | |
*** rgbkrk has joined #openstack-sdks | 05:38 | |
*** vikontessa has joined #openstack-sdks | 06:10 | |
*** rgbkrk has quit IRC | 06:29 | |
*** vikontessa has quit IRC | 06:32 | |
*** sharwell___ has joined #openstack-sdks | 10:47 | |
*** sharwell_ has quit IRC | 10:50 | |
*** mfer has joined #openstack-sdks | 13:04 | |
*** rgbkrk has joined #openstack-sdks | 13:19 | |
*** briancurtin has joined #openstack-sdks | 13:19 | |
*** rgbkrk has quit IRC | 13:34 | |
*** bknudson has joined #openstack-sdks | 13:38 | |
*** briancurtin has quit IRC | 14:08 | |
*** etoews_ has joined #openstack-sdks | 14:12 | |
*** briancurtin has joined #openstack-sdks | 14:15 | |
*** etoews_ has quit IRC | 14:17 | |
*** etoews_ has joined #openstack-sdks | 14:18 | |
*** wchrisj has joined #openstack-sdks | 14:30 | |
*** krames has joined #openstack-sdks | 14:32 | |
*** Klumben has quit IRC | 14:48 | |
*** dolphm has quit IRC | 14:48 | |
*** rgbkrk has joined #openstack-sdks | 14:49 | |
*** dolphm_ has joined #openstack-sdks | 14:49 | |
*** Klumben has joined #openstack-sdks | 14:50 | |
*** dolphm_ is now known as dolphm | 14:50 | |
*** ycombina_ has joined #openstack-sdks | 15:12 | |
*** ycombina_ has quit IRC | 15:15 | |
*** etoews_ has quit IRC | 15:30 | |
*** rgbkrk has quit IRC | 15:31 | |
*** rgbkrk has joined #openstack-sdks | 15:58 | |
briancurtin | jamielennox, wchrisj: i was a bit busy last week - anything going on with http layer + keystone example at the moment? | 16:08 |
---|---|---|
wchrisj | briancurtin: Embarrassed to say, not much. But, I will be more diligent about it this week. | 16:19 |
wchrisj | jamielennox sent me a couple of things to review | 16:20 |
wchrisj | to his credit | 16:20 |
wchrisj | I need to get with him and discuss | 16:20 |
briancurtin | nothing to be embarrassed about - i was hoping to contribute last week but got tied up. let me know if i can help with reviews, and feel free to ping me whenever you're discussing | 16:21 |
wchrisj | I harped on getting something done last week on irc - and then I didnt get anything done to speak of - that's what I meant. Thanks for the offer - will bring you in. | 16:23 |
*** krames has quit IRC | 16:51 | |
*** dhellmann is now known as dhellmann_ | 17:23 | |
*** etoews_ has joined #openstack-sdks | 17:25 | |
*** samchoi has joined #openstack-sdks | 17:39 | |
*** krames has joined #openstack-sdks | 18:02 | |
*** krames has quit IRC | 18:15 | |
*** krames has joined #openstack-sdks | 18:15 | |
elight | wchrisj: Just got back on the job after being out the better part of 1.5 weeks. | 18:16 |
elight | wchris: Reviewing the fog_openstack_tng code. Have some concerns. | 18:16 |
elight | wchrisj: Could we switch to doing PRs on the repo? And only merging PRs after a review? | 18:17 |
elight | wchrisj: This way, we’ll have a better final OpenStack Fog provider | 18:18 |
elight | wchrisj: Also, with a Fog Summit likely in the next few months, I wonder about the wisdom of pushing too hard on this until after the Summit. We don’t know what sort of changes may shake out of the Summit. There could be a large impact to the new OpenStack provider. | 18:18 |
elight | wchrisj: Kyle and I are concerned that if we try to push too hard on getting a new Fog OpenStack provider out the door ASAP that we risk needing to rewrite it (again). Possibly more likely post Summit. | 18:20 |
*** dhellmann_ is now known as dhellmann | 18:23 | |
*** etoews_ has quit IRC | 18:38 | |
wchrisj | elight: That first merge was my fault; MikeH asked me to do it, and I should have pushed him to do it. He reviewed the code before it was merged. That wasn't a cowboy merge on my part. | 18:58 |
wchrisj | elight: As far as waiting for the summit, I'd rather not if we can avoid it. Two months is quite a long time. If we do things now with a focus on easy changeability, we should be good. | 19:01 |
wchrisj | elight: I think we build what we think is a best of breed provider, and let the code talk when we get to the summit. | 19:02 |
*** krames has quit IRC | 19:08 | |
wchrisj | elight: re: your comments about reviewing, what were your concerns? | 19:10 |
*** krames has joined #openstack-sdks | 19:15 | |
elight | wchrisj: I’ve reviewed a little but so far some undesirable tight coupling in Identity and some things that could be more idiomatic | 19:16 |
elight | wchrisj: krames and I are going to spike on a fork and submit a PR or few to demonstrate. | 19:17 |
wchrisj | elight: krames: yeah, this wasnt meant to be the final solution; more of an evolution to be able to get specs around requests and models. We are aware that this isn't great code yet. | 19:20 |
wchrisj | I have finished an initial cut of the specs around requests, and am working on models now | 19:21 |
wchrisj | Am also taking a harder look at authentication | 19:21 |
wchrisj | elight: krames: Do we need a develop branch in the repo? Can I nuke it? | 19:32 |
wchrisj | I dont think we need it - just checking | 19:32 |
krames | I believe you need one if you are working out of the same repo and want to do pull requests | 19:33 |
wchrisj | I do all my dev on feature branches - never need it | 19:33 |
wchrisj | I think it as a mistake on my part that got it there to begin with ;-) | 19:34 |
wchrisj | wa | 19:34 |
wchrisj | was | 19:34 |
elight | We don’t need a “develop” branch unless we need someplace to merge feature branches that’s not “master" | 19:35 |
elight | we’re not there yet. | 19:35 |
elight | So, for now, don’t think so | 19:35 |
wchrisj | am going to kill it for now - we can re-introduce it if/when we need it | 19:35 |
*** eldarx has joined #openstack-sdks | 19:57 | |
*** jamielennox is now known as jamielennox|away | 20:15 | |
*** etoews_ has joined #openstack-sdks | 20:16 | |
*** eldarx has quit IRC | 20:26 | |
*** mfer has quit IRC | 21:04 | |
*** jamielennox|away is now known as jamielennox | 21:17 | |
*** dstufft has quit IRC | 21:22 | |
*** dstufft has joined #openstack-sdks | 21:22 | |
*** etoews_ has quit IRC | 21:43 | |
*** briancurtin has quit IRC | 21:49 | |
*** krames has quit IRC | 22:08 | |
*** krames has joined #openstack-sdks | 22:09 | |
*** krames has quit IRC | 22:10 | |
*** rgbkrk has quit IRC | 22:37 | |
wchrisj | elight: hey, you still around? | 22:43 |
elight | wchrisj: barely | 22:44 |
elight | what’s up? | 22:44 |
wchrisj | lol - dead after your "vacation"? | 22:44 |
elight | dead after moving. yes. | 22:44 |
wchrisj | or just a long day? | 22:44 |
wchrisj | yeah | 22:44 |
wchrisj | I remember those days | 22:44 |
wchrisj | I'm thinking about auth... and there appear to be 3 distinct ways to auth, wih diff results coming back: | 22:45 |
wchrisj | 1) uname/pwd --> unscoped token | 22:45 |
wchrisj | 2) uname/pwd/tenant --> scoped token | 22:45 |
wchrisj | 3) auth token --> scoped token | 22:46 |
wchrisj | I think we should be pretty explicit with how we handle these cases coming in for auth... | 22:46 |
wchrisj | make sense? | 22:46 |
wchrisj | the existing is a hodgepodge | 22:46 |
elight | yes | 22:47 |
wchrisj | are you aware of any other variations for auth? | 22:47 |
elight | No. Granted, my understanding of the supported auth methods is currently dictated by Fog... | 22:48 |
elight | The OpenStack API docs should reveal if there are more. | 22:48 |
wchrisj | I'm looking here: https://github.com/openstack/python-keystoneclient/tree/master/doc/source | 22:49 |
wchrisj | in addition to the API docs | 22:49 |
wchrisj | the API docs have been wrong a few times, so I'm a bit gunshy | 22:50 |
wchrisj | trying to loo in several sources | 22:50 |
wchrisj | look | 22:50 |
wchrisj | Other question is this... | 22:50 |
wchrisj | If you look here: http://api.openstack.org/api-ref-identity.html#identity-v2 | 22:51 |
*** bknudson has left #openstack-sdks | 22:51 | |
wchrisj | you will see that the response back includes several objects (json): service catalog, tenant, user, etc. | 22:52 |
wchrisj | I'm thinking it would be useful to hydrate objects based on those values when you return from the auth call; | 22:52 |
wchrisj | get rid of most of the ivars in the identity class | 22:53 |
wchrisj | does that make sense? | 22:53 |
elight | “hydrate”? Create objects containing the data instead of storing a nested Hash? | 22:55 |
wchrisj | yes | 22:56 |
wchrisj | or even structs | 22:56 |
wchrisj | I happened upon a service_catalog object in the Rackspace code several days ago | 23:00 |
elight | wchrisj: I’m not sure I follow. Only one of those instance variables is required by Identity and the rest are “recognized”. | 23:00 |
elight | wchrisj: It looks to me like they could simply be passed to authenticate instead of being set in the initializer. | 23:00 |
elight | i haven’t spent enough time trying to take this code apart yet... | 23:00 |
wchrisj | That might be true | 23:00 |
elight | well it depends | 23:01 |
wchrisj | Like I said earlier, my efforts so far have been focused on drying the code up, not really refactoring a lot | 23:01 |
elight | If the Identity object will be used to authenticate several times, and those options can be stored and applied for each authentication, then storing them in instance variables make sense | 23:01 |
elight | current_user is clearly specific to a single user. :D | 23:02 |
elight | auth_url should be reusable across calls. | 23:02 |
wchrisj | agreed, but I'd rather have a single ivar that contains an object that manages all of those as opposed to a dozen or more separate ivars... | 23:03 |
elight | see what you’re getting at now. But I don’t know that I agree. | 23:04 |
elight | Some of the variables logically group together well as they seem related to a particular auth attempt | 23:04 |
elight | others are more representative of a particular OpenStack cloud auth service. | 23:05 |
elight | Oh, sorry, but you’re speaking to “handle_auth_results”? | 23:05 |
elight | Those seem mostly related. Though I wonder about “mnagement_url" | 23:05 |
wchrisj | no - "apply_options" | 23:06 |
wchrisj | ugh | 23:06 |
wchrisj | NO WAY we need to save all that | 23:06 |
wchrisj | it feels like a dumping ground | 23:06 |
elight | Again, I get the impression some are representative of a particular auth endpoint and others are representative of a single authenticated user. So maybe two objects? | 23:07 |
wchrisj | much better imo | 23:07 |
elight | Though it seems odd to me that the Identity service object would store information related to a user instead of return it... | 23:07 |
wchrisj | it does return it - that's one reason I suspect it's superfluous | 23:08 |
elight | I would like to believe that an Identity service would know about the how to identify users in general and not concerned with the details of a specific user. | 23:08 |
elight | *nod* | 23:08 |
elight | Yep, I see that. | 23:08 |
elight | And agreed. That’s odd. | 23:08 |
wchrisj | I think this is just indicative of an evolved codebase over time without a lot of backbone wrt design... | 23:08 |
wchrisj | ;-) | 23:08 |
wchrisj | copypasta galore | 23:09 |
elight | accreted, I’d say. Stuff got added but never integrated. | 23:09 |
wchrisj | every stinking service (compute, imge, etc.) has this same code | 23:09 |
elight | :-( | 23:09 |
wchrisj | or variations of it | 23:09 |
elight | That’s copypasta, yeah | 23:09 |
wchrisj | dinnertime - I'll ping you tomorrow | 23:10 |
wchrisj | glad you are back! | 23:10 |
elight | wchrisj: k! | 23:10 |
wchrisj | get some rest | 23:10 |
elight | wchrisj: trying. that’s part of the problem. ;-) | 23:10 |
wchrisj | k | 23:10 |
*** bknudson has joined #openstack-sdks | 23:52 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!