19:00:33 <briancurtin> #startmeeting python-openstacksdk
19:00:33 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:36 <openstack> The meeting name has been set to 'python_openstacksdk'
19:01:07 <briancurtin> 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 <briancurtin> terrylhowe: you around?
19:04:31 <terrylhowe> o/
19:05:21 <briancurtin> terrylhowe: what do we want to do with https://etherpad.openstack.org/p/python-openstacksdk-big-tent-proposal
19:05:42 <terrylhowe> no idea
19:07:16 <terrylhowe> the write up looks fine
19:07:59 <briancurtin> 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 <briancurtin> thinking about the current state
19:08:58 <briancurtin> 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 <briancurtin> 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 <terrylhowe> sure I’m interested.  I’m also not interested in doing that for a long time though.
19:17:56 <briancurtin> 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 <terrylhowe> anything else we should be talking about?
19:21:02 <briancurtin> 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 <briancurtin> terrylhowe: probably just what we need to get done for 0.6
19:21:45 <briancurtin> 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 <terrylhowe> the account stuff looked pretty good, I just had a question on the base class
19:22:38 <terrylhowe> 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 <briancurtin> 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 <terrylhowe> This OCC stuff is the the only other thing I think would be extremely helpful for the OSC POC
19:23:51 <terrylhowe> the question on the base class was why pull in create methods when account doesn’t use them
19:24:49 <briancurtin> 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 <terrylhowe> base class doesn’t look at allow_create and why should it anyway
19:26:09 <terrylhowe> all that could of been left in the container class
19:26:43 <briancurtin> 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 <briancurtin> 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 <terrylhowe> if you use the same create, it would make sense to look at allow_create in the base class
19:28:42 <briancurtin> ok, i see now - yep
19:29:30 <terrylhowe> sorry, looks like my comment is in draft.
19:29:55 <briancurtin> 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 <briancurtin> class.
19:30:23 <briancurtin> 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 <briancurtin> 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 <terrylhowe> that doesn’t solve my functional test config problem though unless I missed something there
19:33:31 <briancurtin> terrylhowe: what is the functioanl test config problem?
19:34:29 <briancurtin> (i probably know what you're talking about, that combination of words isn't registering...i'm kind of fried today)
19:34:42 <terrylhowe> the functional tests could really use some configuration and the nicest place to pull that would be occ
19:35:00 <terrylhowe> like a flavor and image to use testing a particular system
19:35:47 <terrylhowe> potentially a list of tests to skip if testing a particular system because you know they are going to fail
19:36:47 <terrylhowe> I think applications in general would want to access the configuration.
19:36:58 <terrylhowe> I do like the idea of just having a get_connection() though
19:37:47 <briancurtin> 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 <terrylhowe> right, but if I just have a function I can’t expand on it at all
19:38:45 <briancurtin> 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 <briancurtin> 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 <terrylhowe> well, maybe the function should just take a cloud_config blob.  that would solve the import issue as well
19:41:15 <briancurtin> terrylhowe: as in the caller should pass us what comes out of OCC?
19:41:35 <terrylhowe> yeh, move the call to get_one_cloud out of there
19:43:06 <terrylhowe> anyway, what else?
19:43:13 <briancurtin> 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 <briancurtin> 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 <terrylhowe> lots of things would be nice, top priority would be that create attributes bug I just created I think
19:44:20 <briancurtin> 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 <briancurtin> 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 <terrylhowe> yeh, I just haven’t gotten back around to the dynamic loading, I have a big backlog
19:45:11 <briancurtin> but of course, a lot return more. probably just didn't build that around those ones
19:46:28 <terrylhowe> 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 <briancurtin> 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 <terrylhowe> sounds good
19:48:45 <briancurtin> 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 <terrylhowe> yeh, openstacksdk
19:49:43 <terrylhowe> release Weds or Thurs?
19:50:55 <briancurtin> 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 <terrylhowe> awesome
19:52:34 <briancurtin> #endmeeting