19:00:19 <briancurtin> #startmeeting python-openstacksdk
19:00:20 <openstack> Meeting started Tue Mar 31 19:00:19 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:23 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:44 <etoews> o/
19:00:47 <terrylhowe> o/
19:00:54 <briancurtin> if you're here for the SDK meeting, say hi
19:01:07 <dstufft> o/
19:01:46 <briancurtin> #topic Functional Testing
19:01:54 <briancurtin> #link https://review.openstack.org/#/c/169405/ - Moving unit tests
19:02:03 <briancurtin> so, how exactly do we want to do this?
19:02:29 <briancurtin> terrylhowe: is that devstack setup pretty much ready to roll?
19:03:17 <stevelle> o/
19:03:26 <terrylhowe> I was thinking of moving it to examples
19:03:37 <terrylhowe> it could be generalized a bit more too
19:03:40 <briancurtin> and i guess how is it going to work, like where is the vm going to come from that it's running on? is it as part of teh gate or something we'll run locally to point to our own accessible clouds?
19:04:23 <briancurtin> terrylhowe: just as an example of setting up devstack, or for using it? if we're using that for anything i dont think it should be in examples, but we can point to it in documentation as an example usage that we actually depend on
19:04:44 <etoews> one way or the other we'll always need something we'll run locally to point to our own accessible clouds
19:05:46 <terrylhowe> I think for gates you can just opt for the projects you want added to devstack and you get control when it is ready
19:05:56 <briancurtin> seems like maybe it should be in something like openstack/tests/utils?
19:06:19 <terrylhowe> I do think it would be nice to have at least a template for local.conf or something that everyone can use
19:06:31 <etoews> yes
19:06:33 <terrylhowe> maybe that is a good place
19:06:35 <etoews> terrylhowe: +1
19:06:54 <etoews> that's kind of the minimum thing we'll need to agree on
19:07:19 <briancurtin> maybe we should work backwards from what we actually want to be testing. is this intended to be something live like create a container with some metadata, get the metadata and confirm it, add some objects, list them and confirm they're there, then delete it all?
19:07:39 <etoews> that's what i had in mind
19:08:01 <terrylhowe> yeh, basic crud testing for each resource
19:08:03 <etoews> and the tests run sequentially because of the crud operations
19:09:04 <etoews> eventually we'll need to be able to run the functional tests against hp and rackspace and other public clouds but for now we just start with devstack
19:10:03 <etoews> the patch i'm working on for after moving the unit tests is to just run 1 simple functional test
19:10:10 <briancurtin> yeah, that eventually gets into the plugin stuff and third-party CIs and all of that jazz
19:10:15 <briancurtin> etoews: cool
19:10:46 <etoews> the trick will be getting only the functional test to run
19:10:51 <terrylhowe> just being able to list flavors or something simple would be great
19:11:02 <etoews> yep. something like that.
19:11:19 <etoews> i'll also be using os-client-config
19:11:27 <etoews> it's simple enough
19:11:38 <briancurtin> etoews: i haven't toyed around with tox setups in a while, but i think we just need a separate group of test envs that point to a different test directory
19:11:55 <briancurtin> and we probably have to tell the current one to be more explicit about where to look
19:12:04 <terrylhowe> osc is using the —os-cloud option for os-client-config
19:12:10 <etoews> briancurtin: i was digging into it this morning and looking for options
19:12:41 <etoews> terrylhowe: i'm not familiar with the --os-cloud option. what is it?
19:12:43 <etoews> link?
19:12:46 <briancurtin> etoews: i hadn't had time to try it myself, but i posted on the review for the changedir option
19:13:02 <etoews> briancurtin: i'll give that a try
19:13:19 <terrylhowe> https://review.openstack.org/#/c/129795/
19:13:21 <briancurtin> i believe right now it's starting in the root for discovery, we just have to tell it to jump a few levels deeper, as far as i know
19:13:28 <terrylhowe> ^^ that is the osc review of os-client-config
19:13:47 <terrylhowe> I was hoping we’d add support in the examples and use that for the functional tests
19:14:24 <terrylhowe> we don’t want os-client-config as a dependency of the project, but test dependency is fine
19:15:01 <etoews> yep. i only have it in test-requirements.txt right now.
19:15:09 <terrylhowe> cool
19:16:08 <etoews> so are we okay with moving the unit tests into there own sub-dir?
19:16:16 <etoews> s/there/their/
19:16:32 <terrylhowe> yeh, I just have to get over the extra u<tab>
19:16:52 <briancurtin> i think we should, as it'll allow us to group them separately from other types of tests, functional or otherwise. just requires a little extra step in tox
19:17:22 <briancurtin> whether it's that changedir setting or something else
19:17:26 <etoews> as long as we don't name the other sub-dir unctional it should be too bad for tab completion :)
19:17:41 <etoews> s/should/shouldn't/
19:17:49 <terrylhowe> :)
19:18:09 <briancurtin> #topic Removing httpretty
19:18:18 <briancurtin> #link https://review.openstack.org/#/c/164837/ -- remove httpretty from Transport tests
19:18:43 <briancurtin> that's the last remaining "roadblock" to its removal, save for object_store tests, which have to be changed as a part of the great API change anyway
19:19:28 <briancurtin> i would rather just let the object_store tests hold on to httpretty for right now and then they'll be changed once we apply the APIs, rather than doing test changes twice for it
19:19:55 <briancurtin> unless httpretty manages to release yet another broken version...
19:20:50 <terrylhowe> sounds good
19:20:56 <briancurtin> the nice thing about revisiting the mocks is that we dumped a lot of mocked requests by just mocking the session itself, which turned out better where possible
19:21:15 <jamielennox> just thought i'd snoop and saw the topic - dump httpretty - try requests-mock
19:21:27 <briancurtin> jamielennox: yep, that's what we did
19:21:39 <jamielennox> :) carry on
19:22:00 <briancurtin> jamielennox: although we had a few places that didn't really need httpretty in the first place, so we bypassed requests-mock for those. it is pretty nice where we've needed it, though. nice work
19:22:35 <jamielennox> thanks - a complete reaction to how much of a pain httpretty was
19:23:41 <briancurtin> #topic compute metadata
19:24:37 <briancurtin> if anyone has some spare cycles, steve +1ed both of these: https://review.openstack.org/#/c/163639/ is the base, and https://review.openstack.org/#/c/163640/ is the application to Server metadata. we would also use that to create Image metadata, and i think there's another type of metadata in compute that would build off of it
19:26:23 <briancurtin> #topic Common API changes
19:27:34 <briancurtin> Any of the "Common <action> method" reviews are ready to be reviewed. Already had a few +1s on the delete one. i pushed a bunch more patchsets after that while building out that decorator, but it hasnt really changed the behavior of get or delete reviews, was more for the create one and the update one i'm working on now
19:28:44 <briancurtin> update is going to require a little more love since i'm trying to play nice between instances and IDs, but also preserving attributes when it's an instance so we make use of the dirty list and don't make calls we might not need to (right now if you just keep updating the name to the same thing it'll make that meaningless call, but i'm fixing it)
19:28:48 <stevelle> will get them this week
19:28:58 <terrylhowe> yeh, I was on vacation all last week, so I’m a little behind.
19:29:26 <briancurtin> yep, all good, just saying those ones aren't as work-in-progress as they first were since they're the easier of the guidelines to have applied
19:33:17 <briancurtin> the one left that i haven't touched yet is the pagination calls. everyone seemed to be cool with making the method name the plural of the resource, e.g., servers, containers, images, stacks. doug mentioned potentially query_resources, which i sort of liked, but having worked with the objects/containers methods a ton, ive really enjoyed that naming
19:34:03 <etoews> it certainly looks the most natural when you have it in a loop
19:34:34 <stevelle> +1
19:34:38 <etoews> otoh it breaks away from the verb_resource naming scheme
19:35:36 <etoews> i don't feel too strongly about it honestly
19:37:17 <briancurtin> calling them get_resources wouldnt be horrible, but it's so close to get_resource, and it feels like the general use cases for the listing APIs is either a loop or something consuming a generator, so the slightly shorter name fits really well
19:38:07 <briancurtin> get_resources is probably the only other really feasible way. list is out, query is kind of odd unless you're actually passing in query params. i guess we'll see when the review is up what the final verdict is
19:38:33 <etoews> -1 query_resource
19:39:43 <briancurtin> yeah, it presents a different action for similar things. if and only if you're using the query params it seems nice. also makes it seem like you're potentially digging into the resources themselves instead of getting topical info about them
19:40:36 <etoews> right
19:41:34 <briancurtin> any other outstanding topics or reviews to cover for now?
19:42:07 <etoews> bump #link https://review.openstack.org/#/c/162761/
19:42:18 <briancurtin> need to look back at plugin and service discovery soon, but want to get the APIs sorted out much sooner than later
19:42:25 <briancurtin> oh yeah, that one
19:43:00 <etoews> terrylhowe: thoughts on ^
19:43:28 <terrylhowe> I’m still not a big fan of logging the request multiple times on a redirect, but it isn’t a huge deal either
19:44:07 <briancurtin> i think we'd probably want to be able to track each of the steps of the redirect, so we'd probably need the subsequent requests
19:44:20 <briancurtin> otherwise i think it ends up being sort of a black box how we got to the end
19:44:32 <briancurtin> as far as i understand what's going on there
19:44:45 <etoews> that's the short of it
19:45:09 <etoews> multiple requests are being made on a redirect so log those requests to reflect reality.
19:45:33 <terrylhowe> well, the request isn’t going to change, just the url
19:45:52 <stevelle> redirects at debug makes sense to me.
19:46:02 <stevelle> at least noting they happened
19:46:48 <etoews> pinging dtroyer sigmavirus24 on https://review.openstack.org/#/c/162761/
19:47:05 <sigmavirus24> sorry. in video meeting and missed th emeeting invite
19:47:05 <briancurtin> well, we hope the request isn't going to change (i have no idea if it's possible/realistic to be changing it, but i guess it could happen)
19:48:13 <terrylhowe> anyway, it isn’t a huge deal
19:48:55 <etoews> cool
19:50:35 <briancurtin> anything else going on?
19:50:45 <sigmavirus24> uhm
19:50:56 <sigmavirus24> so redirect logic in requests is different than most expect
19:51:04 * sigmavirus24 is still catching up, sorry
19:51:21 <briancurtin> yeah we don't use it
19:51:24 <sigmavirus24> okay
19:52:03 <etoews> should something be done with #link https://review.openstack.org/#/c/135104/ Add coverage-package-name to tox.ini for coverage
19:52:15 <briancurtin> that _send_request method has a reimplementation to avoid requests' way of doing it
19:52:53 <briancurtin> etoews: i'll revisit that. there was some difference in package availability on ubuntu or something
19:53:27 <etoews> no biggie. just looking to sweep out the queue.
19:54:57 <briancurtin> yeah i have a few others to clean out, just abandoned an old WIP that was superseded by the current common reviews
19:55:34 <terrylhowe> there is a pretty big backlog in general right now
19:55:57 <briancurtin> oh, there's also https://review.openstack.org/#/c/155954/ that has been sitting around for a while. i think it's relatively straightforward
19:56:31 <briancurtin> but yeah, since there's a backlog, just look at whatever you can. the Common* ones are bigger and require more attention, but there's a couple quickies around
19:59:26 <briancurtin> i guess that's it for now. thanks everyone
19:59:44 <briancurtin> #endmeeting