19:01:36 <briancurtin> #startmeeting python-openstacksdk
19:01:37 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:41 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:50 <briancurtin> sorry for the delay, was looking at that compute guide
19:01:55 <briancurtin> if you're here for the SDK meeting, say hi
19:02:04 <etoews> it's a page turner
19:02:08 <etoews> o/
19:03:09 <etoews> terrylhowe: you available?
19:04:12 <briancurtin> etoews: may as well get into it, i'm sure he'll be here in a few minutes
19:04:18 <briancurtin> #topic Image Import
19:04:25 <briancurtin> #link https://review.openstack.org/#/c/199318/
19:04:45 <briancurtin> etoews: i have some thoughts on the combination idea, but anything on your end to kick it off with?
19:05:14 <etoews> not beyond what i commented in the review
19:07:04 <briancurtin> 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 <etoews> that's where my thoughts went too
19:07:46 <etoews> i can't think of a good use case for doing them separately
19:08:02 <etoews> in fact, it seems to be really confusing to do them separately
19:08:19 <stevelle> this point is actually a source of debate inside glance
19:08:32 <briancurtin> 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 <etoews> i suspect the reason they're separate api calls is to allow the create to pass a json body
19:08:48 <stevelle> import is async
19:08:52 <terrylhowe> o/
19:08:55 <stevelle> through a task iirc
19:09:57 <stevelle> this doesn't look like the task bit though
19:10:41 <etoews> #link http://developer.openstack.org/api-ref-image-v2.html#storeImageFile-v2
19:11:31 <stevelle> import is a word with special meaning in glance v2, sorry I confused things.
19:11:33 <etoews> hmmmm...if import is async it sure would be nice if it returned a 202 >:|
19:11:46 <stevelle> that is in the tasks api of glance v2
19:11:58 <stevelle> this is just the separable metadata vs payload part
19:12:25 <stevelle> ignore what I said about async :)
19:12:38 <etoews> okay
19:12:40 <etoews> :)
19:13:15 <etoews> stevelle: do you think it makes sense to have create and upload as one call in the sdk?
19:13:30 <etoews> would a user ever do one and not the other?
19:13:37 <stevelle> I think at the proxy level a single operation makes sense
19:14:12 <stevelle> in the resource layer I would think separate operations would be valuable
19:14:33 <briancurtin> stevelle: and at the proxy level it should be called...? upload_image was tossed around and seemed reasonable
19:14:49 <stevelle> seems reasonable
19:14:54 <etoews> i think i would prefer create_image
19:15:04 <etoews> mostly because create_object in object_store
19:15:18 <briancurtin> create_ is also fine with me, as it matches that, but o_s could also move to upload_
19:15:21 <etoews> although i would actually prefer upload_object in object_store
19:15:45 <etoews> and then i'd like to see download_object in object_store too, for parity
19:15:50 <stevelle> upload matches the swift cli also, can't recall what osc uses
19:16:00 <etoews> instead of save_object
19:16:02 <stevelle> but I don't have a strong opinion on this
19:16:19 <briancurtin> upload/download pair +=1
19:16:46 <etoews> terrylhowe: opinion on ^?
19:18:09 <terrylhowe> osc uses create/save which is not great
19:18:20 <terrylhowe> upload/download sounds good to me
19:19:28 <etoews> 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 <briancurtin> i created https://bugs.launchpad.net/python-openstacksdk/+bug/1488631 to track upload/download changes
19:20:34 <openstack> Launchpad bug 1488631 in OpenStack SDK "Converge on upload/download names instead of create/save/etc" [Medium,Confirmed]
19:21:36 <etoews> as in, for calls with file payloads.
19:22:05 <briancurtin> just added that to the description
19:22:31 <etoews> thx
19:23:09 <briancurtin> #topic The Compute User Guide
19:24:18 <terrylhowe> I haven’t made time to look at it all yet.  Looks epic.
19:24:23 <etoews> so this is my first crack at a style for the user guides
19:24:38 <etoews> #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 <briancurtin> 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 <etoews> #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 <etoews> terrylhowe: are env vars supported by occ?
19:26:16 <terrylhowe> yes, but I haven’t tried them.  there is some default cloud name for the env
19:26:27 <terrylhowe> it is disabled in osc to make things a bit confusing
19:27:20 <briancurtin> 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 <etoews> configuring apps with env vars is becoming pretty common place due to the 12 factor app
19:28:17 <etoews> briancurtin: i agree in part.
19:29:12 <etoews> my aim was to make it really clear how to configure the sdk the various ways that suits the user best.
19:29:23 <etoews> it's easy to go overboard though
19:29:56 <etoews> 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 <briancurtin> 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 <etoews> i'll kick it around a bit. i'm concerned that the connect page would become overwhelming.
19:32:13 <etoews> 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 <briancurtin> 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 <etoews> 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 <etoews> maybe connect_from_config.rst or connect_advanced.rst
19:35:39 <briancurtin> 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 <etoews> 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 <briancurtin> good point
19:39:12 <terrylhowe> 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 <etoews> 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 <terrylhowe> okay, sounds fine with me
19:42:36 <terrylhowe> 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 <openstack> Launchpad bug 1488643 in OpenStack SDK "Make sure that from_config works with env vars" [Undecided,New]
19:43:04 <etoews> terrylhowe: where do you download that config file in horizon these days?
19:43:42 <etoews> i go the User Settings page and it's not there anymore.
19:43:59 <terrylhowe> hmm, not sure I don’t remember my ip for my devstack instance either
19:44:21 <etoews> okay. well we should move on anyway.
19:44:46 <briancurtin> one quick thing before the next topic probably takes us to the end
19:45:18 <briancurtin> #topic Everett Toews and Qiming Teng for +2 review status
19:45:47 <etoews> i didn't see that on the agenda :)
19:46:03 <briancurtin> 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 <terrylhowe> +2 on that
19:46:33 <etoews> thx!
19:46:47 <briancurtin> i'll add them and email Qiming about it
19:46:58 <briancurtin> #topic path_args direction
19:46:59 <stevelle> congrats
19:47:07 <etoews> briancurtin: i'd advise taking the vote to the mailing list
19:47:29 <etoews> it gives the project a bit more visibility, a sign of maturity, yada yada yada
19:48:08 <briancurtin> 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 <briancurtin> we can increase visibility in other ways, which should certainly be done, though
19:48:52 <etoews> ah. i missed that fuss. there are so many fusses it's hard to keep track.
19:49:45 <etoews> okay. i'm fine with it.
19:49:50 <briancurtin> 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 <briancurtin> 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 <terrylhowe> I cleaned things up a lot and pulled out all the little bugs into other patches that are merged
19:51:48 <terrylhowe> 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 <briancurtin> etoews: quick jump back - i found the RC, it's in https://devstack/project/access_and_security/
19:52:06 <terrylhowe> there is only one case where a url prop is in the body in telemetry
19:52:34 <etoews> ha! i just found it too. http://docs.openstack.org/cli-reference/content/cli_openrc.html#openrc-dashboard
19:53:59 <terrylhowe> it’d be nice of horizon would generate a clouds.yaml
19:54:20 <briancurtin> 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 <briancurtin> it doesn't actually break anything
19:55:33 <etoews> 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 <stevelle> liking the sound of these url props to make things clearer
19:56:13 <stevelle> I just don't have time to experiment with it
19:56:23 <terrylhowe> the advantage is they will automatically do the string->resource thing like resource.prop does
19:57:44 <terrylhowe> the one telemetry property we can leave as a resource.prop
19:58:00 <briancurtin> yeah, breaking some of that stuff up and being smarter about what goes where will be really good
19:58:56 <terrylhowe> 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 <terrylhowe> so the path args automatically get set in the resource when you get one
19:59:49 <terrylhowe> and we are out of time
20:00:01 <briancurtin> 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 <terrylhowe> it is currently broken probably for a lot of other resources I’d think
20:00:44 <etoews> time
20:00:48 <briancurtin> #endmeeting