19:00:47 #startmeeting python-openstacksdk 19:00:48 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:52 The meeting name has been set to 'python_openstacksdk' 19:01:14 sigmavirus24: I haven't audited to see if I did https well or just enough 19:01:36 Terry Howe, HP 19:01:39 Ian Cordasco, Rackspace 19:01:46 Brian Curtin 19:02:01 Steve Lewis, Rackspace 19:02:12 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 #topic KSC auth - https://review.openstack.org/#/c/156064/ 19:03:23 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 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 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 yeh, at the summit we discussed bringing those back from compatibility 19:04:36 we still have the generic identity plugin that I think is default 19:05:12 KSC also has two other plugins that I didn’t bring over in that patch, maybe in another change request 19:05:15 That makes sense. I'll take a gander and give it a try 19:05:53 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 is my understanding correct? 19:06:55 yeh, if the vendor plugin was inheiriting off the previous plugins 19:07:59 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 k 19:08:15 #topic Support Resource as a type for properties - https://review.openstack.org/#/c/152275/ 19:09:47 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 I like the idea on this one, just haven't really decided on the review 19:10:18 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 it looks good, I’d like to mess with it to make sure I understand how it works 19:13:32 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 that sounds like a good idea briancurtin 19:14:31 #topic the base Resource.find 19:15:17 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 i tried a few other things and 15 minutes ago came up with https://review.openstack.org/#/c/156707/ 19:16:50 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 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 I’ve thrown some comments down, but I still need to do a proper review 19:23:22 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 I’d personally sooner the proxy layer didn’t get involved in fixing filtering problems 19:24:28 because then those fixes aren’t available at the resource layer 19:24:47 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 at the resource you would just do Flavor.find(..., filters={"minSize": 90}) to get back 90gb+ servers 19:25:38 (actually that takes MB) 19:26:10 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 okay, sounds good 19:26:42 #topic non-paginated lists 19:27:28 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 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 Would this be kind of solved if page returned a list of resources instead of dicts? 19:31:32 because I was kind of thinking page should be changed to return a list of resources 19:32:50 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 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 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 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 #topic dirty list not kept up to date - https://review.openstack.org/#/c/156485/ 19:43:02 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 looks like something I probably broke along the way 19:44:08 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 I’m sure I did that I guess just to test that the security group constructs the rules 19:45:11 as I recall, the GET returns all the rules in the body 19:45:48 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 ah, we should probably just do self.assertEqual(type(sot.security_group_rules[0]), SecurityGroupRule) 19:47:25 or something 19:48:23 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 #topic case insensitive attr dict - https://review.openstack.org/#/c/156135/ 19:50:10 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 scary change to me 19:51:14 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 but yeah, i dont love it, but we need it or something like it. requests itself does something pretty similar 19:53:11 so we rely on a case-insensitive dict but specify the preferred format for outbound props 19:54:02 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 I haven't seen any places in the APIs where that will be a problem yet. 19:54:39 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 yeah also requests will lower-case the headers by default typically 19:55:41 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 but I think we offer a way to pull them out case sensitively 19:55:55 #endmeeting