19:00:26 <etoews> #startmeeting python-openstacksdk
19:00:27 <openstack> Meeting started Tue Jul  7 19:00:26 2015 UTC and is due to finish in 60 minutes.  The chair is etoews. 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 <terrylhowe> o/
19:00:52 <etoews> good day terrylhowe
19:01:04 <terrylhowe> briancurtin: busy?
19:01:27 <etoews> i think he is...
19:01:40 <etoews> hopefully he'll be by later
19:01:59 <etoews> it's july so there's less and less people around
19:02:10 <etoews> i plan to be one such person soon too
19:02:15 <etoews> :)
19:02:43 <terrylhowe> no vaca plans for me, all work and no play
19:02:49 <stevelle> +1 that
19:02:51 <etoews> :(
19:03:05 <etoews> #topic previous meeting action items
19:03:48 * etoews 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:04:05 <etoews> not sure if he had a chance to do that...
19:04:17 * etoews etoews log bug about connection reset
19:05:02 <etoews> done. #link https://bugs.launchpad.net/python-openstacksdk/+bug/1470236
19:05:02 <openstack> Launchpad bug 1470236 in OpenStack SDK "ConnectionError: ('Connection aborted.', error(54, 'Connection reset by peer'))" [Undecided,Incomplete]
19:05:40 <etoews> sigmavirus24 and cory followed up on it very quickly and i haven't had a chance to give it another look :(
19:06:17 * etoews etoews to add registering error handlers to post 1.0 wishlist
19:06:39 <etoews> done. #link https://bugs.launchpad.net/python-openstacksdk/+bug/1470243
19:06:39 <openstack> Launchpad bug 1470243 in OpenStack SDK "Register error handlers" [Undecided,New]
19:07:11 <etoews> that's that
19:07:24 <etoews> #topic version negotiation
19:07:57 <etoews> as i was beating my head against glance, i stumbled on some version issues.
19:08:18 <etoews> first was just figuring out how to specify a particular version of an api
19:08:37 <etoews> but that lead me to the question of version negotiation
19:08:47 <etoews> i found this
19:09:18 <etoews> Version discovery #link https://bugs.launchpad.net/python-openstacksdk/+bug/1353031
19:09:18 <openstack> Launchpad bug 1353031 in OpenStack SDK "Version discovery" [Undecided,Invalid]
19:09:32 <etoews> but it's marked as invalid and i'm not sure why
19:09:51 <etoews> we're definitely going to need version discovery/negotiation in some respect
19:10:12 <terrylhowe> because the blueprint, but right now I’m in favor of ignoring blueprints and using bugs so there is one place to track issues
19:10:35 <terrylhowe> if things get more complicated, we could start using blueprints again
19:10:56 <etoews> that works for me
19:10:56 <terrylhowe> so, the version you want to use does not show up in the version catalog?
19:11:57 <etoews> there are more versions in the catalog than what we allow for (in glance)
19:12:18 <etoews> i just stumbled across them poking around the api
19:12:32 <etoews> 1 sec.
19:13:44 <etoews> http://paste.openstack.org/show/352788/
19:14:26 <etoews> it was interesting see there's version all the way up to 2.3
19:14:38 <etoews> the url for all of them are /v2
19:14:59 <etoews> which is fine
19:15:44 <terrylhowe> version should be set to 2 then?
19:15:44 <etoews> but stuff could be added to 2.3 that we just have no idea about. obviously none of it should be backwards incompatible though.
19:16:44 <etoews> that's kind of at the heart of the issue.
19:16:44 <terrylhowe> seems like if fields were added to resources, we could just add them and people could use them if desired in that situation
19:16:53 <etoews> ya
19:17:25 <etoews> but they won't even know what *actual* version of the api they're using.
19:17:31 <terrylhowe> we have fields in some resources for extensions, similar kind of situation
19:17:33 <etoews> and i'm not even 100% certain that matters.
19:18:15 <etoews> let me throw this question out there
19:18:45 <etoews> if we did some form of version negotiation, would it even necessarily affect the public interface of the sdk?
19:19:18 <etoews> is it the kind of thing you wind up exposing to the user?
19:20:04 <etoews> i guess i'm asking i we think it's something necessary for 1.0
19:21:01 <terrylhowe> in cases like this, I’d kind of like to leave it up to the user a little to keep things simple.  we don’t want to burden everyone with querying the versions interface all the time.
19:21:34 <terrylhowe> if someone cares, they can hit the interface and decide what they want to populate for these point releases
19:22:11 * briancurtin is here
19:22:40 <etoews> which interface exactly in "hit the interface"?
19:23:42 <terrylhowe> the top level versions interface
19:24:38 <etoews> ...of the sdk. right?
19:26:10 <terrylhowe> well, the sdk often has a versions.py resource for that
19:26:33 <terrylhowe> we should probably do some nice support for it in the proxy
19:27:25 <etoews> so the user could conceivably do their own version negotiation using version.py for a particular service
19:28:13 <etoews> alright. is there anything to do here then?
19:28:32 <terrylhowe> version.py support for the proxy at least
19:28:56 <etoews> terrylhowe: care to file a bug for it?
19:30:21 <terrylhowe> https://bugs.launchpad.net/python-openstacksdk/+bug/1472373
19:30:21 <openstack> Launchpad bug 1472373 in OpenStack SDK "Support Version Resource in Proxy" [Undecided,New]
19:30:34 <etoews> ++
19:30:34 <etoews> #topic drop glance v1 support
19:31:20 <etoews> see the agenda for a relevant conversation from #openstack-glance on the subject https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda
19:32:14 <etoews> when it comes to image create/update the v1 and v2 apis do things completely differentyl
19:32:35 <stevelle> very true
19:32:35 <etoews> that had me wondering whether we want to expend the effort to support v1 at all
19:32:51 <etoews> considering it seems to be on its way out the door
19:33:02 <briancurtin> i'm in favor of dropping it if possible
19:33:32 <stevelle> etoews: I believe the plan is to seriously consider introducing the deprecation of v1 in M cycle, so it will be around a bit
19:33:42 <etoews> keeping it around effectively encourages users to keep using a deprecated api
19:34:12 <etoews> stevelle: gotcha. but we don't want to encourage its adoption by supporting it. imo.
19:34:35 <etoews> if somebody really needed it we could always put it back in.
19:34:37 <stevelle> I would agree that if we don't have complete support for the full v1 API that wouldn't be terrible.
19:34:53 <stevelle> I wouldn't want to see us cut it entirely, for now.
19:35:06 <etoews> stevelle: are you aware of anywhere it's being used?
19:35:38 * etoews gets a bit over-excited when it comes to talking about deleting code
19:35:43 <stevelle> using the SDK support, no I'm not.
19:35:50 <stevelle> using the Glance v1, yes
19:36:11 <etoews> okay. any examples of the top of your head?
19:36:28 <terrylhowe> we use v1 in public cloud.  I don’t think it is exactly v1 though
19:36:29 <etoews> i'm just trying to gauge if those example would necessitate sdk support.
19:36:51 <terrylhowe> feel free to mark it as deprecated though
19:36:55 <etoews> terrylhowe: interesting. i checked hp's site and couldn't find any mention of it.
19:36:57 <terrylhowe> just don’t delete it
19:37:15 <terrylhowe> Well, I don’t think it is in Helion
19:37:16 <stevelle> I would say 90% of operators I spoke to in Vancouver have v1 deployed. About 80% probably had v1 only.
19:37:18 <etoews> maybe it's just not exposed publicly or did i miss it?
19:37:33 <stevelle> but that was a self-selecting group that approached me
19:37:46 <etoews> stevelle: still, that's significant.
19:38:36 <stevelle> I encouraged every one of them to work on getting onto Kilo soon and to deploy v2.
19:38:54 <etoews> so what are we saying? keep what's there for v1 currently but mark it as deprecated and only put effort into v2?
19:38:59 <stevelle> none of them needed something that wasn't better in v2.
19:39:27 <etoews> the double negative there is messing with me
19:39:47 <stevelle> sorry
19:40:06 <stevelle> none of them needed changes-since
19:40:31 <etoews> i.e. v1 does what they need so why upgrade?
19:41:38 <etoews> so we keep what's there for v1 currently but mark it as deprecated and only put effort into v2?
19:41:55 <terrylhowe> sounds good, if some cares, they can work on v1
19:42:01 <stevelle> I think that would be fine. I might lean towards v1 is "unsupported"
19:42:11 <stevelle> until Glance formally deprecates v1
19:42:52 <stevelle> If we don't feel that is a useful distinction I would be fine with just deprecating now.
19:44:53 <etoews> stevelle: how would we mark it as unsupported? just something in the docstrings?
19:45:24 <briancurtin> etoews: probably use the warnings module as well and have things show up in logs, in addition to docstrings
19:45:36 <stevelle> etoews: I suppose so. That brings up the point of "nobody reads docs" again, though
19:45:42 <briancurtin> that's their fault
19:45:56 <stevelle> I like that response
19:47:09 <etoews> dang. so here's the rub. right now it's broken as is. create/update simply do not work.
19:47:12 <stevelle> I don't have a strongly held opinion either way, but we should be able to decide
19:47:48 <etoews> do we really want to release broken, unsupported code?
19:47:55 <terrylhowe> set allow_create and allow_update to false I guess
19:48:19 <terrylhowe> I’d like to be able to list images on a v1 system
19:48:30 <etoews> hmmm...that is a quick way out.
19:48:44 <stevelle> +1 terrylhowe
19:48:46 <etoews> i'm okay with that.
19:48:52 <briancurtin> yeah, that works
19:49:15 <stevelle> file a bug, mark it wishlist, include reference in a code comment?
19:49:28 <etoews> #action etoews to file a bug to mark glance v1 as unsupported
19:49:44 <etoews> i'd say no wishlist. this is happening.
19:50:20 <etoews> #topic big tent
19:50:22 <stevelle> disregard my last line. ready to move on
19:50:41 <etoews> oops. sorry i rushed the new topic there.
19:51:12 <etoews> Example governance: https://review.openstack.org/#/c/188014/
19:51:20 <etoews> Example git namespace change: https://review.openstack.org/#/c/197672/
19:51:43 <etoews> i had planned on writing up the proposal this week.
19:52:11 <etoews> but my vacation starts friday afternoon and i won't be around to follow up on comments
19:53:06 <etoews> should i still go for it now and you all can address the comments or wait till i get back from vacation (july 21)?
19:53:28 <briancurtin> i think we can address it
19:54:08 <etoews> okay. i'll try to work something up once i'm done with this glance stuff.
19:54:22 <etoews> #topic multi-region testing
19:54:54 <etoews> we haven't done any functional multi-region testing have we?
19:55:06 <briancurtin> i haven't
19:55:27 <etoews> i did a bit with the message service stuff on rackspace
19:55:31 <terrylhowe> I’ve hit different regions if that’s what you mean, but it has been a while
19:55:43 <briancurtin> ive done some manual testing against a multi-region cloud (rackspace) and saw that some things are not properly working, as in we're getting the wrong region in some cases
19:55:51 <terrylhowe> maybe we could set up a simple automated test to do something
19:56:02 <etoews> i was getting queues created in hong kong that were supposed to be created in northern virginia
19:56:03 <briancurtin> although i dont know if that was a pure SDK thing or if i did something wrong in our plugin
19:56:08 <briancurtin> yep
19:56:17 <briancurtin> i haven't looked back to that one
19:56:17 <etoews> i don't think it was the plugin
19:56:37 <etoews> i'll search for a bug and file one if there isn't one.
19:56:49 <briancurtin> i have been able to properly switch the region and get the right compute info back, but message was always in teh wrong spot
19:57:10 <stevelle> I am planning to do some multi-region stuff with object storage real soon now but it will be rather ad-hoc
19:57:49 <etoews> cool. let us know how it goes.
19:57:57 * etoews is determined to get through all the topics
19:57:59 <briancurtin> etoews: i dont think there is a region bug, there in probably a similar area, i have a bug out for properly finding versioned endpoints
19:58:28 <etoews> #topic vacation
19:58:53 <etoews> just a quick note, i'm on vacation from july 10-21 and july 29-aug 5.
19:59:17 <briancurtin> enjoy
19:59:20 <etoews> basically consider me out until early aug
19:59:22 <etoews> :)
20:00:19 <etoews> #endmeeting