19:01:36 #startmeeting python-openstacksdk 19:01:37 Meeting started Tue Aug 25 19:01:36 2015 UTC and is due to finish in 60 minutes. The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:41 The meeting name has been set to 'python_openstacksdk' 19:01:50 sorry for the delay, was looking at that compute guide 19:01:55 if you're here for the SDK meeting, say hi 19:02:04 it's a page turner 19:02:08 o/ 19:03:09 terrylhowe: you available? 19:04:12 etoews: may as well get into it, i'm sure he'll be here in a few minutes 19:04:18 #topic Image Import 19:04:25 #link https://review.openstack.org/#/c/199318/ 19:04:45 etoews: i have some thoughts on the combination idea, but anything on your end to kick it off with? 19:05:14 not beyond what i commented in the review 19:07:04 so if we get them right independently, is there ever a case when you would only use one of them to complete an operation? or would you always be using both methods? (i'm not all that familiar with how this is used) 19:07:17 * briancurtin is thinking slightly ahead to the single-method version 19:07:30 that's where my thoughts went too 19:07:46 i can't think of a good use case for doing them separately 19:08:02 in fact, it seems to be really confusing to do them separately 19:08:19 this point is actually a source of debate inside glance 19:08:32 yeah. I'd just want to make sure there's no case where the current day create_image is useful on its own 19:08:36 i suspect the reason they're separate api calls is to allow the create to pass a json body 19:08:48 import is async 19:08:52 o/ 19:08:55 through a task iirc 19:09:57 this doesn't look like the task bit though 19:10:41 #link http://developer.openstack.org/api-ref-image-v2.html#storeImageFile-v2 19:11:31 import is a word with special meaning in glance v2, sorry I confused things. 19:11:33 hmmmm...if import is async it sure would be nice if it returned a 202 >:| 19:11:46 that is in the tasks api of glance v2 19:11:58 this is just the separable metadata vs payload part 19:12:25 ignore what I said about async :) 19:12:38 okay 19:12:40 :) 19:13:15 stevelle: do you think it makes sense to have create and upload as one call in the sdk? 19:13:30 would a user ever do one and not the other? 19:13:37 I think at the proxy level a single operation makes sense 19:14:12 in the resource layer I would think separate operations would be valuable 19:14:33 stevelle: and at the proxy level it should be called...? upload_image was tossed around and seemed reasonable 19:14:49 seems reasonable 19:14:54 i think i would prefer create_image 19:15:04 mostly because create_object in object_store 19:15:18 create_ is also fine with me, as it matches that, but o_s could also move to upload_ 19:15:21 although i would actually prefer upload_object in object_store 19:15:45 and then i'd like to see download_object in object_store too, for parity 19:15:50 upload matches the swift cli also, can't recall what osc uses 19:16:00 instead of save_object 19:16:02 but I don't have a strong opinion on this 19:16:19 upload/download pair +=1 19:16:46 terrylhowe: opinion on ^? 19:18:09 osc uses create/save which is not great 19:18:20 upload/download sounds good to me 19:19:28 okay. i'll condense to upload_image as one function in the proxy. they're already separate functions at the resource level. 19:20:34 i created https://bugs.launchpad.net/python-openstacksdk/+bug/1488631 to track upload/download changes 19:20:34 Launchpad bug 1488631 in OpenStack SDK "Converge on upload/download names instead of create/save/etc" [Medium,Confirmed] 19:21:36 as in, for calls with file payloads. 19:22:05 just added that to the description 19:22:31 thx 19:23:09 #topic The Compute User Guide 19:24:18 I haven’t made time to look at it all yet. Looks epic. 19:24:23 so this is my first crack at a style for the user guides 19:24:38 #link http://docs-draft.openstack.org/23/215823/2/check/gate-python-openstacksdk-docs/8d5d180//doc/build/html/users/guides/connect.html 19:24:46 i just started getting into it right before the meeting. overall looks pretty good, have a few comments in draft. one immediate suggestion is to strike the env var section out of Connection -- we don't directly support it, and shouldn't go on to explain how to do things we don't directly support. if people like env vars, they can figure it out 19:24:47 #link http://docs-draft.openstack.org/23/215823/2/check/gate-python-openstacksdk-docs/8d5d180//doc/build/html/users/guides/compute.html 19:25:48 terrylhowe: are env vars supported by occ? 19:26:16 yes, but I haven’t tried them. there is some default cloud name for the env 19:26:27 it is disabled in osc to make things a bit confusing 19:27:20 etoews: ah, well if it's supported by OCC they can look at OCC. i'd prefer we don't go into every nook and cranny of configuration that our dependencies support. explaining Connection's actual arguments as well as how to use from_config should do the trick 19:27:24 configuring apps with env vars is becoming pretty common place due to the 12 factor app 19:28:17 briancurtin: i agree in part. 19:29:12 my aim was to make it really clear how to configure the sdk the various ways that suits the user best. 19:29:23 it's easy to go overboard though 19:29:56 my intention was to doc the minimal amount of occ config to get the sdk working and then punt to occ docs. 19:29:58 maybe we just load it up for right now and pare it down? easier to do that than offer too little and have people do the wrong thing 19:31:15 i'll kick it around a bit. i'm concerned that the connect page would become overwhelming. 19:32:13 i think i'll add a disclaimer along the lines of "if this is your first rodeo, just use the Connection object. after that try one of the from_config styles below" 19:33:17 etoews: what about having a sub-page of alternative or advanced methods? /connect just lists Connection and then how to from_config with a file, and then /connect/advanced can drill down into env vars, brain mapping, whatever 19:34:46 i can see doing that. even from_config with a file is pretty involved because you have to explain the minimal config for a file. 19:35:06 maybe connect_from_config.rst or connect_advanced.rst 19:35:39 etoews: i guess leave it for right now and we can break it up as the sections are fully filled out to see how it should work 19:36:50 the more i think about the more i prefer to break it up. i'd prefer it if the user can learn how to connect without having to even scroll. 19:37:11 good point 19:39:12 we should just test that env+occ is working that we default OS_CLOUD to the env if it is not set. I haven’t tried that. I’d think it would be easiest for most people to get rolling with env since horizon will give you that as the config 19:41:37 personally i think telling users to explicitly set their creds in a Connection is the easiest possible thing (not necessarily the best thing). if only because it's all right there in the app. 19:42:18 okay, sounds fine with me 19:42:36 created a ticket anyway https://bugs.launchpad.net/python-openstacksdk/+bug/1488643 because I can’t remember all these things to do 19:42:36 Launchpad bug 1488643 in OpenStack SDK "Make sure that from_config works with env vars" [Undecided,New] 19:43:04 terrylhowe: where do you download that config file in horizon these days? 19:43:42 i go the User Settings page and it's not there anymore. 19:43:59 hmm, not sure I don’t remember my ip for my devstack instance either 19:44:21 okay. well we should move on anyway. 19:44:46 one quick thing before the next topic probably takes us to the end 19:45:18 #topic Everett Toews and Qiming Teng for +2 review status 19:45:47 i didn't see that on the agenda :) 19:46:03 both Everett and Qiming are up over 40 reviews in the Liberty cycle and are generally active around the whole code base 19:46:04 +2 on that 19:46:33 thx! 19:46:47 i'll add them and email Qiming about it 19:46:58 #topic path_args direction 19:46:59 congrats 19:47:07 briancurtin: i'd advise taking the vote to the mailing list 19:47:29 it gives the project a bit more visibility, a sign of maturity, yada yada yada 19:48:08 etoews: ehh, there was some fuss about email vote on +2 access a while ago that let people take care of it as they see fit, or something like that. plus it would just a be a bunch of people saying +1 19:48:32 we can increase visibility in other ways, which should certainly be done, though 19:48:52 ah. i missed that fuss. there are so many fusses it's hard to keep track. 19:49:45 okay. i'm fine with it. 19:49:50 terrylhowe: i knocked out a bunch of dependent reviews leading up to a lot of what you've been up to lately 19:50:23 the foreign key thing still doesn't make sense to me (but i see it's workflow-1 now), but the path-args in a method maybe makes sense 19:51:08 I cleaned things up a lot and pulled out all the little bugs into other patches that are merged 19:51:48 I was thinking about creating a new property like resource.prop that is for url props so they stay ouf of the message body 19:51:56 etoews: quick jump back - i found the RC, it's in https://devstack/project/access_and_security/ 19:52:06 there is only one case where a url prop is in the body in telemetry 19:52:34 ha! i just found it too. http://docs.openstack.org/cli-reference/content/cli_openrc.html#openrc-dashboard 19:53:59 it’d be nice of horizon would generate a clouds.yaml 19:54:20 terrylhowe: yeah, and i think overall we need to get a little smarter with what we're sending whether it's in headers, body, or URLs. we have that thing you just noticed with object_store and headers, we were previously sending unrecognized query params in URLs, and telemetry body values. that stuff will add up to more data being sent over the wire, even if 19:54:21 it doesn't actually break anything 19:55:33 and with nova 2.1 on the way, validation of requests is going to be a lot stricter so sending superfluous stuff might get you a 400 when it didn't before. 19:55:45 liking the sound of these url props to make things clearer 19:56:13 I just don't have time to experiment with it 19:56:23 the advantage is they will automatically do the string->resource thing like resource.prop does 19:57:44 the one telemetry property we can leave as a resource.prop 19:58:00 yeah, breaking some of that stuff up and being smarter about what goes where will be really good 19:58:56 the final thing I’d like to try with all this is to replace this: https://github.com/stackforge/python-openstacksdk/blob/master/openstack/object_store/v1/_proxy.py#L131 19:59:26 so the path args automatically get set in the resource when you get one 19:59:49 and we are out of time 20:00:01 that would be nice. i don't like that either, but that's one of those backwards places i couldn't originally work around (which was why object_store's whole API was backwards the first time around) 20:00:23 it is currently broken probably for a lot of other resources I’d think 20:00:44 time 20:00:48 #endmeeting