19:00:28 <briancurtin> #startmeeting python-openstacksdk
19:00:28 <openstack> Meeting started Tue Jun 30 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:54 <briancurtin> if you're here for the SDK meeting, say hi. i know etoews may be a few minutes late
19:01:18 <terrylhowe> o/
19:02:34 <briancurtin> etoews and i already chatted a bit about this first one so we can get into it and he'll catch up
19:02:40 <briancurtin> #topic Proposal: moratorium on new services/resources being added until after 1.0
19:03:00 <briancurtin> In order to be able to release, we're going to need to put a halt to adding support for new operations while we catch up on functional tests, documentation, and the other larger initiatives we need to complete like plugins
19:04:05 <terrylhowe> sounds good
19:04:14 <briancurtin> I don't imagine this to be very controversial, but the operations we support today is just what we should stick with. Don't add any more, just make what we have right now work better (or at all)
19:04:19 <etoews> ni
19:04:21 <etoews> hi
19:04:35 <etoews> ++
19:04:40 <dhellmann> o/
19:04:46 <stevelle> o/
19:04:48 <terrylhowe> what about what is in the pipe
19:05:02 <terrylhowe> like quiming’s node
19:05:13 <briancurtin> terrylhowe: anything that is in there right now i'm fine with allowing it to go in
19:05:39 <briancurtin> anything entered after this i think we should -2 and hold off
19:05:46 <terrylhowe> k
19:06:00 <etoews> briancurtin: when you say resources above, do you mean not adding any new resources to existing services?
19:06:26 <briancurtin> no new services to be added, no new resources to existing services
19:07:10 <briancurtin> somewhat of an API freeze -- if we need to change how things behave that's fine, but don't grow  to support any new APIs
19:07:40 <etoews> so some of the services we ship for 1.0 would be incomplete
19:07:45 <briancurtin> probably
19:08:37 <briancurtin> if we get things in order i'm sure we could open it up, or if there are things out there right now that absolutely need other things to operate, we could make some exceptions as needed
19:08:49 <etoews> i'm okay with that
19:08:53 <briancurtin> i'd just rather our support not grow open ended at this point
19:09:20 <etoews> the exceptions being stuff like "oh, this service is completely useless without resource x"
19:09:25 <briancurtin> yep
19:09:57 <etoews> okay. functional tests, user guides, and examples will help inform the extent of uselessness.
19:10:08 <briancurtin> bingo
19:10:30 <briancurtin> anyone opposed to the general sentiment here?
19:10:54 <dhellmann> makes sense to me
19:11:08 <terrylhowe> #agreed
19:11:34 <briancurtin> #topic second meeting
19:11:49 <briancurtin> Qiming and the rest of the Senlin team is interested in coming to our meetings, but they're between 11-13 hours difference. I caught their Senlin team meeting from 0800-0900 US/Central time this morning
19:12:01 <briancurtin> As the project grows, we're going to need to reach more people anyway, so we're going to have to have two meetings at some point - not everyone can or has to make both meetings, but we'll just need to make sure everyone is aware of what's going on, and that decisions are appropriately handled inside and outside of meetings due to the increasingly distributed
19:12:01 <briancurtin> nature of the contributors
19:12:32 <etoews> let's play timezone roulette
19:13:23 <terrylhowe> early and late meetings might work like the api-wg
19:13:37 <briancurtin> i haven't looked at the schedule yet, but my first thought is to add a semi-weekly meeting that works for Qiming, and then maybe we cut this meeting back to semi-weekly so it's an alternating  time slot. could always keep this weekly, or even that weekly as well...i'm not really sure how that works around here
19:14:10 <etoews> the alternating meetings have not worked well at all for the api-wg
19:14:58 <etoews> the meeting that works well for asia is not well attended.
19:15:21 <briancurtin> etoews: should we just always have both, as in once a week there's a morning meeting and once there's an afternoon, and sometimes you just attend what you can attend?
19:15:45 <etoews> something like that would be preferable
19:16:08 <briancurtin> i guess we'd also have to be careful not to have hard decisions made at one meeting that leaves out the other group, or start using mailing list for some things
19:16:54 <dhellmann> briancurtin: yeah, it's probably best not to make decisions in the meeting if we're going to try to deal with timezones
19:17:03 <dhellmann> summarize issues and take them to the mailing list or spec reviews
19:18:12 <etoews> dhellmann: do you know where the meeting file lives?
19:18:27 <briancurtin> it's in a repo somewhere now
19:18:36 <etoews> ya. i just don't know where.
19:18:37 <dhellmann> etoews: git://git.openstack.org/openstack-infra/irc-meetings
19:19:11 <dhellmann> there are some basic instructions on http://eavesdrop.openstack.org
19:19:30 <dhellmann> but the readme in the repo has more details: http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/README.rst
19:19:48 <etoews> thx
19:19:55 <briancurtin> thanks dhellmann
19:20:34 <briancurtin> #action briancurtin will take a look at the schedule and try to find something that works for current team plus those on the other side of the world
19:20:53 <briancurtin> #topic find
19:21:06 <briancurtin> i think this was etoews: "There are a lot of open bugs regarding find. Let's see if we can nail down a path forward for find."
19:21:41 <etoews> yep. this seems like the last hold out of stabilizing the internal api.
19:22:09 <etoews> i don't have a strong opinion on it. just want to see it get sorted.
19:22:18 <briancurtin> after a change terrylhowe made, as well as the one i just put in to check the find results, it's probably just up to functional testing to find out what really works and doesn't
19:22:34 <etoews> nice
19:22:35 <terrylhowe> yeh
19:22:35 <briancurtin> im guessing once those two things are in, it's really down to resources that may not be using path_args stuff correctly
19:25:02 <briancurtin> beyond just writing tests, i don't think there's anything really left to figure out since i backed away from the fancy stuff i wanted to add (or it really applies more to list anyway)
19:25:16 <briancurtin> #topic create images
19:25:21 <briancurtin> etoews
19:26:10 <etoews> the glance api...
19:27:18 <etoews> so when you create an image you send the name in the request header because the image bytes go in the body
19:27:24 <etoews> meta_name = resource.header('x-image-meta-name')
19:27:40 <etoews> but the response has all of the info in the json body of the response
19:27:48 <etoews> name = resource.prop('name')
19:28:13 <etoews> you wind up with 2 fields that are the same thing.
19:28:39 <etoews> i just did that to hack something together that works
19:28:45 <etoews> obviously we don't want that
19:29:05 <etoews> i haven't even had a chance to consider solutions yet
19:29:19 <briancurtin> and the alias thing won't work here because one is a body prop and one is a header key
19:29:21 <terrylhowe> Just override create_* of some sort for Image seems like the easiest thing
19:29:49 <terrylhowe> I don’t think there is anything here that would be used anywhere other than v1 and v2
19:29:53 <briancurtin> yeah, something like that
19:31:00 <etoews> so create_image(self, **attrs) in _proxy stays as it is.
19:32:19 <etoews> then that _proxy method calls a create_* method on Image?
19:32:48 <briancurtin> yeah, it'll probably have to work similarly to how you've done things in the message service
19:33:16 <briancurtin> doesn't get the common self._create stuff out of the base class, has to go direct to what you've overridden. i think
19:33:48 <briancurtin> well, unless everything in the create_ is hooked up properly, you might be able to go through self._create in the proxy call
19:34:46 <etoews> i don't think you can go through self._create in the proxy call
19:35:17 <etoews> then the user had to know to set meta_name or name prior to calling the proxy
19:36:10 <etoews> right now i'm thinking take everything as a regular resource prop and translate it to headers depending on the context of the call
19:36:26 <terrylhowe> I was thinking the new create method would map name->X-image-name or whatever it is called
19:36:54 <etoews> yep. i think we're on the same page.
19:37:33 <etoews> but there *wouldn't* be a x-image-name field on the resource
19:37:40 <etoews> just name
19:38:31 <etoews> i'm good on this. we can move on.
19:39:27 <terrylhowe> sounds good to me
19:40:02 <etoews> /bump briancurtin
19:40:02 <briancurtin> #topic reauth on token timeout
19:40:06 <etoews> :)
19:40:30 <terrylhowe> did it work?
19:40:38 <etoews> 1 sec.
19:41:40 <etoews> yes and no
19:41:56 <etoews> i ran 4 "long" tests
19:42:30 <etoews> tokens expire in an hour for devstack so i hit the api with the sdk slept 2-3 hours then hit it again.
19:43:06 <etoews> it would reauth but in 2 of the 4 tests i got this error
19:43:08 <etoews> requests.exceptions.ConnectionError: ('Connection aborted.', error(54, 'Connection reset by peer'))
19:44:17 <terrylhowe> server disconnected an idle connection maybe
19:44:27 <etoews> there was also 1 weird result where it slept for 11.5 hours instead of 3
19:44:41 <terrylhowe> 54 though?
19:45:48 <terrylhowe> that must be the errno for the socket
19:46:29 <etoews> something like that
19:46:42 <etoews> it's definitely a googlable problem
19:48:20 <terrylhowe> think Transport should catch the 54 and retry one time?
19:49:06 <etoews> or a configurable amount of times.
19:49:13 <etoews> but maybe something
19:49:18 <etoews> i'll open a bug to track it.
19:49:38 <terrylhowe> excellent
19:49:47 <etoews> i'm pretty sure it's got nothing to do with token reauth and everything to do with the amount of time between requests.
19:51:14 <etoews> #action etoews log bug about connection reset
19:51:32 <etoews> /bump briancurtin
19:51:45 <briancurtin> #topic registering error handlers
19:52:00 <etoews> this was just an idea
19:52:16 <etoews> the reauth topic reminded me of it
19:52:21 <terrylhowe> like the 54 socket error?
19:52:39 <terrylhowe> or at some other level?
19:52:42 <etoews> or whatever
19:53:02 <etoews> whatever error that is
19:53:55 <etoews> we wrap that final call to requests with some code that will run an error handler registered by the user
19:54:24 <etoews> it's just a mechanism to allow users to handle weirdness in whatever envs they're running in
19:55:07 <terrylhowe> maybe just create a ticket and put it on the wishlist for after 1.0
19:55:20 <etoews> "for bizarre reason x they regularly get weird error y and they'd like the sdk to handle it some way at a low level"
19:55:33 <etoews> yep. definitely post 1.0.
19:55:33 <terrylhowe> part of me likes the idea, the other part thinks maybe the user should just do it themselves
19:56:35 <etoews> i know what you mean but that can for the user to write a bunch of high level error handling instead of a little bit of low level error handling.
19:58:19 <etoews> #action etoews to add registering error handlers to post 1.0 wishlist
19:58:30 <terrylhowe> yeh, it might save them writing wrapper or something which would be a pita
20:01:35 <etoews> /bump briancurtin
20:01:59 <etoews> thanks all
20:02:29 <etoews> i think brian might be having connection issues
20:02:46 <terrylhowe> thanks etoews, back to the sdk room I guess
20:03:36 <briancurtin> #endmeeting