19:01:16 <briancurtin> #startmeeting python-openstacksdk
19:01:17 <openstack> Meeting started Tue Mar 25 19:01:16 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:20 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:33 <briancurtin> For everyone who is here for the Python meeting, can you state your name and affiliation?
19:01:44 <edleafe> Ed Leafe, Rackspace
19:01:50 <dtroyer> Dean Troyer, Nebula
19:02:00 <briancurtin> Brian Curtin, Rackspace
19:02:18 <wchrisj> Chris Johnson, HP
19:04:05 <briancurtin> I'm guessing/hoping others will probably roll in
19:04:26 <briancurtin> #topic Status of https://review.openstack.org/#/c/79435/ (Infrastructure for adding auth to a requests sesssion)
19:05:07 <briancurtin> When we left off, Jamie and I think a few others said that seemed fine to go in, but there were some infra hiccups preventing it. Since then, a -1 from Terry Howe popped up
19:05:55 <briancurtin> unfortunately I don't see Terry or Alex here
19:06:17 <mfer> Matt Farina, HP
19:06:34 <wchrisj> Terry is offline ATM
19:06:40 <briancurtin> anyone with a comment on that review or should we move forward/perhaps come back to it
19:07:32 <wchrisj> briancurtin: I'll ping Terry and ask him to comment ASAP
19:08:20 <briancurtin> #topic https://review.openstack.org/#/c/82646/ (Add API discovery support)
19:08:37 <dtroyer> briancurtin: would probably be better to look at these in order
19:08:49 <briancurtin> yeah i just realized i pasted the wrong thing, 1 sec
19:09:22 <briancurtin> #topic: https://review.openstack.org/#/c/81882/ (Add requests.Session wrapper class)
19:10:46 <briancurtin> other than my little minor comments, i think it's probably fine. could use some other eyes now that it's broken up and has a few more revs
19:10:55 <dtroyer> Anyone have any idea if I've addressed alex's comments sufficiently?
19:11:24 <briancurtin> i *think* so
19:11:59 <briancurtin> i pinged him to show up here fwiw
19:13:41 <dtroyer> what sort of docs are expected as we go here?  not finished, of course, but should something go in ad modues are added??
19:14:56 <briancurtin> dtroyer: good question, which i havent thought of until now, but I wonder if we should put in signatures at the very least, so we know *what* should be documented...versus nothing, then coming back and not covering things
19:15:14 <bknudson> I'd prefer it if the docs were first
19:15:29 <dtroyer> I was thinking that the equivalent of what I had in the blueprint could go in too
19:16:29 <briancurtin> bknudson: not having done doc-driven dev, or anything close to it - to what degree are you documenting things first? like writing the signature and prose documentation all up front, or just sketching a general idea up?
19:16:49 <bknudson> a general idea would be adequate
19:16:58 <bknudson> show a use case
19:17:19 <bknudson> btw - what docs are we talking about? a tutorial or something?
19:17:30 <bknudson> I like it for as much docs as possible be in the docstrings.
19:17:44 <dtroyer> anything really, but I was thinking of what should go into the repo, doc/source/??
19:18:49 <briancurtin> unless we have something pulling the docs out of the docstrings and into separate (or additional) documentation, i don't really like depending on docstrings
19:19:22 <bknudson> I'd prefer it if we could get as much as possible into docstrings vs separate docs. tutorials would go in separate docs, but should be able to figure out how to use the API from the docstrings
19:19:40 <bknudson> I've seen docstrings done poorly and I've seen them done well.
19:20:27 <briancurtin> you should be able to figure out the API from docstrings, but you shouldn't have to go there to find it. telling people to look at the source to find out how to use it is not a good experience
19:20:47 <bknudson> the docs are generated from the docstrings, you don't have to look at the source
19:21:31 <briancurtin> if we have that in place, that seems fine. i wasnt aware of that being the current plan
19:21:55 <briancurtin> (not familiar with how docs are done around here)
19:22:28 <bknudson> http://docs.openstack.org/developer/keystone/api/modules.html
19:22:32 <bknudson> keystone has the docstrings.
19:22:41 <bknudson> (and this is an example of docstrings docs not done right)
19:23:28 <briancurtin> as long as that infra is in place to have it there, if we do it right, then that looks fine for API docs. we can deal with tutorials or user guides and whatnot as things move on
19:24:09 <bknudson> docstrings make it easier for developers because then it's right there with the code... it still takes work to make it useful
19:25:04 <briancurtin> yep. i'll start taking a closer look at docstrings in reviews, but as long as we have good ones, i think that satisfies any doc-as-part-of-change requirement we may have for now
19:27:19 <briancurtin> #topic https://review.openstack.org/#/c/81988/ (Add redirection handling to openstack.session.Session)
19:28:53 <briancurtin> this also looked generally fine, although not being familiar with where it came from, i feel like it's probably better with some eyes from keystone people (which is where it came from, IIRC)
19:30:06 <briancurtin> dtroyer: are there tests to go with this one?
19:30:27 <dtroyer> This is basically out of jamielennox's Session object.  I haven't written/stolen specific tests yet
19:30:33 <bknudson> I assume this project is going to have a requirement for unit tests.
19:31:21 <briancurtin> yep. functionality wise it appears fine, but...tests
19:32:55 <wchrisj> question on this approach...
19:33:35 <wchrisj> Why is the redirect handling being done inside of the session. That feels like it should be in the HTTP transport layer
19:33:52 <wchrisj> if I understand what is being discussed (may not)
19:34:13 <wchrisj> it feels out of place inside of session
19:34:35 <dtroyer> as I see it, the alternative is modifying requests itself.  This is as close as we get otherwise.
19:35:13 <jamielennox> sorry, here
19:35:38 <jamielennox> wchrisj: for the time being at least this IS the HTTP transport layer
19:35:56 <wchrisj> ahh, OK, I just saw the "import requests"
19:36:03 <wchrisj> so yeah, now I see
19:36:17 <jamielennox> i submitted a bug to requests saying that for programming against APIs we would like to ignore the web redirects
19:36:46 <jamielennox> and was told that certains redirects allow (or at best don't specify) that the http method must be the same
19:36:53 <jamielennox> and that essentially apis shouldn't be using those redirects
19:37:07 <wchrisj> so this redirect handling stuff is a temp hack to overcome that shortcoming?
19:37:13 <jamielennox> however we had legacy tests in keystone that required those status to redirect correctly
19:37:19 <jamielennox> keystoneclient i mean
19:37:26 <jamielennox> wchrisj: essentially
19:37:40 <dtroyer> how temporary is it though?
19:37:43 <wchrisj> jamielennox: ok
19:37:52 <jamielennox> dtroyer: i was told it's not going to happen
19:38:01 <dtroyer> that's what I thought
19:38:25 <briancurtin> jamielennox: do you have the bug report handy?
19:38:34 <dtroyer> so it s a permanent reminder of a temporary feeling…  ;)
19:38:40 <jamielennox> briancurtin: i'll have a look
19:38:40 <wchrisj> What I'm getting at is we might want to isolate that in it's own layer just for this sort of reason
19:38:52 <wchrisj> would that make sense jamielennox: ??
19:38:59 <dtroyer> wchrisj: I see this is exactly that layer
19:39:00 <wchrisj> or is it overkill?
19:39:06 <jamielennox> https://github.com/kennethreitz/requests/issues/1778
19:39:11 <briancurtin> thanks
19:40:24 <jamielennox> i still think the reply to the bug is wrong for the API case
19:40:55 <wchrisj> dtroyer: This isn't a hill to die for, but Session is about a lot more than just the HTTP transport, correct?
19:41:08 <bknudson> people use web for something other than getting web pages?
19:41:32 <jamielennox> bknudson: :)
19:41:48 <dtroyer> wchrisj: sort of.  It is also a handly place for some common OpenStack-specific things that need to happen at this layer
19:42:03 <jamielennox> bknudson: technically they may be right - but if i was an admin i would expect i could install a 301 redirect and things would work
19:42:46 <jamielennox> wchrisj: if they were to be seperate it would be a subclass anyway so there isn't an advantage in security just seperating code
19:43:01 <jamielennox> also it would be really easy to make the subclass - because python
19:43:45 <jamielennox> that's at least the plan i've been working on for keystoneclient for when someone get's really annoyed by the mixing
19:45:08 <jamielennox> on this topic i do like the comment at: https://github.com/kennethreitz/requests/blob/master/requests/sessions.py#L132
19:45:16 <jamielennox> # Do what the browsers do, despite standards.
19:45:37 <jamielennox> yet they weren't willing to consider adding a standards mode
19:45:49 <briancurtin> bummer
19:46:53 <briancurtin> 14 min left and another review to cover, will jump forward
19:47:02 <briancurtin> #topic https://review.openstack.org/#/c/82646/ (Add API discovery support)
19:47:26 <dtroyer> this one is not finished but I wanted to get some early feedback on it
19:47:39 <dtroyer> it is totally different from what Jamie did in keystoneclient
19:48:02 <dtroyer> I wanted a discovery mechanism that could stand alone and not be too closely tied to any one API
19:48:20 <dtroyer> which is why the Identity hack is in a subclass
19:48:28 <bknudson> jamielennox has some changes to support other version responses
19:48:35 <bknudson> to the keystoneclient version
19:48:43 <jamielennox> dtroyer: right i've been wanting to go through that and see where the differences in support are
19:49:07 <dtroyer> I don't have all of the stable/experimental status bits in yet
19:49:08 <briancurtin> dtroyer: i have zero knowledge of how keystoneclient does it. should i have that?
19:49:19 <jamielennox> briancurtin: not really
19:49:28 <bknudson> briancurtin: no, please look at this fresh!
19:49:28 <jamielennox> briancurtin: the current keystoneclient only does it for keystone
19:49:46 <jamielennox> (though there are changes in place to start fixing that)
19:51:58 <jamielennox> dtroyer: did the ApiVersion class come from the keysteonclient equivalent?
19:52:28 <jamielennox> or do you see you'll have need for that?
19:52:52 <dtroyer> jamielennox: no, that's from scratch from last fall sometime
19:53:17 <dtroyer> it was just more convenient to put the version normalization in there
19:53:32 <dtroyer> I'm not sure there is a need for it outside discovery
19:53:45 <jamielennox> dtroyer: ok, that approach is what we currently have in keystoneclient but i scrapped it in a pending review
19:53:47 <bknudson> for keystoneclient we do version negotiation because we've got a v2 and v3 client libs
19:53:53 <bknudson> but there's only one openstackclient
19:54:07 <bknudson> so seems like we don't need to do version negotiation?
19:54:41 <dtroyer> bknudson: we do, OSC knows how to talk to all versions supported by the libs, but it doesn't knwo which one to use.  This stuff cam eout of what I've been working on for OSC
19:55:01 <dtroyer> back before any of the libs even thought about it
19:55:01 <briancurtin> dtroyer: using the tests as a guide, this seems straightforward enough to me coming at it with no specific knowledge
19:55:35 <jamielennox> bknudson: yea - the same thing will apply to all the other clients when we have unversioned urls in the service catalog
19:56:39 <bknudson> is openstack lib going to have multiple client lib versions?
19:57:22 <bknudson> i.e., an identity.v2 lib and an identity.v3 lib? or a compute.v2 and compute.v3?
19:57:24 <jamielennox> bknudson: it will need to span multiple api versions
19:57:38 <jamielennox> the internals of how htat will work are still unknown
19:57:43 <briancurtin> yeah, not sure exactly how it'll do it, but it'll be there
19:57:45 <bknudson> can identity lib support both identity v2 and identity v3?
19:57:49 <dtroyer> bknudson: I've always thought if it like that, similar to the project libs today
19:58:10 <dtroyer> there should be a higher-level API that strives to be version-agnostic
19:58:17 <jamielennox> bknudson: identity is tricky because of the changes from v2->v3, but in general ys
19:58:25 <dtroyer> I don't want to mix that conversation into the low-level API though
19:59:18 <jamielennox> dtroyer: so there are a lot of public apis in discovery - some returning ApiVersion objects
19:59:25 <briancurtin> 1 min left, anything to sneak in before breaking this up?
19:59:39 <jamielennox> not necessarily a problem just that it might be worth keeping some of that private
19:59:53 <dtroyer> jamielennox: yeah, I haven't really thought about that bit yet
20:00:26 <dtroyer> some of those may be useful, and I'm not sure of the consensus about sublasses overriding private methods
20:00:33 <briancurtin> #endmeeting