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