19:00:05 <briancurtin> #startmeeting python-openstacksdk
19:00:06 <openstack> Meeting started Tue Feb  9 19:00:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:10 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:21 <etoews> o/
19:00:51 <briancurtin> rtheis you around? i don’t see terry online at all
19:01:07 <rtheis> hi
19:01:44 <rtheis> I have another meeting running at the same time so may be distracted for a bit
19:02:13 <briancurtin> rtheis: all good, not much to discuss - i have a small update and then i know etoews has a thing
19:02:23 <briancurtin> i’m going to kick it off with an update on what i’ve been working on. it’s been in circles a few times, but i think i’m on the right path
19:04:35 <briancurtin> after going down a few rabbit holes that ended up being impossible with props being descriptors, i looked at maybe moving away from them being that, but it harms usability, so i think i can keep them intact but just change how we store things. since we’ve been putting headers together with body props in the _attrs dict, i’m looking at storing them
19:04:35 <briancurtin> completely separately and splitting how headers and body props work under the hood, while enabling URI-only props. i think through that it should help an issue everett saw with some services being strict about what they receive, so we’d be able to specify that certain things are read-only or for requests or something like that, so that we’re not sending
19:04:35 <briancurtin> more data than we need to (or more than the server can work with)
19:05:55 <briancurtin> there hasn’t been a lot to show for it because there has been a lot of starting and stopping, heading another direction, running into the same road block, and then going back to the drawing board. i should be able to get a lot further with this, it just touches a lot of places and i need to figure out some good internal APIs for working with it
19:06:22 <etoews> that sounds like a lot of work
19:06:48 <briancurtin> sort of, but i don’t think it’s work we can avoid
19:06:52 <etoews> seems like it could be helpful down the road too though
19:06:58 <rtheis> indeed
19:07:19 <etoews> once openstack gets stricter about the requests it accepts
19:09:04 <briancurtin> i’m going to try to minimize the change and just focus on getting the public stuff right so that we can release a 1.0, if it’s possible to split it up at all. i don’t really know how the full change is going to turn out  right now though
19:10:40 <briancurtin> anyway, that’s where that’s at. etoews do you want to talk about the metadata stuff?
19:10:47 <etoews> sure
19:10:59 <etoews> https://bugs.launchpad.net/python-openstacksdk/+bug/1487150
19:11:00 <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:11:51 <etoews> so starting on that has basically been pulling a loose thread on a sweater.
19:12:21 <etoews> first i ran into this https://bugs.launchpad.net/python-openstacksdk/+bug/1488269/
19:12:22 <openstack> Launchpad bug 1488269 in OpenStack SDK "Object get needs to be smarter about what headers it sends" [Undecided,New]
19:13:05 <etoews> i got sort of figured that one out (haven't sent a any new commits though)
19:13:51 <etoews> then i learned of the horrific inconsistency in metadata handling between account/container and object in object store http://developer.openstack.org/api-ref-objectstorage-v1.html
19:15:19 <etoews> to smooth over that inconsistency it's got me considering redesigning the way compute handles metadata
19:15:49 <etoews> here's what i'm thinking
19:16:36 <etoews> the object store proxy would have a metadata interface like
19:16:38 <etoews> get_metadata(self, resource, key=None)
19:16:38 <etoews> create_metadata(self, resource, **metadata)
19:16:38 <etoews> replace_metadata(self, resource, **metadata)
19:16:38 <etoews> update_metadata(self, resource, **metadata)
19:16:38 <etoews> delete_metadata(self, resource, key)
19:16:48 <etoews> (very similar to compute)
19:17:06 <etoews> resource would have to be an instance of an account, container, or object, just so we can switch on the resource type to do the appropriate thing and `**metadata` would be able to update both custom metadata and regular metadata.
19:17:59 <etoews> to keep things things consistent we'd want to change the metadata interface in compute to match
19:18:27 <etoews> although that would be part of a different patch set and not that difficult to do.
19:19:20 <etoews> we'd also need to look at the image service metadata/properties/whatever-they-call-it to be sure that interface would work there too.
19:20:03 <briancurtin> etoews and i already sort of talked about this, but yeah, i’m on board with it. consistency across the board, and allows us to fix some of the issues object_store has with its own inconsistencies
19:20:23 <etoews> all in all it's a ridiculous amount of work just to set key/value pairs on resources :/
19:21:22 <briancurtin> yep, but another one of those things we should spend the time to get right before shipping an inconsistent 1.0 that we can’t really change without a 2.0
19:21:42 <etoews> ya. better to get this stuff in now.
19:22:34 <etoews> rtheis: is https://review.openstack.org/#/c/270900/ updated on what we discussed last week ( https://bugs.launchpad.net/python-openstacksdk/+bug/1461200/comments/9 )?
19:22:35 <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:23:18 <rtheis> etoews: yes, I updated based last week's discussion
19:23:58 <rtheis> It is China holiday now so maybe Qiming is out
19:24:14 <etoews> thx. i'll give it another review.
19:24:42 <briancurtin> same
19:24:47 <etoews> year of the monkey!
19:24:52 <rtheis> :)
19:25:07 <etoews> year of the code monkey!
19:26:32 <briancurtin> anything else going on?
19:28:03 <etoews> not so much
19:28:16 <rtheis> nothing else here
19:29:03 <briancurtin> alrighty then, back to the grind i guess
19:29:36 <briancurtin> #endmeeting