19:00:47 <briancurtin> #startmeeting python-openstacksdk
19:00:48 <openstack> Meeting started Tue Feb 17 19:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:52 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:14 <stevelle> sigmavirus24: I haven't audited to see if I did https well or just enough
19:01:36 <terrylhowe> Terry Howe, HP
19:01:39 <sigmavirus24> Ian Cordasco, Rackspace
19:01:46 <briancurtin> Brian Curtin
19:02:01 <stevelle> Steve Lewis, Rackspace
19:02:12 <briancurtin> so i put together an agenda that i'll try to work off of, but there's a lot to get through: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2015-02-16_1900_UTC
19:02:38 <briancurtin> #topic KSC auth - https://review.openstack.org/#/c/156064/
19:03:23 <briancurtin> terrylhowe: i put a few comments on there after trying it out. overall looks good, just a few consistency things with project/tenant, and then user_name/username
19:03:43 <sigmavirus24> Is the point of this to allow existing keystone client auth plugins to work instead of having to reimplement them for openstacksdk?
19:03:51 <terrylhowe> I’m having a tough time keeping up with the onslaught of code from briancurtin so I haven’t had a chance to address that
19:04:18 <terrylhowe> yeh, at the summit we discussed bringing those back from compatibility
19:04:36 <terrylhowe> we still have the generic identity plugin that I think is default
19:05:12 <terrylhowe> KSC also has two other plugins that I didn’t bring over in that patch, maybe in another change request
19:05:15 <sigmavirus24> That makes sense. I'll take a gander and give it a try
19:05:53 <briancurtin> terrylhowe: i think it would be best to have this KSC switch before we do do more with the vendor plugins so we have that squared away before you or i or anyone else go off and write one type of plugin and then change
19:06:14 <briancurtin> is my understanding correct?
19:06:55 <terrylhowe> yeh, if the vendor plugin was inheiriting off the previous plugins
19:07:59 <briancurtin> cool, whenever you have time for more on that i'm ready for reviews so we can make sure it's in
19:08:10 <terrylhowe> k
19:08:15 <briancurtin> #topic Support Resource as a type for properties - https://review.openstack.org/#/c/152275/
19:09:47 <briancurtin> that review allows for a couple of other things in the queue which are pretty powerful. it'll make resources which currently use other resource IDs pretty nice, and it allowed for a pretty nice combination of sub-resources where compute.v2.Limits contains an AbsoluteLimit and a RateLimit
19:10:17 <stevelle> I like the idea on this one, just haven't really decided on the review
19:10:18 <briancurtin> we've wanted something better for IDs for a while now. the Limits thing came up when I was tinkering around and realized what that could do
19:11:28 <terrylhowe> it looks good, I’d like to mess with it to make sure I understand how it works
19:13:32 <briancurtin> cool. i might do some writing on the toying around that came of that, because the compute.v2.limits change shows off how to build a resource out of a complex body like limits pretty well
19:14:01 <stevelle> that sounds like a good idea briancurtin
19:14:31 <briancurtin> #topic the base Resource.find
19:15:17 <briancurtin> i had a few approaches to fix Resource.find that came from using it and finding that the filter args it uses don't work in enough cases, but then my method was far too heavy handed and would require a lot of data
19:15:36 <briancurtin> i tried a few other things and 15 minutes ago came up with https://review.openstack.org/#/c/156707/
19:16:50 <briancurtin> it tries to just GET /myresource/name_or_id - if it's an ID that it exsists, it'll be returned. if not, we have to try to get data and do client side filtering. by default, all we can do is take all the data. however, when we know what type of filtering we can provide, we accept that and pass it on
19:18:14 <briancurtin> so if you just call Foo.find(session, "blah"), it's like doing "select *". Foo.find(session, "blah", filters={"name": "blah", "filters": "name"}) would potentially reduce to exactly the item we want assuming that particular resource supports those filters
19:19:53 * sigmavirus24 has thoughts that he'll leave on the review
19:22:49 <terrylhowe> I’ve thrown some comments down, but I still need to do a proper review
19:23:22 <briancurtin> i wish there was a more general purpose way to do filtering without requesting a lot of data up front, but so many APIs do different things that it doesn't end up working. from this, it makes it easy in the proxy layer to handle those filters by itself without even giving a name
19:24:15 <terrylhowe> I’d personally sooner the proxy layer didn’t get involved in fixing filtering problems
19:24:28 <terrylhowe> because then those fixes aren’t available at the resource layer
19:24:47 <briancurtin> i dont think it'll fix it, i think it just makes it so you can pass in the filters nicely. like find_flavor(size=90)
19:25:28 <briancurtin> at the resource you would just do Flavor.find(..., filters={"minSize": 90}) to get back 90gb+ servers
19:25:38 <briancurtin> (actually that takes MB)
19:26:10 <briancurtin> we'd still be fully handling the problem in the resource layer, just making a convenient sheen on top in the proxy
19:26:17 <terrylhowe> okay, sounds good
19:26:42 <briancurtin> #topic non-paginated lists
19:27:28 <briancurtin> we've gone a few different ways on this, including trying to determine it ourselves, trying to split out different methods, etc. they all have various penalties, including on needing extra requests. i think it's time to just make users say whether or not it's paginated at the resource layer with a parameter: https://review.openstack.org/#/c/156664/
19:29:32 <briancurtin> that allows proxy implementors to always work with Resource.list instead of some form of Resource.page and everything else works the same
19:30:45 <terrylhowe> Would this be kind of solved if page returned a list of resources instead of dicts?
19:31:32 <terrylhowe> because I was kind of thinking page should be changed to return a list of resources
19:32:50 <briancurtin> terrylhowe: i dont think so because then proxy usages would then have to consume the list just to turn it into a generator, so they'd all have to add a ``for i in R.page: yield i`` in order to work the same as the other things that work with list
19:33:37 <briancurtin> terrylhowe: i think that's actually a good change, but it doesn't solve the specific case since whether it's one page or 100 pages we should return a generator
19:36:28 <briancurtin> i'm starting to like the idea of flipping a parameter versus calling a different function. that also makes it easier to go back and forth for some of those resources which support but may disable pagination on the server side. if you know it's enabled, just flip the param and you're good
19:37:54 <briancurtin> and we should perhaps add that paginated flag into proxy methods so list_networks (which started the whole non-paginated list thing) so we can pass it down below as the user wants
19:41:34 <briancurtin> #topic dirty list not kept up to date - https://review.openstack.org/#/c/156485/
19:43:02 <briancurtin> while messing with some object_store stuff which i was trying to fix, i realized we're not properly tracking modified attributes, or the dirty list. resource.prop attribute access doesn't get tracked there, so i moved it to follow that same path so Resource.update calls work properly (since they only send dirty values)
19:43:49 <stevelle> looks like something I probably broke along the way
19:44:08 <briancurtin> it does have one thing that is commented out because it was somehow causing a test failure which i don't get. i'm going to come back and look at that and see what's going on, unless someone remembers creating that security_group_rule thing
19:44:47 <terrylhowe> I’m sure I did that I guess just to test that the security group constructs the rules
19:45:11 <terrylhowe> as I recall, the GET returns all the rules in the body
19:45:48 <briancurtin> yeah that part makes sense (would also benefit from that Resource-as-type change, i think), but the specific test looking for __class__.__name__ oddly broke
19:47:22 <briancurtin> ah, we should probably just do self.assertEqual(type(sot.security_group_rules[0]), SecurityGroupRule)
19:47:25 <briancurtin> or something
19:48:23 <briancurtin> i'm going to try to rush through this last thing because i'm in the barbican mid-cycle meetup and i'm being summoned to an SDK conversation
19:48:29 <briancurtin> #topic case insensitive attr dict - https://review.openstack.org/#/c/156135/
19:50:10 <briancurtin> setting any header attributes that come back doesn't always work because of the case mismatch. we can set and get our own things because we know the case, but we can't get anything that doesn't directly match. using this case insensitive dict to store what we get back helps this work
19:50:26 <terrylhowe> scary change to me
19:51:14 <briancurtin> we really have no other choice since header keys are case insensitive by nature and they're set in different cases than we ourselves create
19:52:09 <briancurtin> but yeah, i dont love it, but we need it or something like it. requests itself does something pretty similar
19:53:11 <stevelle> so we rely on a case-insensitive dict but specify the preferred format for outbound props
19:54:02 <briancurtin> stevelle: yep. anything we get which matches insensitively will be stored, and what we send outbound will have the case we configure the prop with
19:54:36 <stevelle> I haven't seen any places in the APIs where that will be a problem yet.
19:54:39 <briancurtin> the place where we have the most (only?) header stuff is in object_store, and it has all of the props as lowercase
19:55:32 <sigmavirus24> yeah also requests will lower-case the headers by default typically
19:55:41 <briancurtin> i have to drop off, they're apparently just pausing waiting for me to join this barbican/castellan conversation about things living in SDK. i'll be back on in -sdks in a bit
19:55:47 <sigmavirus24> but I think we offer a way to pull them out case sensitively
19:55:55 <briancurtin> #endmeeting