19:00:28 <briancurtin> #startmeeting python-openstacksdk
19:00:28 <openstack> Meeting started Tue May 12 19:00:28 2015 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:31 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:36 <dhellmann> o/
19:00:46 <briancurtin> if you're here for SDK meeting, say hi
19:01:04 <dtroyer> o/
19:01:16 <etoews> o/
19:01:19 <terrylhowe> o/
19:01:56 <briancurtin> #topic finishing out proxy APIs
19:02:51 <briancurtin> so now that we have create, update, and delete done, there's a review out for list that i think should work for most people (https://review.openstack.org/178302), but get is the hangup
19:03:06 <briancurtin> what should we support with soemthing like get_server in terms of what it accepts and what it returns?
19:03:40 <briancurtin> my thinking is that you can give it an ID, a server object, or a name (which it then passes to list, filters on it, and gives you the match)
19:04:29 <briancurtin> i dont personally see a need for the find functionality we have floated. being able to get one resource or multiple resources through the two methods covers what i can imagine
19:05:33 <briancurtin> if you need finer grained search capability, you can leverage the query params we support in the list calls and then add additional searching in your application code, but it's a specialized enough thing that i dont know if we can do a great job supporting it within the SDK
19:06:02 <dtroyer> the biggest difference I came to between find and list is find returns a single thing and list returns a … list of things.  the input bits totally can overlap
19:06:42 <dtroyer> find is often useful as a wrappper to list if/when the input args need a common set of tweaks, with the right defaults o list inputs that shouldn't benecessary
19:06:43 <briancurtin> dtroyer: but when get_server is only ever going to return one server and find_server is also only going to return one, is there still a need for both?
19:07:06 <dtroyer> only as a convenience
19:07:52 <briancurtin> wouldnt it be more convenient to just call one method though?
19:08:05 <dtroyer> there have been corner cases with the old libs where find has some specific fallback that list doesn't, I don't think that should be necessary in the SDK
19:08:33 <briancurtin> i guess what i could do, in the interest of time, is just make get_server return based on ID or object, and either it grows to cover something like find or find still lives on its own
19:08:43 <dtroyer> it depends on the inputs.  Again, with clean and consistent lower-level implementations, I'm hoping it isn't
19:09:34 <etoews> i wouldn't care to see get_server grow beyond id or object
19:09:47 <dtroyer> so get_server() wraps list_server() and returns a single server object or raises excpetion if there is more than one?
19:10:07 <dtroyer> name also please, I need that all the time in OSC
19:11:07 <briancurtin> dtroyer: my current approach is that get_server tries to do a GET on the ID (you either pass one or a resource, and we get hte raw ID) - if it's not found based on that (because maybe it wasn't an ID), it would then call list with name=the_input_value and then return one and only one value (or raise if it's not one)
19:11:08 <etoews> when using name isn't that part of servers() considering they're usually not unique?
19:11:33 <etoews> names are not unique that is
19:11:42 <briancurtin> etoews: if you create servers that are not named uniquely then you'll have to do something else entirely if you ever want to find them
19:12:03 <dtroyer> no they;re not, which is why you have to handle the multiple return case
19:13:02 <dtroyer> briancurtin: that;s essentially what the #*&! find() in OSC does, it's a bastard that includes all the special cases in the old libs…
19:16:04 <briancurtin> im just thinking that ive rewritten find at least 10 times now and it will never work generically, and i dont want to have to reimplement stuff all over for how every single resource does different things. i think we have a pretty good list that now supports query params, and i can make get just work on IDs. together those should be enough to get people
19:16:04 <briancurtin> started, and maybe later we figure out find
19:16:40 <briancurtin> i dont want to rush a release, but i really want to get something out there if we have create, update, delete, get, and list done ahead of teh summit since we've been sitting on a lot of changes for a while now
19:17:03 <briancurtin> another thing we talked about was clone - that can also come later, it's just fanciness on top of create
19:17:08 <etoews> briancurtin: get just works with IDs and names?
19:17:16 <briancurtin> no
19:17:24 <briancurtin> IDs only (which includes resources)
19:17:41 <briancurtin> it currently does the name thing right now, but if it's going to do that then we are not having find
19:18:03 <dtroyer> I'm good with that
19:18:03 <briancurtin> it sounds like maybe we want find, so getting by name will happen there
19:18:15 <briancurtin> (there=find)
19:18:39 <etoews> ah. that got lost in the noise for me.
19:18:39 <stevelle> I also like that option
19:19:36 <etoews> summary:
19:19:37 <etoews> get by id, find by name, list with filters
19:19:37 <etoews> or
19:19:37 <etoews> get by id/name, list with filters
19:19:46 <etoews> are those basically the options?
19:20:11 <dtroyer> I like the first only because find is implemented as a combination of get and list, that lests get and list stay atomic
19:20:20 <briancurtin> teh second one could really get by id/name/<any of the query params the associated list method takes>
19:21:09 <briancurtin> but i want to just go with the first at this point. maybe it grows to cover the second, but it seems less likely now
19:21:37 <etoews> terrylhowe: thoughts?
19:21:51 <etoews> on the options.
19:22:02 <terrylhowe> sorry, I got pulled aside there :-/
19:23:18 <dhellmann> I like the 3 separate functions, for the reasons dtroyer stated
19:24:58 <stevelle> also, very easy to document and explain
19:25:27 <dhellmann> ++
19:26:08 <terrylhowe> I’m a like the find method.  I think the biggest challenge with it is how wonky list can be
19:26:50 <briancurtin> so far the only real wonkiness ive found with list is that some support pagination and some dont, but we figured that one out (although it's manual when building the resource)
19:27:53 <etoews> option 1 wfm
19:28:09 <dtroyer> as long as list() has a consistent interface, find should be ok.  The only thing I'd wonder about is also having a find_all() that returns all matches and find() wrap that to be the return-exactly-one obejct version
19:28:19 <dtroyer> but that too can come later
19:28:33 <briancurtin> but anyways, at this point i'll think out that get review and have it ready probably right after this meeting. list is already out there. i probably won't actually be able to work on find right away with talk slides and things to build up that is using what's out there...but it's next
19:28:47 <briancurtin> *thin out that get review
19:29:41 <briancurtin> the only other thing i had on the "agenda" was if anyone has any high priority stuff they need eyes on for the rest of the week
19:30:05 <briancurtin> and i guess another is if there are specific topics to cover in the cross-project session that was accepted - i havent written any agenda up on it yet but will in the next day or so
19:30:19 <etoews> what's the story on the failing py34?
19:30:39 <etoews> do we just ignore it and merge away or is that a no-no?
19:31:11 <briancurtin> i dont think we can merge unless that's passing, but when i looked earlier i dont think it was anything we did...but i didnt dig very far
19:31:13 <terrylhowe> I keep hoping that will magically fix itself
19:31:26 <briancurtin> oh, you know what...timed out after 40 minutes
19:31:30 <briancurtin> i bet it's httpretty
19:31:35 <etoews> yep. time out everytime.
19:32:01 <briancurtin> yep, httpretty released yesterday
19:32:02 <dtroyer> is httpretty a prereq?  hopefully for testing only?
19:32:23 <briancurtin> dtroyer: yeah it's a testing req, and we're most of the way through removing it
19:32:27 <terrylhowe> I thought we were mostly off httpretty
19:32:34 <dtroyer> good to hear, thanks
19:32:55 <briancurtin> mostly, but still a handful of them left, i think just in object_store, which i had been saving since the tests needed to be rewritten when we changed the proxy methods
19:33:10 <briancurtin> when the get and list changes go through, i think we should be off httpretty at that point
19:33:35 <briancurtin> we should probably push through another hack workaround for httpretty though because of this so we can get things moving
19:33:52 <etoews> !=0.8.9
19:33:52 <briancurtin> (like the extra requirements file, or messing with tox)
19:33:53 <openstack> etoews: Error: "=0.8.9" is not a valid command.
19:35:30 <briancurtin> terrylhowe: yeah, it's just in object_store right now and a test base class
19:36:24 <etoews> fix test right now or exclude 0.8.9 right now. i've got a patch for exclude 0.8.9 ready to go.
19:36:46 <terrylhowe> send it etoews
19:37:07 <briancurtin> etoews: how are you doing it though? if you try to change requirements or test-requirements it'll get bounced by some requirements watcher. i think
19:37:29 <etoews> we already have a bunch of exclusions for httpretty
19:37:38 <dtroyer> do you know if that release breaks anything else?
19:37:40 <briancurtin> the last time we had to do this we pulled it out of test-requirements and put it in like fix-gates.txt and inserted that into the tox.ini
19:37:45 <etoews> i'm working on the assumption adding one more won't hurt
19:38:11 <terrylhowe> true, I think the gate will downvote your change etoews like briancurtin says
19:38:24 <briancurtin> dtroyer: not really sure, but the last 4-5 httpretty releases just hang on some socket stuff only on 3.4. there had been a patch by dave stanek months ago that just sits there and they release without it
19:39:01 * dtroyer sighs
19:39:41 <briancurtin> the carelessness of releases is part of what i think spurred requests-mock by jamie, which we moved to (along with just not using anything and using regular Mocks better)
19:39:54 <etoews> so what exactly do we need to do to get out of this snarl right now?
19:40:11 <dhellmann> should we address this in the global requirements list?
19:40:29 <briancurtin> dhellmann: knowing the last 5 times this has happened, there's probably 4 changes out there right now for it
19:40:30 <dhellmann> with a cap, instead of with simply != that is?
19:41:02 <dhellmann> https://review.openstack.org/#/q/project:openstack/requirements+is:open+message:httpretty,n,z
19:41:05 <briancurtin> etoews: i think if we pull httpretty out of test-requirements, put it in its own file temporarily with exactly what we know works, have tox.ini pip install -r that file, then we can sidestep the issue for now
19:41:29 <briancurtin> ah, only one (so far!)
19:42:00 <dhellmann> it looks like it is hitting an issue with neutron
19:42:16 <dhellmann> http://logs.openstack.org/40/182340/1/check/check-requirements-integration-dsvm/15bd61d/console.html#_2015-05-12_19_25_10_338
19:42:24 <etoews> https://review.openstack.org/#/c/182340/
19:42:42 <briancurtin> etoews: here's one we did last time: https://review.openstack.org/#/c/158419/
19:43:13 <etoews> how much effort is it to just get us completely off httpretty at this point?
19:43:30 <terrylhowe> https://github.com/gabrielfalcao/HTTPretty/pull/193 some upvotes there might get gabriel to merge that
19:43:32 <dhellmann> it looks like the fix for that gate issue is https://review.openstack.org/#/c/182413/
19:43:47 <terrylhowe> it looks pretty big because there is a base transport class that uses it too
19:44:01 <terrylhowe> not sure how that base class is used though
19:44:03 <briancurtin> etoews: not much. it just hinges on the object_store tests being updated, but i dont want to update them independently and then also change them again when making hte proxy test changes. i will look right after this, but they're easy to move in line with the rest of teh proxies once their actual implementations follow
19:44:23 <briancurtin> terrylhowe: that base transport isn't used in any of the other changes though, as far as i remember
19:44:44 <briancurtin> i moved away from using htat register_uri method that it is exposed through
19:45:07 <briancurtin> iirc that's really just there for the remaining object_store ones and their different proxy impl
19:45:42 <briancurtin> so we either swap out the impl of register_uri, or i think probably just remove that since that's not how requests-mock does it
19:46:25 <briancurtin> i think the approach to do is sidestep httpretty for right now and hopefully within a day or so the get and list methods might be approved, and then the first changes i'll do after that are finishing up the object_store transition to remove the httpretty things
19:46:58 <etoews> +1
19:47:09 <terrylhowe> yeh, sounds good
19:47:34 <etoews> sidestep httpretty == https://review.openstack.org/#/c/182340/
19:47:49 <briancurtin> etoews: that's going to take 5 days to get through
19:48:04 <briancurtin> etoews: i'm going to do https://review.openstack.org/#/c/158419/ again and it'll be over in 10 minutes
19:48:57 <etoews> alright
19:50:34 <briancurtin> running tests with the change right now, should be able to push in a few min
19:50:46 <briancurtin> 10 minutes left, anything else to get through in the next few days?
19:51:15 <etoews> it's not a priority for the summit but ... https://review.openstack.org/#/c/181607/
19:52:21 <etoews> i'm going to be giving a workshop on building an app on openstack at qcon in ny and i want to use the sdk but i need me some queues
19:53:05 <etoews> the workshop is june 9
19:53:16 <terrylhowe> it looked good in general etoews but I haven’t tried it
19:53:54 <terrylhowe> this patch also makes me wonder again if we should have a messaging directory with all the various messaging services inside it, but I think not
19:53:59 <etoews> seems support for zaqar was just added as a plugin to devstack.
19:54:42 <dtroyer> let's get the core close to done before expanding
19:54:46 * dtroyer used the c-word there
19:55:24 <terrylhowe> true dtroyer
19:56:04 <briancurtin> let this run the tests, but it should pass and we'll temporarily be around httpretty again: https://review.openstack.org/#/c/182435/
19:57:08 <etoews> terrylhowe: i can give you access to a devstack instance if you want to do a quick trial run.
19:59:22 <terrylhowe> that’s okay etoews thanks though
19:59:52 <terrylhowe> https://review.openstack.org/#/c/155362/ dynamic service loading
20:00:02 <etoews> alright. well ping me if you have any questions on it. i'm pretty available this week.
20:00:08 <terrylhowe> a topic I wanted to actually talk a bit about at the summit
20:00:57 <etoews> time
20:01:16 <etoews> briancurtin: time to call it
20:01:21 <briancurtin> terrylhowe: yeah, that one keeps creeping to the top of my list. i will try to get to it once again after get/list
20:01:27 <briancurtin> #endmeeting