19:00:16 <briancurtin> #startmeeting python-openstacksdk
19:00:17 <openstack> Meeting started Tue Oct 21 19:00:16 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:21 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:28 <briancurtin> if you're here for the SDK meeting, say hi
19:00:31 <briancurtin> Brian Curtin, Rackspace
19:00:40 <sigmavirus24> Ian Cordasco, Rackspace
19:00:52 <jamielennox_> Jamie Lennox, Red Hat
19:00:52 <stevelle> Steve LEwis, Rackspace
19:01:03 <dtroyer> Dean Troyer, Nebula
19:01:11 <terrylhowe> Terry Howe, HP
19:01:44 <briancurtin> #topic summit talk (just a quick mention)
19:02:34 <briancurtin> i have 15 minutes pretty solidly figured out - outlined and sort of scripted - a bit of a conclusion, but right now i'm looking at filling in teh rest with code and examples
19:02:53 <briancurtin> the content so far is at https://etherpad.openstack.org/p/sdk-summit-talk but this morning i started working it into actual slides
19:03:08 <dhellmann> Doug Hellmann, HP
19:03:21 <briancurtin> terrylhowe: did you end up doing anything on slides?
19:04:05 <terrylhowe> I will add some stuff Wednesday
19:04:21 <briancurtin> cool
19:05:04 <briancurtin> #topic current reviews
19:05:30 <briancurtin> autodoc seems like a good idea, so +2 on pushing forward with that
19:05:51 <briancurtin> i think it's used in most other projects as well, right?
19:06:34 <sigmavirus24> I don't know but it greatly simplifies documentation and ensures high quality docstrings in the event someone opens up their interpreter and runs help on the object
19:06:59 <dhellmann> which patch is that?
19:07:12 <sigmavirus24> dhellmann: there are several of them
19:07:52 <terrylhowe> I like the idea of autodocs, makes things a lot more likely to be correct
19:07:59 <dhellmann> oh, you mean the sphinx autodoc stuff -- there's also a feature in pbr to auto-generate files with autodoc directives in them, but you have to be careful using that because it might expose private modules
19:08:12 <dhellmann> I like managing the files by hand, myself
19:09:21 <terrylhowe> well, I would like the formatting to be a little different, but I think it is worth the compromise
19:09:24 <briancurtin> ive always done by hand in the past, but it's always been small enough codebases to keep track of. this feels like it could be nice
19:09:59 <dhellmann> yeah, using the automodule directives ensures you don't forget to add public classes to your documentation
19:10:10 <terrylhowe> I think the pieces parts in this project will come of more scrutiny than some other projects
19:10:33 <terrylhowe> relatively at least
19:12:32 <briancurtin> any thoughts on the jenkins/high level reviews? https://review.openstack.org/#/c/121368/ and https://review.openstack.org/#/c/121660/
19:13:39 <briancurtin> i like it enough to start building out swift on it for the talk examples. although i want to try and iron out a better name than "potentate" for those classes, but that's fairly minor bikeshedding (Impl?)
19:14:16 <briancurtin> there is that one import question i had, which could be made easier by dropping 2.6, and dropping 2.6 was also mentioned on that test rearranging review
19:14:39 <jamielennox_> is there a blueprint for this potentate stuff, this is the first i've seen and i'm not getting it
19:15:05 <dhellmann> briancurtin: client libs are expected to retain python 2.6 support for now, so I'm not sure if we should drop it.
19:15:14 <briancurtin> good enough for me
19:16:04 <terrylhowe> jamielennox_: no blueprint I don’t think, take a look at https://review.openstack.org/#/c/121368/3/openstack/identity/v3/potentate.py
19:16:45 <terrylhowe> and the bottom of https://review.openstack.org/#/c/121368/3/openstack/connection.py is where we set all the services up in the connection class https://review.openstack.org/#/c/121368/3/openstack/connection.py
19:17:30 <terrylhowe> sorry there is so much in there, it was hard to break down and it is really just a straw man as Dean would say
19:17:42 <dhellmann> do we have a specs repo? should we?
19:18:32 <terrylhowe> we could probably use a little more formal process dhellmann
19:18:34 <briancurtin> blueprints, specs, ...all new to me, not sure what we have, should have, need, etc
19:18:51 <dhellmann> terrylhowe: it makes the project feel more official :-)
19:18:52 <briancurtin> now that we've gotten a lot of the dirty work out of the way, some process would help
19:19:25 <dhellmann> briancurtin: yeah, that's what I was thinking.
19:19:25 <sigmavirus24> agreed. it's hard to join the project without some outline of what needs to be done
19:19:36 <sigmavirus24> it's why I have not yet contributed anything more than simple reviews
19:19:38 <dhellmann> sigmavirus24: and why what is already done was done...
19:20:08 <briancurtin> i'll look around and see what process is out there and what is being used elsewhere and see what we can bring in
19:20:44 <briancurtin> we sort of started on some blueprints but i/we at the time didnt actually know what we were doing, and we just went ahead and wrote code
19:20:52 <sigmavirus24> yeah, I'm not sure we need all of those to  h appen at once, just some blueprints to start would be helpful so new people can help contribute some code
19:20:58 <dhellmann> yeah, that's a good place to start with experimentation
19:21:15 <stevelle> blueprints or specs or both, what is the smoothest transition?
19:21:20 <dhellmann> blueprints would be a nice lightweight start, but specs aren't really that much work, either
19:21:35 <dhellmann> and they're a heck of a lot easier to comment on
19:21:35 <terrylhowe> blueprints at least would be useful
19:21:52 <stevelle> lightweight seems like a good thing from where the project is right now, and going the right direction.
19:22:08 <briancurtin> i'll take a look back to blueprints after more of this summit talk is prepared
19:22:25 <jamielennox_> i think we dismissed it in the past because too much was in flux
19:22:39 <jamielennox_> a blueprint is a proposal to do something specific and we were all just throwing up code too quick to bother with it
19:22:49 <dhellmann> do we have a launchpad page?
19:22:50 <jamielennox_> it's going to become more important as things start to stabilize
19:23:08 <sigmavirus24> dhellmann: unifiedsdk is the project named
19:23:09 <terrylhowe> https://bugs.launchpad.net/unifiedsdk
19:23:12 <sigmavirus24> *name
19:23:13 <dhellmann> https://launchpad.net/python-openstacksdk is 404
19:23:14 <dhellmann> ah
19:23:36 <briancurtin> yeah we should change the name or something, that whole "unified" name is long gone (not sure if this matters)
19:23:36 <terrylhowe> we should perhaps dump unifiedsdk and use python-openstacksdk
19:23:41 <dhellmann> ok, it's pretty easy to turn on blueprint management there -- let me know if I can help, briancurtin
19:24:03 <dhellmann> renaming a project requires manual intervention from the launchpad admins, but it can be done
19:24:11 <dhellmann> I think you just have to file a bug
19:24:28 <briancurtin> easy enough, i'll look into it
19:24:57 <sigmavirus24> briancurtin: jesse might have to do it if he's the one that registered the project
19:25:02 * sigmavirus24 is guessing
19:25:19 <briancurtin> if he ever takes that horse head mask off i'll get him to look into if, if we need him
19:25:45 <sigmavirus24> :D
19:26:03 <dhellmann> oh, blueprints are already turned on for that project
19:26:05 <dhellmann> https://blueprints.launchpad.net/unifiedsdk
19:26:43 <briancurtin> yeah, those are probably bad, i didnt really know what to be doing there but someone said 'write some blueprints'
19:26:59 <dhellmann> heh
19:27:52 <briancurtin> terrylhowe: since you have the most outstanding code right now, what would be the most help to you?
19:28:26 <terrylhowe> well, there are some bugs that should probably be blueprints like the version discovery stuff
19:29:11 <terrylhowe> there is also the somewhat related missing ability to support multiple verstions of a service
19:29:27 <terrylhowe> I could go through the blueprints and make some up I guess
19:29:38 <terrylhowe> and update what is out there
19:30:04 <briancurtin> yeah i havent gotten around to multiple version like i thought i would
19:30:47 <sigmavirus24> briancurtin: if you ever feel like brain dumping on me, feel free. I can try to help
19:31:13 <briancurtin> we should start brain dumping on the issue tracker and blueprints :)
19:31:38 <stevelle> that
19:31:44 <sigmavirus24> yes. i can also sketch out blueprints from brain dumps =P
19:31:55 <terrylhowe> there are still missing things like image v2, compute extensions, … that are a lot easier to work on
19:32:25 <stevelle> terrylhowe: does supporting multiple versions have potential impacts on image v2?
19:32:50 <dhellmann> briancurtin: an etherpad is another good place to brain dump, since it's easier to clean up than incomplete bugs/blueprints
19:33:02 <terrylhowe> not totally, the problem is in the high level interface
19:36:39 * jamielennox_ has to run - apologies
19:40:55 <briancurtin> besides acting on all of that stuff, anything left to chat on?
19:41:49 <terrylhowe> nothing comes to mind for me
19:42:53 * sigmavirus24 has nothing
19:43:18 <stevelle> nothing more
19:43:29 <sigmavirus24> I'm curious about the necessity of reordering test runs with tox but that's not really something we need to talk about in the meeting
19:45:10 <briancurtin> may as well wrap this up and continue in -sdks then
19:45:11 <briancurtin> thanks all!
19:45:13 <briancurtin> #endmeeting