19:00:28 <briancurtin> #startmeeting python-openstacksdk
19:00:28 <openstack> Meeting started Tue Mar 11 19:00:28 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:32 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:53 <briancurtin> #link https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK <- Agenda
19:01:11 <briancurtin> #link https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK <- General Project Info
19:01:36 <briancurtin> Could everyone here for the python-openstacksdk meeting state their name and affiliation?
19:01:46 <edleafe> Ed Leafe, Rackspace
19:01:51 <dtroyer> Dean Troyer,  Nebula
19:01:59 <briancurtin> Brian Curtin, Rackspace
19:02:01 <jamielennox> Jamie Lennox, Red Hat
19:02:25 <wchrisj> Chris Johnson, HP
19:02:31 <jnoller> Jesse Noller, Rackspace
19:02:32 <dolphm> dolph mathews, rackspace
19:02:59 <briancurtin> Alex_Gaynor: ping
19:03:46 <bknudson> Brant Knudson, IBM
19:03:59 <briancurtin> So the meeting agenda is pretty light, as there hasn't been a ton of movement, but the first item is discussion the identity example. Direction, etc
19:04:03 <briancurtin> #topic https://review.openstack.org/#/c/79435/
19:04:31 <briancurtin> hopefully Alex_Gaynor comes in here, he was around earlier
19:05:01 <wchrisj> did he have lunch plans at this time?
19:05:09 <wchrisj> someone did...
19:05:21 <jnoller> he did
19:05:22 <wchrisj> It was him
19:05:26 <wchrisj> ugh
19:05:29 <briancurtin> oh, well moving on
19:05:36 <jnoller> anyway; the primary contention here seems to httppretty
19:05:50 <jnoller> which; has that been ported to python 3 yet?
19:06:34 <jnoller> and the dependency on URLObject
19:06:46 <jamielennox> yes it has been ported to python 3
19:07:26 <jnoller> I do agree with alex re: the global monkey patching / magic stuff behind it
19:07:38 <jnoller> I'm not a huge fan of those kinds of mocks/stubs
19:07:38 <bknudson> we're using it in keystoneclient which passes python33
19:08:01 <jnoller> bknudson: thanks, all I could recall were -dev discussions from a month or 3 ago
19:08:11 <jamielennox> jnoller: the advantage i've seen is that you are actually testing the code all the way through
19:08:26 <dolphm> what does URLObject buy you here?
19:08:52 <jamielennox> you actually test the request layer
19:09:18 <jamielennox> i completely agree with the global stuff in projects, but i think its fine for testing
19:09:53 <briancurtin> if it does the trick and is working well elsewhere, i tend to agree
19:09:58 <jnoller> jamielennox: part of this is that users want a lib (included with the sdk) of verified mocks/stubs/fakes that don't manipulate or monkeypatch
19:10:07 <jnoller> so they can use those for testing as well
19:10:20 <jamielennox> jnoller: ok - that's new
19:10:28 <jnoller> jamielennox: it's on the wiki
19:10:33 <bknudson> for keystone, a verified mock would be essentially running it with kvs backends
19:10:37 <jnoller> jamielennox: might need to call it out more
19:10:38 <dolphm> authorization scope is also completely ignored in that patch -- which is fine at rackspace, but doesn't fly in openstack
19:10:38 <bknudson> or sqlite.
19:10:43 <edleafe> jamielennox: It's important for an SDK, since it will be used as part of other projects
19:10:45 <briancurtin> are there alternatives that do the same or similar stuff without global stuff?
19:11:03 <briancurtin> (im not really familiar with this particular lib)
19:11:08 <jamielennox> briancurtin: i don't think you can, it's patching at the socket level so it installs it globally
19:11:18 <jnoller> briancurtin: for http/requests you can use regular mocks or even betamax (which is an add on)
19:11:51 <jamielennox> mocking the requests interface is a PITA, you end up carrying these dictionaries of default arguments around
19:12:29 <jnoller> I'm generally -1 on anything that patches sockets :( - but I'm also happy to reach out to Ian / Kenneth about better mocking for requests
19:12:55 <wchrisj> if betamax is anything like it's cousin vcr (ruby), that would be worth considering imo
19:12:59 <jnoller> But I'm also just one voice :)
19:13:01 <briancurtin> also happy with that as well
19:13:07 <jnoller> wchrisj: it was based on VCR
19:13:14 <wchrisj> that was my  thought
19:13:18 <jamielennox> if requests will provide support then that would be good
19:13:19 <wchrisj> jnoller: ^^
19:13:29 <jamielennox> doesn't VCR mock the socket as well?
19:13:33 <jnoller> betamax: https://pypi.python.org/pypi/betamax/0.1.6
19:13:44 <briancurtin> jnoller: does httpretty entirely fail the mock/stub thing, or is it just subpar? (not that i want to start this off with subpar stuff, just trying to understand where it fits)
19:13:57 <jnoller> briancurtin: I want to confirm with Alex_Gaynor
19:14:43 <briancurtin> so i guess we have a couple of action points to work out
19:14:47 <jnoller> briancurtin: Anything that's monkeying with too much global state or monkey patching builtins is not a plus in my mind - especially if we want swappable tcp / http transports like Alex_Gaynor is proposing
19:15:00 <briancurtin> agreed/makes sense
19:15:13 <jnoller> briancurtin: Ideally our test mocks / stubs can be used by end users building applications
19:15:31 <briancurtin> #topic look into better mocking with requests (check with Kenneth et. al)
19:15:38 <briancurtin> ah crap, sorry, meant action
19:15:46 <briancurtin> #action look into better mocking with requests (check with Kenneth et. al)
19:16:06 <jnoller> The other point on that change is the dependency on https://urlobject.readthedocs.org/en/latest/quickstart.html
19:16:15 <jamielennox> jnoller: i disagree, httpretty was adopted initially because it does deal with multiple HTTP transports. Because you mock at the socket layer it doesn't matter who makes the HTTP call
19:16:30 <jamielennox> if you use httplib or requests or whatever you will get the same response
19:16:35 <briancurtin> #action confirm state of HTTPretty usability with regard to verifying mocks/stubs
19:17:01 <briancurtin> #topic using URLObject
19:17:04 <jamielennox> (if it clashes with a goal i understand not using it, just pointing out)
19:17:09 <bknudson> does mocks/stubs here mean a fake keystone server?
19:17:11 <jnoller> jamielennox: global patching socket objects side-effects end users in surprising/unexpected ways though - I see both sides honestly
19:17:29 <jnoller> bknudson: in memory fake; not a running /forked daemon
19:17:30 <jamielennox> jnoller: it's testing code, users shouldn't care
19:17:57 <jnoller> ?
19:18:46 <bknudson> seems like it would be easier to make it so that keystone can run in-memory rather than develop a fake keystone.
19:18:57 <jamielennox> depends on the goal, if you mean internal testing then i don't know why users care what you use, if you want to export that testing to others then sure we don't want to export global state
19:19:26 <jnoller> What we use for testing should be what we recommend users use for testing - eating our own dogfood
19:20:10 <jnoller> bknudson: that means an in memory version of a LOT of things (you're going to need a full in memory openstack system)
19:20:14 <jamielennox> there's recommend and then there's here use all this stuff we've developed to help you
19:20:46 <jnoller> If we ship fakes/mocks/stubs we should be using the same ones - so the latter
19:20:46 <bknudson> jnoller: yes, keystone is probably simpler than some of the other things that will need to be faked
19:21:58 <jnoller> Personally: I would not make a recommendation for testing like this without the test suite for the sdk itself relying on it and shipping the verified mocks/stubs
19:22:25 <briancurtin> but we have a few levels of users to care about. end-users building products on this, vendors building extensions on this, etc. some end-users may not care, but i can see vendor users/devs caring
19:22:25 <jnoller> But, we need to clarify this for sure
19:23:17 <jamielennox> jnoller: ok, when i wrote the httpretty comment i wasn't aware we were considering exporting mocks, in that case i wouldn't want to export something that globally patched objects
19:23:27 <jnoller> briancurtin: I added that to the wiki as it was like #2 or #3 on the most-requested-for-a-real-sdk things when I asked at large (verified testing stuff)
19:23:39 <jnoller> jamielennox: Yeah, we should definitely dig into it
19:23:43 <briancurtin> yes
19:23:55 <jnoller> Next on Alex's patch is urlobject
19:25:20 <jnoller> Looking at it; he doesn't make extensive use of it, but reading the docs I can see why he's using it
19:25:28 <briancurtin> what does urlobject buy us?
19:25:34 <briancurtin> (havent read those docs yet)
19:25:35 <jnoller> it *seems* like a much better way of managing urls -> https://urlobject.readthedocs.org/en/latest/quickstart.html
19:25:53 <jnoller> For example
19:25:54 <jnoller> >>> print(url.with_auth('alice', '1234'))
19:25:54 <jnoller> https://alice:1234@github.com/zacharyvoase/urlobject?spam=eggs#foo
19:26:16 <bknudson> urlobjects looks safer than dealing with urls as strings.
19:26:26 <jnoller> You get out of the URL parsing / building / string concatenation game
19:26:33 <wchrisj> +1
19:26:44 <jnoller> bknudson: exactly (I've been bitten a LOT by treating them like strings)
19:27:25 <jnoller> url = blah + var + '/whee:' : port :(
19:27:26 <briancurtin> seems reasonable to me at first glance, and jamie's comment wasn't strong one way or another. Ed did bring up the point to minimize dependencies, but this seems valuable
19:27:43 <dolphm> urlobject has no other deps
19:28:04 <jamielennox> sure, happy to not have to do URL building - i don't care either way on this one, if we get it past requirements then we should use it - else no great loss
19:28:15 <edleafe> Just quoting from the original design criteria for the SDK
19:28:20 <jnoller> I want to minimize dependencies, but I also don't want to fail boat on url management
19:28:41 <jnoller> this basically means: requests + urlobject
19:29:11 <jnoller> which doesn't seem *terrible* as it still avoids the N+K dependencies creep
19:29:44 <dtroyer> no but it's a bit ironic that the first code patch adda a new dependency...
19:29:51 <dolphm> it's not in global requirements though, which just means no one else is using it yet
19:29:59 <briancurtin> (sorry, bad conference wifi)
19:30:04 <jnoller> dtroyer: yeah :(
19:30:57 <dolphm> jnoller: i'd simply like to have a reasonable explanation for needing every dependency; this seems to be one we'd use extensively, and it's light so ++
19:31:13 <briancurtin> agree
19:31:23 <wchrisj> agree
19:31:28 <jamielennox> ++
19:31:32 <jnoller> dolphm: Ok, Alex_Gaynor needs to document (in a blueprint) why using this (and adding it to global-requirements) is a positive
19:31:55 <briancurtin> #action Alex_Gaynor outline a justification of why to use URLObject and add it as a dependency
19:32:17 <jnoller> Its not like installing its own wsgi server ;)
19:32:32 <dolphm> jnoller: not that there's anything wrong with that, right?
19:32:39 <jnoller> haha
19:33:01 <dtroyer> but it's also not packaged in Ubuntu yet…so yet one more step to completion
19:33:31 <jnoller> dolphm brought up some good rackspace-isms in Alex_Gaynor's patch that have to be excised
19:33:39 <jnoller> dtroyer: good catch
19:34:06 <briancurtin> yeah that'll be a good thing to cover in the BP
19:35:28 <jnoller> So, Alex has some refinement to do
19:35:34 <dolphm> blueprints effectively get lost after they're implemented though... they "why" might be better preserved in a commit message
19:35:41 <dolphm> the*
19:35:58 <jnoller> dolphm: commit message and the wiki
19:36:03 <briancurtin> dolphm: is this better to be laid out in a wiki, and then condensed into a commit
19:36:12 <briancurtin> mind reader
19:37:21 <briancurtin> so, ok, have some research to do on HTTPretty, requests mocking, URLObject. what else do we have with the example so far?
19:37:45 <jnoller> briancurtin: remove the rackspace-isms
19:38:04 <jnoller> dolphm did a great job pointing those out
19:38:23 <briancurtin> #action Alex_Gaynor remove Rackspace-isms in example code, as pointed out by dolphm
19:38:41 <bknudson> what's the "validated stub/mock" in this patch? https://review.openstack.org/#/c/79435/5/openstack/tests/test_auth.py ?
19:41:18 <jnoller> @bknudson: good question for Alex_Gaynor
19:42:15 <jnoller> briancurtin: anything else for us to review? It seems everyone got busy with conferences and icehouse so our goal should be to focus on more BP / commits like the one Alex_Gaynor did so we can discuss those going into next week
19:42:58 <briancurtin> i think that's it on review for right now. should we take the last 20 or so min and talk about what, if anything we want to have at the design summit?
19:43:03 <dolphm> dtroyer: i saw you added another line break to the requirements files, what happened there?
19:43:25 <dolphm> (there's two line breaks at the end of the file now)
19:43:50 <dolphm> which is definitely better than zero and a broken jenkins
19:43:50 <Alex_Gaynor> (I'm present now)
19:44:02 <jnoller> pfft food
19:44:07 <dtroyer> it was part of trying to figure out what it took to get any of those changes through...
19:44:20 <dtroyer> int he end we needed to just disable the test due to the way it was written
19:44:24 <dtroyer> can be cleaned up now
19:44:30 <dolphm> dtroyer: ack
19:44:38 <briancurtin> #topic Design Summit topic(s)
19:45:06 <briancurtin> with 15 minutes left, anything input as to what, if anything, should be submitted for the design summit?
19:45:50 <jnoller> briancurtin: I submitted a design summit session today on this and developer experience/cloud consumer stuff
19:45:51 <briancurtin> i'm not familiar with how this goes, so i would appreciate some insight into what we can do, how we should do it, etc.
19:46:00 <briancurtin> jnoller: can you link to it?
19:46:08 <wchrisj> New for me too
19:46:08 <jnoller> y
19:46:10 <jnoller> one second
19:46:30 <dolphm> jnoller: i don't see one...
19:46:35 <dolphm> ah http://summit.openstack.org/cfp/details/34
19:46:50 <jnoller> http://summit.openstack.org/cfp/details/34
19:47:42 <briancurtin> not knowing how broad or narrow these things go, should this project be on its own, or should it be a part of the greater experience stuff?
19:48:32 <jnoller> briancurtin: I'm open to suggestions on that too
19:49:01 <jnoller> briancurtin: too narrow worries me, I'd like to avoid a monoculture when looking at the personas/users
19:49:05 <briancurtin> i just don't really know. i think there's certainly value in getting together on the greater topic, and getting with teh PHP, Ruby, Go, etc folks
19:49:08 <edleafe> briancurtin: The design summit sessions are where everyone concerned makes decisions on how to proceed over the next 6 months. The sessions should be very specific
19:49:09 <briancurtin> yep
19:49:10 <dolphm> related: User Experience Designers Gathering http://summit.openstack.org/cfp/details/33
19:49:32 <jnoller> dolphm: yes, that one is very focused on horizon
19:49:34 <briancurtin> edleafe: so should there be a python session, php session, ruby sess, etc?
19:49:43 <edleafe> ideally, yes
19:49:46 <Alex_Gaynor> dolphm: Will get a patch up to address your concerns after the meeting.
19:50:02 <edleafe> A lot of what we will discuss has nothing to do with ruby or php
19:50:09 <dolphm> jnoller: ++ it's on the "Other projects" track though - any idea why? (or what that track is for?)
19:50:17 <briancurtin> do we then push for *both* avenues? individual to suss out a lot of our specific things, but also unified to gather common direction?
19:50:24 <jnoller> dolphm: No idea, I saw it this morning
19:50:33 <jnoller> briancurtin: good idea
19:50:41 <jnoller> better than mine!
19:50:45 <wchrisj> briancurtin: +1
19:50:47 <dtroyer> briancurtin: ideally, yes
19:50:59 <edleafe> briancurtin: it depends on what aspects of the design you need to work on
19:51:12 <dtroyer> given a choice and the stage we're in, python-specific if we can only do one
19:52:27 <jnoller> I will say mfer and others here have been making progress on the other SDKs too (php, go, etc)
19:52:38 <edleafe> dtroyer: yeah, given that we don't have anything to go on, generic is probably all we can do
19:52:46 <jnoller> the goals are pretty aligned
19:53:08 <edleafe> jnoller: aren't they working from an established code base?
19:53:38 <jnoller> edleafe: they're all shifting into 2.0 clean room modes
19:53:47 <dolphm> jnoller: where are the non-python sdk's on github?
19:53:48 <jnoller> edleafe: much like this one
19:54:02 <jnoller> dolphm: hold on, need to find all the links
19:54:23 <dolphm> jnoller: and is there any desire to get them into stackforge? (has that been discussed?)
19:54:28 <mfer> is this something we should continue in the #openstack-sdks room?
19:54:28 <dtroyer> Go: http://git.openstack.org/cgit/stackforge/golang-client/
19:54:39 <jnoller> mfer: true
19:54:43 <mfer> dolphm a number of them are going into stackforge already
19:54:44 <jnoller> sorry, lack of focus
19:55:45 <jnoller> edleafe: think you can work with alex to flesh out more of the identity stuff?
19:56:11 <edleafe> I'
19:56:14 <edleafe> oops
19:56:36 <edleafe> I'd have to discuss with him what his goal is with the code - not entirely clear to me yet
19:58:01 <briancurtin> if people aren't hounding us at this conference, i'm around to help out with it
19:58:10 <jamielennox> let me know any issues you have with identity, though i realize i'm not in most peoples TZ
19:58:14 <jnoller> ok, let's see if we can do that and keep more going into the repo for discussion
19:58:25 <briancurtin> feed the machine with code
19:58:30 <jnoller> jamielennox: I don't even know what TZ I'm in right now so it's cool
19:58:44 <briancurtin> what even is time
19:59:07 <briancurtin> so i think that's probably it, anything as the clock winds down?
19:59:13 <jnoller> Nope!
19:59:25 <wchrisj> I'll get with Alex_Gaynor: and help as well
19:59:38 <dolphm> glad to see everyone here :)
19:59:55 <briancurtin> #endmeeting