19:00:11 <briancurtin> #startmeeting python-openstacksdk
19:00:12 <openstack> Meeting started Tue Feb  2 19:00:11 2016 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:15 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:49 <rtheis> o/
19:01:07 <etoews> o/
19:01:52 <briancurtin> i don’t really have an agenda right now as the last few days i haven’t spent a ton of time working as i just moved over the weekend. anyone have a particular topic to bring up?
19:02:12 <rtheis> https://bugs.launchpad.net/python-openstacksdk/+bug/1461200
19:02:13 <openstack> Launchpad bug 1461200 in OpenStack SDK "Create basic resource.props for id and ids attributes" [Critical,In progress] - Assigned to Richard Theis (rtheis)
19:02:20 <etoews> yes. that one.
19:02:24 <rtheis> https://review.openstack.org/#/c/270900/
19:02:28 <rtheis> Wondering how to proceed
19:03:00 <rtheis> I was considering only using _ids for a list of ID strings
19:03:09 <briancurtin> ooh, yeah, i saw the emails on that but haven’t come back to it, though i remember having one thought on a naming choice - i’ll read up right now
19:03:18 <rtheis> ok
19:03:36 <terrylhowe> o/
19:03:36 <etoews> ya. let's take a min and nail it down.
19:06:15 <terrylhowe> this whole id thing in the path args I made it so there were no _id properties and the major ones would resolve to a resource object
19:06:27 <terrylhowe> for things in path args at least
19:06:54 <terrylhowe> probably too much work though
19:07:16 <terrylhowe> things like tenant_id would be converted to a project resource
19:07:41 <briancurtin> ok, so qiming’s last two sentences on https://bugs.launchpad.net/python-openstacksdk/+bug/1461200/comments/6 — anything that is an id or sequence of ids should now be foo_id or foo_ids, regardless of if it comes in the response as foo or whatever. while renaming pools in his example to pool_ids doesn’t buy us much in that exact spot, consistency across
19:07:43 <openstack> Launchpad bug 1461200 in OpenStack SDK "Create basic resource.props for id and ids attributes" [Critical,In progress] - Assigned to Richard Theis (rtheis)
19:07:43 <briancurtin> the board is what it buys us
19:08:14 <briancurtin> terrylhowe: yeah but we’re going away from type=Resource
19:08:42 <terrylhowe> that is fine, it is cool on one level, but probably in reality no end of hassle
19:09:32 <briancurtin> terrylhowe: i haven’t had time to look over the last few days, but the thing on my plate now that i’m back into it is to figure out our problems with the path_args stuff that was mostly caused by type=Resource, so that whole thing is probably easier to do now. i think
19:12:27 <rtheis> so use _id/_ids for property names only if the property is ID/list of IDs ?  And leave the properties which contain list of dicts or dicts as-is ?
19:13:15 <rtheis> That is what I was considering in comment 7
19:13:42 <etoews> rtheis: what does a "list of dicts which contain the load balancer IDs" look like?
19:13:46 <etoews> do you have some example data?
19:13:57 <rtheis> yeah
19:14:35 <etoews> rtheis: what does a "list of dicts which contain the load balancer IDs" look like?
19:14:35 <etoews> do you have some example data?
19:14:36 <rtheis> [{'id': '6'},{'id': '7'}]
19:15:26 <rtheis> so each dict is a load balancer and the only data returned is the ID for the load balancer
19:15:37 <rtheis> But I suppose the network API could return more in the future
19:16:16 <etoews> sigh...future proofing...
19:16:22 <briancurtin> rtheis: a single string should be _id, a sequence or collection should be _ids (lists, lists of dicts, dicts, etc)
19:16:44 <rtheis> ok
19:19:12 <etoews> briancurtin: can you communicate that to qiming on the email thread?
19:19:53 <briancurtin> etoews: should i put it in the issue so it’s out there? (also this is the kind of thing that would eventually be codified in a contrib guide)
19:20:14 <etoews> ++ even better
19:20:27 <briancurtin> i’ll write that up after this is over
19:20:37 <rtheis> thanks
19:21:27 <briancurtin> anything else to discuss?
19:21:41 <rtheis> nothing else from me
19:21:53 <etoews> https://review.openstack.org/#/c/265659/
19:22:03 <etoews> should be ready to go.
19:22:44 <briancurtin> etoews: looking now
19:23:29 <briancurtin> etoews: yeah that’s good
19:24:06 <etoews> if we have functional tests that are configurable and we can skip functional tests if a particular service isn't present, that opens up the gate (pun intended) to testing against public clouds.
19:24:50 <etoews> not sure how storing username/password would work with the gate though or if it's even possible.
19:25:06 <etoews> either way it's a post-1.0 consideration.
19:26:21 <briancurtin> yeah, not sure how creds would work. the services which do third-party testing, like cinder and neutron, probably have something along the same lines, right?
19:27:11 <etoews> those are drivers though. not sure if secrets are required in those cases.
19:27:20 <briancurtin> ah, true
19:27:59 <etoews> anyway, i don't want to distract for 1.0 stuff. just something for future consideration.
19:28:09 <etoews> my other thing was this.
19:28:10 <etoews> https://bugs.launchpad.net/python-openstacksdk/+bug/1487150
19:28:11 <openstack> Launchpad bug 1487150 in OpenStack SDK "Object store set_object_metadata is a bit oddball" [Critical,In progress] - Assigned to Everett Toews (everett-toews)
19:28:26 <etoews> i just picked that up
19:29:03 <etoews> i chatted with brian a bit about it but wanted to chat briefly here too
19:29:42 <etoews> here's what i'm currently thinking for the interface
19:29:46 <etoews> set_account_metadata(metadata=None, **properties)
19:29:46 <etoews> set_container_metadata(container, metadata=None, **properties)
19:29:46 <etoews> set_object_metadata(obj, container=None, metadata=None, **properties)
19:30:42 <etoews> in object store terms, metadata is actually "custom" metadata
19:31:03 <etoews> but it's similar to metadata in compute and it's only called metadata in compute
19:31:12 <etoews> (although the impl is very very different)
19:32:09 <etoews> so i was thinking that you can set "metadata" on resources in object store
19:32:49 <etoews> but if you want to set well-defined metadata (like "delete_after") then you can do that through **properties
19:33:46 <etoews> does that make sense? thoughts?
19:36:09 <rtheis> sounds good to me, but I'm not very familiar with object store
19:36:12 <briancurtin> of note: we talked about just making this set_metadata(…) and having one method for account, container, and object, but it becomes quite odd in that account is effectively the ‘base’ of all of this (it’s root of the REST API) and the others compound on top of it, so a single method API for this has a bunch of extra arguments we’d have to parse out
19:36:12 <briancurtin> to figure out what is actually going on
19:37:51 <etoews> briancurtin: what do you think about the naming? i know it's a bit different from what we discussed earlier.
19:38:14 <briancurtin> etoews: i’m cool with it
19:39:12 <etoews> k. i'll go forward with that.
19:39:14 <etoews> thx
19:40:09 <etoews> briancurtin: did you want to talk about https://bugs.launchpad.net/python-openstacksdk/+bug/1538267 at all?
19:40:10 <openstack> Launchpad bug 1538267 in OpenStack SDK "Need RFC2616 formatter as a type for properties" [Medium,In progress] - Assigned to Brian Curtin (brian.curtin)
19:40:40 <briancurtin> etoews: oh i abandoned that one and pushed a small change to just remove date from object
19:41:06 <briancurtin> date and timestamp are the same value in different formats, so we don’t need to formatters to change them into the same datetime object
19:41:36 <etoews> oh. gotcha. just need to kill off the issue then.
19:41:44 <briancurtin> just marked as won’t fix
19:41:49 <etoews> cool.
19:42:49 <briancurtin> oh, the branch i intended to push got hung up when i lost internet. now it’s up: https://review.openstack.org/275385
19:44:01 <etoews> nice. we're closer to 1.0 than ever.
19:45:07 <etoews> nothing else from me.
19:45:22 <briancurtin> same
19:46:59 <etoews> rtheis: terrylhowe: anything from yourselves?
19:47:05 <rtheis> nothing else
19:47:08 <terrylhowe> nothing here
19:47:13 <briancurtin> cool, thanks everyone
19:47:15 <etoews> thx
19:47:16 <terrylhowe> thanks
19:47:17 <briancurtin> #endmeeting