19:00:24 <briancurtin> #startmeeting python-openstacksdk
19:00:25 <openstack> Meeting started Tue Jun 23 19:00:24 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:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:29 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:37 <terrylhowe> o/
19:00:39 <briancurtin> if you're here for the SDK meeting, say hi
19:01:16 <etoews> o/
19:02:10 <briancurtin> #topic Add Heat resource support
19:02:15 <briancurtin> #link https://review.openstack.org/#/c/181063/
19:02:32 <stevelle> o/
19:02:54 <briancurtin> i think the last patchset addressed etoews concern, and i think overall it looks alright. it'll end up changing a bit later depending on what happens with find, but should go on as-is if it works
19:03:08 <etoews> +1
19:03:58 <dhellmann> o/
19:04:13 <terrylhowe> on my todo list to look at that one, but it was real close before
19:04:20 <etoews> cool.
19:04:40 <briancurtin> #topic marking APIs as Beta in the SDK
19:04:45 <briancurtin> not sure who put this in - anyone?
19:04:55 <etoews> that was me
19:05:07 <etoews> reasoning...
19:05:58 <etoews> we put a bunch of code into the sdk and release it. even though we're pre 1.0 and instability *should* be assumed. it's hard to tell what's stable and what isn't.
19:06:11 <etoews> this topic is actually more important post 1.0
19:06:42 <etoews> we'll be putting code in post 1.0 and users will have no way to know what's stable and what isn't
19:06:57 <etoews> since it all winds up getting released
19:07:16 <terrylhowe> we could start a plugin repo for new dev
19:07:30 <briancurtin> then it all falls apart like the current mess
19:07:32 <etoews> perhaps we can mark entire services as beta?
19:07:40 <briancurtin> current mess meaning *clients
19:07:59 <etoews> we went down the "alternate" repo path with jclouds. it was horrible.
19:08:25 <stevelle> this seems related to the next agenda topic
19:08:28 <briancurtin> etoews: within CPython we have the idea that new APIs can be added for one or more releases in a provisional state. i believe the ipaddr module went in like this
19:08:45 <etoews> that's the kind of thing i had in mind
19:09:03 <briancurtin> as for versioning, i think we probably just have to be super strict on version numbers and grow like browsers do, where we'll be on version 35 at this time next year
19:09:18 <briancurtin> or does that not solve what you're looking for etoews?
19:10:01 <etoews> i'm not as concerned with semver (although i do like it) but more of a way of signaling to users that something isn't fully baked yet.
19:10:33 <etoews> for instance, i'd be fine with not incrementing major version if it was a beta api that we were breaking backwards compat with.
19:10:54 <briancurtin> on that, then i'd probably stick with the provisional thing. in CPython that's really just signaled within teh PEP that added something, as well as in documentation. i wouldnt mind some kind of decorator that logged a message saying it's a provisional API, or the warning module to emit something
19:11:08 <etoews> ++
19:11:32 <briancurtin> i know someone is going to say "but people don't read the docs" and the answer is "too bad"
19:12:02 <etoews> isn't that what emitting something would be for?
19:12:55 <briancurtin> etoews: assuming people pay attention to them, and i forget what the situation is with warnings showing up in the default case of just running "python"
19:13:24 <briancurtin> i know DeprecationWarning is silenced by default and you have to explictly turn warnings to be louder to get it. not sure about other types, or custom types
19:13:44 <etoews> well anything, it becomes more import post 1.0. i'll log a bug to keep track of it.
19:13:49 <briancurtin> cool
19:13:51 <etoews> s/anything/anyway/
19:14:26 <briancurtin> #topic functional testing of "non-core" service
19:14:33 <briancurtin> "can openstack.tests.functional.base.requires_service be changed to wrap an entire test class?"
19:14:46 <etoews> me again
19:14:50 <briancurtin> that answer is yes, it can be a class decorator
19:15:05 <stevelle> I'd like to decide what might be provisional from the previous discussion. Is this topic a good place to do that?
19:15:13 <briancurtin> etoews: are we going to bother defining core/non-core, or does this just mean stuff that doesn't show up in a usual devstack?
19:15:29 <briancurtin> yeah actually let's pause this for a second
19:15:33 <etoews> usual devstack is the answer i think
19:15:48 <briancurtin> stevelle: may as well, we've got the time
19:16:12 <briancurtin> etoews: any specific example of something you'd want to put through a provisional state?
19:16:27 <etoews> basically anything new
19:16:37 <etoews> for example...
19:17:00 <etoews> i was doing the message service and i got the interface wrong the first time around.
19:17:28 <etoews> a release could have happened before i had a chance to fix it
19:17:45 <etoews> now i've got someone thinking they can depend on this crappy interface
19:17:58 <etoews> and i come along and change it in the next release
19:18:24 <stevelle> ok, I just wanted to clarify.  Are there OpenStack services in the sdk that we believe are currently in a provisional state?
19:18:33 <etoews> i just want to be able to signal to users that certain services are under development and to expect a bumpy ride
19:19:13 <stevelle> this is a great topic, as it also helps identify where the project team can apply resources as well
19:19:14 <etoews> heat
19:19:23 <etoews> message
19:19:32 <briancurtin> stevelle: im not really sure if any entire services are like that
19:19:48 <briancurtin> etoews: i think we're on the same page with how you're thinking of this
19:19:49 <etoews> it's still so early on in the development of those i'm not confident the interfaces are stable
19:20:57 <etoews> but again we're pre 1.0 so it's kinda all fair game.
19:21:18 <briancurtin> good to think about though. we have somewhat of a free pass right now but real life starts fairly soon
19:21:24 <etoews> not that i think we're due for any huge interface changes
19:21:47 * etoews looks forward to real life
19:21:48 <briancurtin> as we get around to more functional tests im sure we'll run into stuff that just does not work at all as-is, and will need to be changed around
19:22:18 <terrylhowe> yeh, that’s why it is taking so long to write teh functional tests
19:22:20 <etoews> more functional tests for the functional test god
19:22:52 <terrylhowe> once we get a lazy load for the modules, that would be a good point to put up some warning on deprecated/beta services
19:22:57 <briancurtin> we're at the point now where no resource/proxy changes should go in without functional test changes as well
19:23:05 <stevelle> and we are not thinking about provisional tag for things that don't work or are not insufficiently tested, just for things that may have api changes at proxy or above, right?
19:23:10 <etoews> terrylhowe: when you say that is it because things are changing out from underneath you?
19:23:12 <briancurtin> (i guess we've been there a while and i think a few people have said that...but anyway)
19:23:34 <stevelle> not/insufficiently*
19:23:54 <terrylhowe> no, the proxies were never really functionall tested in a lot of cases and they just don’t work
19:24:19 <briancurtin> stevelle: things that don't work should just be pulled out, i woudnt want to cover up bugs with this. once we get to a better level of functional testing this tag might make sense
19:24:30 <etoews> ah. yes. i work under the assumption that if there's no functional test it's most likely broken.
19:24:38 <briancurtin> it should really only be used as an excuse for the API changing, not the behavior
19:26:23 <briancurtin> we especially  have the broken proxy issue when it comes to most anything that needs path_args
19:26:35 <briancurtin> but we'll get around to those, or are getting around to those
19:27:38 <stevelle> I forget if we have a coverage report for functional tests
19:27:48 <stevelle> I don't believe I recall seeing one
19:27:50 <briancurtin> not currently, but should add it. only unit test now
19:28:27 <briancurtin> will have to figure out how to configure it since we'll want it to only report based on proxy classes and not the entire openstack namespace
19:28:56 <stevelle> got it.
19:29:15 <briancurtin> should get back to "functional testing of "non-core" service"
19:29:25 <stevelle> I think we can return to the functional testing topic yes
19:29:32 <briancurtin> etoews: so what else did you have in mind here?
19:30:06 <etoews> mostly just being able to requires_service at a class level.
19:30:34 <etoews> i've got a bunch of message functional tests but haven't committed them because a call per method is so slow.
19:30:37 <briancurtin> that shouldn't be too bad, and we should actually put that on every single class just to be safe and not assume anything is actually there
19:31:07 <briancurtin> etoews: i can look into that right after this then
19:31:14 <etoews> cool. thx.
19:32:14 <terrylhowe> may be related to this topic.  I was wondering if we could get rid of setupClass teardownClass because of the change in tox.ini
19:32:37 <etoews> in the base functional class?
19:32:41 <terrylhowe> I’d like to try again.  I made that change originally before all tests from one class were forced to one thread
19:33:14 <briancurtin> i'm not familiar with a change to tox.ini that would affect those methods
19:33:14 <etoews> i noticed that ostestr has a --serial param
19:33:27 <etoews> that could be handy for functional tests
19:33:39 <terrylhowe> yes
19:34:08 <terrylhowe> anyway, I’d like to explore the standard format again, but there is a lot out there at the moment
19:36:06 <briancurtin> #topic Resource.find
19:36:11 <terrylhowe> somewhat related ostestr has a bug I don’t think the fix has been released, probably only on ubuntu https://review.openstack.org/#/c/187300/
19:36:15 <briancurtin> #link https://review.openstack.org/#/c/193728/
19:36:56 <briancurtin> i haven't seen that one, running on osx
19:37:42 <terrylhowe> I kind of figured most people were on osx
19:37:44 <briancurtin> with this Resource.find, terrylhowe i'm not sure if you saw my response to your comment about it working like the previous one, but i wonder if we shouldn't push the "find one item by name or id" off to each of the get_* methods in a proxy?
19:38:04 <stevelle> I test under ubuntu fwiw
19:39:33 <briancurtin> we could just change the from_id method to be a little smarter, or something else has that behavior that knows per-resource if it's name or id that matters, and you'd only get one resource back or nothing. i think we briefly talked about that a while back but didn't go that route
19:40:10 <briancurtin> i'm thinking about that because find running a query based on list makes me think find_* methods should actually be plural, since they are running regex queries that would return multiple items
19:40:23 <terrylhowe> the whole find thing I’m not really ready to deal with.  I haven’t added functional tests for most of them
19:40:37 <briancurtin> i wouldnt even do that because they will all break
19:40:48 <briancurtin> most of them are broken as-is and we'd just break them more
19:40:50 <terrylhowe> having find return multiple items makes me think it should be just part of list
19:42:08 <briancurtin> As in, we should add this behavior to list and then make the current find better?
19:43:23 <briancurtin> maybe this does make sense, as list+query params (when available) does this
19:43:31 <terrylhowe> anytime you are searching for some resource, unless by id (or maybe name) you could get multiple responses
19:44:22 <briancurtin> i'll see how i can shift this over to list to make up for the ones that don't support query params, or even supplement the ones that do
19:44:55 <terrylhowe> I’d just like to see something like if (queryparam): slow client side search else: high perf generator
19:45:34 <stevelle> +1
19:45:36 <terrylhowe> since support is so terrible for query params, it seems like we could just pertend they don’t exist at all for now
19:46:05 <terrylhowe> and just do the filtering client side
19:46:11 <stevelle> I'd also be happy with just delegating the filtering to the consumer of the list as well tbh
19:47:11 <briancurtin> inserting our own search in between the proxy call and the resource.list when query params aren't supported shouldn't be too hard. anything we can let the server do to reduce the data returned and work faster i think we should try to enable
19:47:36 <terrylhowe> if it isn’t too much work, great
19:48:22 <stevelle> just as a note, it seems appropriate to bring up the filtering guideline from the API-WG here.
19:49:07 <stevelle> https://review.openstack.org/#/c/177468/
19:49:13 <briancurtin> filtering as in reducing the fields returned, or filtering as in reducing the amount of resources returned?
19:49:26 <stevelle> resources returned
19:50:35 <stevelle> would like to be sure we are providing the best guidance for services to make this support better in the future.
19:50:41 <briancurtin> i'll take a look, but isn't that a server-side thing? i'm not entirely sure what the takeaway of that would be here
19:50:47 <briancurtin> oh
19:51:19 <stevelle> particularly, as terrylhowe points out, support is currently spotty at best
19:53:25 <terrylhowe> may be we should have some way the customer asks for server or client side filtering manually
19:54:28 <briancurtin> i was just thinking about solving some of this with a local=bool flag, but probably not even exposing that at the proxy level. at the proxy level we'd know if a resource can do server-side querying and send those args through, or we pass it through the local query. similar to how we have to set paginated=bool for them at that levlel
19:55:10 <etoews> local=bool seems like a cognitive burden on the user
19:55:35 <briancurtin> it wouldnt be on the user, it would be handled the same way paginated=bool is right now
19:55:49 <etoews> ah
19:56:14 <etoews> missed the "not even exposing that..."
19:58:28 * briancurtin blows whistle for 2 minute warning
19:59:35 <terrylhowe> nothing else here
20:00:08 * briancurtin sounds a loud horn
20:00:14 <briancurtin> #endmeeting