19:00:09 <briancurtin> #startmeeting python-openstacksdk
19:00:09 <openstack> Meeting started Tue Jan  5 19:00:09 2016 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:13 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:39 <briancurtin> etoews: i made it
19:01:00 <etoews> hi!
19:02:27 <terrylhowe> o/
19:02:45 <briancurtin> i’m not sure what exactly to cover here other than maybe another walkthrough of https://launchpad.net/python-openstacksdk/+milestone/1.0
19:03:31 <etoews> sgtm
19:03:46 <briancurtin> only five things left that aren’t in-progress
19:04:02 <briancurtin> #topic https://bugs.launchpad.net/bugs/1466192 - Update contributor guide
19:04:05 <openstack> Launchpad bug 1466192 in OpenStack SDK "Update contributor guide" [Critical,Confirmed] - Assigned to Brian Curtin (brian.curtin)
19:04:50 <briancurtin> i guess that is sort of in progress in that i started sketching some things out, but don’t have a review up for it yet. shouldn’t be too hard, just need to formalize a bunch of the things we’ve all been doing anyway
19:06:21 <briancurtin> overall i want to be able to enable teams to come in and figure out what to do just based on that doc. a lot of stuff is fairly easy to figure out just by looking at something like compute, but we need to formalize a bunch of guidelines, such as how to name props and such
19:07:21 <etoews> definitely worthwhile. hopefully it'll save some review time too.
19:08:04 <briancurtin> seems like something that’ll take an afternoon to write, some time to massage, and hopefully a few quick passes through review to be done
19:08:53 <rtheis> o/
19:09:23 <briancurtin> #topic https://bugs.launchpad.net/bugs/1513679 - download_object needs to have the same API as get_object
19:09:26 <openstack> Launchpad bug 1513679 in OpenStack SDK "download_object needs to have the same API as get_object" [Critical,Confirmed]
19:10:35 <etoews> is https://bugs.launchpad.net/python-openstacksdk/+bug/1488631 a prereq for that one?
19:10:36 <openstack> Launchpad bug 1488631 in OpenStack SDK "Converge on upload/download names instead of create/save/etc" [Critical,In progress]
19:10:39 <briancurtin> i know i looked at this so it’s either not tagged or isn’t pushed yet, but is a quick one. additionally, there’s a review out there from last week where someone proposed taking a file stream instead of just a path, but the review doesn’t pass tests and is a little too involved. i’ll probably take a look at integrating
19:10:58 <briancurtin> etoews: yeah it’s a part of it
19:11:55 <etoews> what's left to be done on 1488631?
19:12:16 <briancurtin> looking
19:12:57 <briancurtin> etoews: probably nothing, but could use a quick look through the code to make sure nothing else has those names
19:13:12 <briancurtin> i think it was just image and object_store that had the problem
19:14:04 <briancurtin> #topic https://bugs.launchpad.net/bugs/1526516 - Catch all ksa exceptions and map them to SDK exceptions
19:14:06 <openstack> Launchpad bug 1526516 in OpenStack SDK "Catch all ksa exceptions and map them to SDK exceptions" [Critical,Confirmed]
19:15:39 <briancurtin> i just noticed this again today while running functional tests that i keep getting 409 conflict. not only do i not even know what that means, it’s just a pretty generic ksa exception
19:16:12 <briancurtin> i don’t know if we can get more info out of it, but it’d probably be confusing if someone saw a 409 conflict keystoneauth1 exception
19:16:58 <etoews> everyone will naturally assume it's a keystone problem whenever they see something like that
19:17:11 <etoews> makes for a lot of confusing bug reports
19:18:22 <briancurtin> i haven’t looked into this at all, but i’m not entirely sure how/where to solve this since we’re not doing anything of our own in making requests and handling responses, since it’s offloaded entirely to KSA
19:19:02 <briancurtin> maybe a global exception hook or something, although that seems dirty
19:19:42 <terrylhowe> I would think most changes would be in resource.py
19:20:14 <rtheis> How does occ or osc handle this?  Maybe sdk could do something similar if it makes sense
19:20:21 <briancurtin> no clue
19:20:32 <briancurtin> terrylhowe: actually yeah, good point
19:20:44 <etoews> where do all of the ksa exceptions live?
19:20:48 * etoews goes to look
19:20:48 <terrylhowe> osc just prints the exceptions
19:21:14 <terrylhowe> occ just looks for a list of valid plugins I think
19:21:24 <etoews> https://github.com/openstack/keystoneauth/tree/master/keystoneauth1/exceptions
19:22:09 <terrylhowe> well, if we at least catch the base class, that would be a good start
19:22:18 <terrylhowe> thanks for finding that etoews
19:22:37 <briancurtin> etoews: what terrylhowe said with handling in resource.py is maybe right, but it looks like they’re structured well enough that an excepthook could convert them somewhat easily
19:23:56 <etoews> well it doesn't really make sense to map exceptions like these https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/exceptions/http.py
19:24:09 <etoews> they're all just based on the http status code
19:24:48 <etoews> and a lot of the other exceptions in that package are actually specific to keystone
19:25:22 <briancurtin> perhaps there’s no clear catch-all thing to do here, but instead just make sure we take care of things appropriately in Resource methods
19:26:09 <briancurtin> we already do a small amount of that anyway, e.g., handling 404s and checking the ignore_missing flag
19:26:55 <briancurtin> in the case i mentioned above, i need to dig in and figure out what that 409 Conflict ordeal is and maybe come up with a decent case to solve it
19:28:25 <terrylhowe> If a helper class/method was developed, it would be fairly easy to test always map over the message attribute and sometimes http_status
19:29:36 <briancurtin> i think we’d probably want to coerce a more detailed response-code specific ksa exception down to HttpException - using the code and the status message from the KSA exc to create it
19:29:44 <etoews> and if we continue to have our own HttpException https://github.com/openstack/python-openstacksdk/blob/master/openstack/exceptions.py#L37 we should really map all of https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/exceptions/http.py to it
19:33:36 <terrylhowe> true
19:34:24 <briancurtin> etoews: do you mean a 1-1, or in that we handle KSA’s base HttpError and create our HttpException from it?
19:34:39 <etoews> base
19:35:28 <etoews> there really isn't a lot of value in giving each status code it's own exception like https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/exceptions/http.py does
19:35:49 <terrylhowe> Not each one, but 404 at least
19:35:54 <etoews> ya
19:36:19 <briancurtin> there are some common/special/meaningful cases like 404 that we can use separately, but yep, agreed
19:36:42 <briancurtin> i think we’re on the same page here, so whenever someone has time to write it up, go for it
19:38:19 <briancurtin> #topic https://bugs.launchpad.net/bugs/1494494 - Expose the full URL to an object in object_store
19:38:21 <openstack> Launchpad bug 1494494 in OpenStack SDK "Expose the full URL to an object in object_store" [Medium,Confirmed]
19:38:50 <briancurtin> i haven’t looked at this since KSA, but i also noticed something in object_store docs that might make this easier, so a combination of the two might be a lot easier than what i was looking at before
19:39:39 <briancurtin> #topic https://bugs.launchpad.net/bugs/1524466 - Corner "Report a Bug" links to wrong repo
19:39:41 <openstack> Launchpad bug 1524466 in OpenStack SDK "Corner "Report a Bug" links to wrong repo" [High,Confirmed] - Assigned to Anne Gentle (annegentle)
19:39:56 <briancurtin> anne isn’t in here, but etoews have you seen/heard anything about that?
19:40:08 <etoews> nada
19:40:34 <etoews> i can ping her
19:41:55 <etoews> i'll find out if the "release of the openstackdocstheme" part of that has been done
19:42:21 <briancurtin> cool
19:43:51 <briancurtin> anything else to cover? i’m mostly catching up on the last week or so of reviews and reviving a compute metadata change that i think is now good to go
19:44:16 <rtheis> when I go to http://developer.openstack.org/sdks/python/openstacksdk/, "Report a Bug" appears to link to https://bugs.launchpad.net/python-openstacksdk/ for me...  am I looking at the wrong doc?
19:45:02 <etoews> so it does :)
19:45:26 <briancurtin> oh, hmm. would be nice to change the summary text, but that’s pretty much good
19:45:39 <etoews> the "Welcome to the OpenStack SDK! in openstacksdk" seems unnecessary
19:46:04 <briancurtin> ah, that’s just the title of the page and the name of the project, so it’s maybe a decent starting point actually
19:46:40 <briancurtin> yeah when you dig in to other pages it names them as the page’s title
19:47:05 <etoews> that makes sense if you're logging bugs against docs i suppose
19:47:48 <etoews> i just marked it as fix released
19:48:16 <briancurtin> i guess if you’re using it as a quick way to find our launchpad it doesn’t make sense, but it’s probably better to fill in that title than nothing. if someone wants to file a code bug they’re probably ok with just deleting that stuff
19:51:46 <briancurtin> anything else?
19:51:56 <terrylhowe> nothing here
19:52:06 <etoews> i noticed some places where "save" is still used. fixing up now. then we can close out that one issue.
19:52:18 <rtheis> nothing here
19:52:25 <etoews> nothing else
19:52:31 <briancurtin> cool, thanks all
19:52:35 <briancurtin> #endmeeting