19:00:33 #startmeeting python-openstacksdk 19:00:33 Meeting started Tue Jul 14 19:00:33 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:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:36 The meeting name has been set to 'python_openstacksdk' 19:01:07 if you're around for the SDK meeting, say hi. i'm guessing it's just terry and i. everett is on vacation for a while. 19:04:15 terrylhowe: you around? 19:04:31 o/ 19:05:21 terrylhowe: what do we want to do with https://etherpad.openstack.org/p/python-openstacksdk-big-tent-proposal 19:05:42 no idea 19:07:16 the write up looks fine 19:07:59 terrylhowe: once we have the PTL thing ironed out i can submit it (or you can if you want), and then i guess we just do whatever Q&A on the review for it. the thing i still don't want to do with the PTL spot is having some implicit rotation there - since it'll be a real election next time i dont think we can (or should) plan anything like that besides 19:08:00 thinking about the current state 19:08:58 someone we dont even know could come along for the next cycle and be the best candidate, so i think if anyone is interested right now we should just focus on right now 19:11:52 so i'm interested in PTL today, and i know you're interested in PTL at some point -- are you interested today? 19:13:47 sure I’m interested. I’m also not interested in doing that for a long time though. 19:17:56 i don't know when the next election would be, but i think the only duration is to that next point. since it's per-cycle it cant be any more than six months, and we're in the middle of a cycle so it's probably only a few months anyway. i think? 19:20:58 anything else we should be talking about? 19:21:02 the last time my email shows something about a PTL election was in April, so i would think the next time it'll come up is October 19:21:13 terrylhowe: probably just what we need to get done for 0.6 19:21:45 terrylhowe: i pushed the object_store metadata stuff, which would be good to get in. which of your current changes do you want the focus on so we can get them in? 19:22:11 the account stuff looked pretty good, I just had a question on the base class 19:22:38 I haven’t had a change to give the object store stuff a try yet, but yeh, that’d be good to get in 19:23:24 terrylhowe: what's up with the base class? i actually have a question for myself on that...can it or should it pertain to Object as well? i guess i should look at that after this 19:23:35 This OCC stuff is the the only other thing I think would be extremely helpful for the OSC POC 19:23:51 the question on the base class was why pull in create methods when account doesn’t use them 19:24:49 terrylhowe: calling create on it isn't even going to work since Account has allow_create=False, but it could raise NotImplementedError 19:25:43 base class doesn’t look at allow_create and why should it anyway 19:26:09 all that could of been left in the container class 19:26:43 well Account.create is going to call Account.create_by_id, which is going to see that Account.allow_create=False and it's going to raise that it can't be done...but i could just put that method back in container 19:27:10 however, if i can actually use the same thing for Object, it will make sense to do that all in the base, so i'll take another look at it 19:28:02 if you use the same create, it would make sense to look at allow_create in the base class 19:28:42 ok, i see now - yep 19:29:30 sorry, looks like my comment is in draft. 19:29:55 terrylhowe: on OCC, i have this one in draft but will just send here: To me, the #1 option for this is a factory function that returns a working Connection object -- that's a fairly common construct. Returning the args isn't the greatest, but I think the last of our options is a class that contains individual methods that have to be called to construct a 19:29:55 class. 19:30:23 taking in OCC and returning COnnection will keep any possible changes self-contained. we should solve any testing issues in the tests rather than building a class to make testing easier 19:31:23 if Connection grows to take 5 configurable parameters, both the params-returning-function is tricky, and the class-with-methods is another moving target. function-returning-Connection is the only one that easily survives those changes 19:32:11 that doesn’t solve my functional test config problem though unless I missed something there 19:33:31 terrylhowe: what is the functioanl test config problem? 19:34:29 (i probably know what you're talking about, that combination of words isn't registering...i'm kind of fried today) 19:34:42 the functional tests could really use some configuration and the nicest place to pull that would be occ 19:35:00 like a flavor and image to use testing a particular system 19:35:47 potentially a list of tests to skip if testing a particular system because you know they are going to fail 19:36:47 I think applications in general would want to access the configuration. 19:36:58 I do like the idea of just having a get_connection() though 19:37:47 terrylhowe: that sounds like a specialization *beyond* this. creating a Connection from a config is something we should probably figure out first. reading a config and pulling testing information out of it seems like it'd be part 2 19:38:16 right, but if I just have a function I can’t expand on it at all 19:38:45 if an application wants to access the configuration it can read the configuration file. the SDK creating its connection is something it should just do 19:39:26 i dont think we should try to get all possible information for other people out the config. we need only to know what it takes to create a Connection. if my app needs more i'll read the file 19:40:38 well, maybe the function should just take a cloud_config blob. that would solve the import issue as well 19:41:15 terrylhowe: as in the caller should pass us what comes out of OCC? 19:41:35 yeh, move the call to get_one_cloud out of there 19:43:06 anyway, what else? 19:43:13 hmm. that might work, but we'd have to have some safety checks up front so we know we can operate on that blob 19:43:45 terrylhowe: besides this account/object_store stuff and OCC things, i dont have anything else immediately needed for a 0.6. anything you want to squeeze in? 19:44:19 lots of things would be nice, top priority would be that create attributes bug I just created I think 19:44:20 the dynamic loading would be nice to get in, but shouldn't rush that. can do a 0.7 in a few weeks -- i think that stuff is something we should release immediately once it's ready 19:44:56 terrylhowe: yeah i saw that, that's a good one. not sure why that happened but im guessing it's just based on some of the initial resources we put in - a bunch of them do only return an ID 19:44:57 yeh, I just haven’t gotten back around to the dynamic loading, I have a big backlog 19:45:11 but of course, a lot return more. probably just didn't build that around those ones 19:46:28 I noticed the create thing when I was working on teh osc poc. I should probably do one more pass there to see if anything else shows up 19:46:52 terrylhowe: ok so i'll keep an eye on the OCC thing and try to clean up the Account/object_store stuff. i might not get to it this afternoon since i'm heading to some family stuff, but i'm back to normal tomorrow 19:47:27 sounds good 19:48:45 terrylhowe: anything else to cover? i think we should be set to release as openstacksdk instead of python-openstacksdk, as far as i remember...i think we changed what we needed 19:49:06 yeh, openstacksdk 19:49:43 release Weds or Thurs? 19:50:55 terrylhowe: i would think Thurs unless we happen to get everything ironed out tomorrow. im only going to focus on those three things until we're out, so hopefully not too much longer than these next days 19:51:10 awesome 19:52:34 #endmeeting