19:00:15 <briancurtin> #startmeeting python-openstacksdk
19:00:17 <openstack> Meeting started Tue Jun 16 19:00:15 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:20 <openstack> The meeting name has been set to 'python_openstacksdk'
19:00:25 <briancurtin> if you're here for the SDK meeting, say hi
19:00:29 <tpatil> hi
19:00:32 <etoews> o/
19:01:17 <terrylhowe> o/
19:01:57 <briancurtin> #topic Expose 'get_x_openstack_request_id' method in all OpenStack clients api bindings
19:02:07 <tpatil> #link: https://blueprints.launchpad.net/python-openstacksdk/+spec/expose-get-x-openstack-request-id
19:02:08 <briancurtin> so tpatil first thing with this is that we dont work on any of the projects you listed
19:02:26 <briancurtin> so we can maybe do something about this within SDK, but you'd have to talk to those projects to get them to do anything about it
19:02:50 <tpatil> in the last meeting, Doug suggested to talk with SDK team to get this done in the python-*clients.
19:02:58 <briancurtin> yeah that's not us
19:03:21 <briancurtin> tpatil: for example, if you want python-cinderclient changed, you'll have to talk to the cinder team
19:03:24 <terrylhowe> best I can think is the last request id gets saved in the session
19:04:19 <tpatil> we want to add this support to all clients, so do you recommend we should talk with all respective team to get this job done.
19:04:24 <briancurtin> tpatil: yes
19:04:47 <terrylhowe> you could tslk to us as well though
19:04:47 <tpatil> ok,I will do that. Thanks.
19:05:05 <briancurtin> tpatil: i mean we can do this for OpenStack SDK, but if you want other projects changed you'll have to talk to them
19:05:23 <etoews> we're a pretty good starting point though
19:05:29 <tpatil> Ok, Let me explain
19:05:54 <tpatil> right now, X-openstack-request-id is not returned by the client to the caller.
19:06:02 <tpatil> If X-openstack-request-id is available with the user, it will be easy for the service provider to trace any issue by looking at the log messages and respond user quickly with appropriate reasoning
19:06:31 <briancurtin> tpatil: yep, i read the blueprint, and we can do that in our project, but it doesn't seem to be the one you're actually looking for
19:07:37 <tpatil> braincurtin: To get this started, what do you recommend we should be doing?
19:07:56 <briancurtin> tpatil: i would start by talking to the projects that you would like to have modified
19:09:07 <tpatil> briancurtin: Ok, I will create blueprint for each of the project and talk with the team individually then.
19:09:45 <briancurtin> tpatil: sounds good. we'll keep an eye on the one you submitted and can probably add the feature fairly easily. we already had something similar logging transaction ids for object storage
19:10:06 <briancurtin> #topic Roadmap to 1.0
19:10:19 <briancurtin> #link https://etherpad.openstack.org/p/sdk_road_to_1.0
19:10:33 <terrylhowe> https://bugs.launchpad.net/python-openstacksdk/+bug/1465817
19:10:34 <openstack> Launchpad bug 1465817 in OpenStack SDK "Provide method to get latest request id" [Undecided,New]
19:10:36 <terrylhowe> so it is tracked
19:10:44 <briancurtin> tpatil: ^
19:11:24 <briancurtin> in order to keep track of all of the things we're planning on doing, and making sure they get done, i started throwing together all of the things I think we want to get nailed down in order to call ourselves a 1.0
19:11:25 <tpatil> briancurtin: sounds good. I will follow up with this bug
19:11:49 <briancurtin> if anyone has stuff to add, feel free. it's mostly a topic list for right now, and then we can talk about prioritizing once we have everything on the table
19:12:45 <tpatil> I will include all projects to this bug and start submitting patches, is that ok?
19:12:45 <terrylhowe> I plan to be done with the functional tests this week.  Of course it will take a little while to work thought the pipe
19:12:59 <terrylhowe> sure thing tpatil thanks
19:13:39 <etoews> do we also want to start taking the steps towards becoming part of the "big tent"?
19:13:52 <tpatil> terrylhowe: Good, thanks
19:13:53 <briancurtin> etoews: is tehre any good reading on what that actually means?
19:14:11 <etoews> i was going to go have a look for that right now.
19:14:17 <briancurtin> i know the repo changes from stackforge to openstack but i couldnt care less about that
19:15:03 <terrylhowe> as far as big tent, I’d like to see some POC first probably starting with OSC
19:15:44 <terrylhowe> Once I get the functional tests done, I should be free to try something
19:15:50 <etoews> briancurtin: i know it's not a big deal to you but it's a visibility thing for the project.
19:16:06 <etoews> what i've found so far #link http://governance.openstack.org/reference/new-projects-requirements.html
19:16:11 <briancurtin> etoews: i can put aside my non-caring for governance if it actually matters, but i guess i just havent seen that it does
19:19:49 <etoews> imo, it's just one piece of the puzzle. is it an absolute necessity? probably not but i think it would be good to have that piece for a more complete picture.
19:19:54 <briancurtin> terrylhowe: one thing i'm going to start hacking on soon is building support into Ansible that uses SDK instead of pyrax. i had talked to jesse keating a bit after our talk at the summit and he wants to see that as well (i think he's the maintainer of ansible openstack/rackspace support)
19:20:15 <etoews> the more important stuff is what's on the roadmap.
19:20:45 <terrylhowe> ansible would be a good one briancurtin
19:21:33 <etoews> briancurtin: is that a pre or post 1.0 thing?
19:22:21 <etoews> anything that gets used in ansible should be a priority to be functional tested.
19:22:32 <briancurtin> etoews: pre, at least to see where we're at so we build a nice 1.0 beyond building it based on the toy-ish apps we've been using to test out apis and whatnot
19:22:40 <briancurtin> and yeah, should be functionally tested
19:23:52 <terrylhowe> I guess as a final step to the functional tests, I need to finish up generalizing them so they can run in many environments
19:23:56 <briancurtin> once we get caught up on functional tests, any code change should require both unit and functional tests. and docs too, so those don't lag behind either
19:25:04 <etoews> should we take a stab at prioritizing the work in the roadmap?
19:25:47 <briancurtin> terrylhowe: i wonder if we can setup a coverage job to compare functional tests to the proxies?
19:26:14 <terrylhowe> that would be nice, no idea how to do that
19:26:25 <briancurtin> etoews: is everything in that list that you all want to have prioritized?
19:26:36 <terrylhowe> some things are not going to be practical for automated tests
19:26:37 <briancurtin> I just threw what I know and want to see worked on
19:27:33 <briancurtin> And now I'm on mobile because my home internet is flaking out...
19:27:46 <briancurtin> terrylhowe: which things?
19:28:33 <terrylhowe> some operations might be too difficult to functional test, like will we have an instance big enough to fire up a database for example
19:28:48 <terrylhowe> I’m not sure
19:30:10 <etoews> terrylhowe: that's why it will be nice to be able to have it run in many envs, including hp and rackspace.
19:30:28 <terrylhowe> yes, definitely
19:30:50 <terrylhowe> part of the config I’d like to have for the tests is enable/disable for some tests
19:30:50 <etoews> having a full public cloud behind it will make doing more complicated/intensive things easier than with devstack.
19:30:56 <briancurtin> etoews terrylhowe as for prioritizing things, my first thought was to turn that list into launchpad bugs targeted at 1.0 and just use the importance categories. then if you're going to work on one, assign it to yourself -- we haven't been using assignments or importance very much
19:31:27 <terrylhowe> sounds good briancurtin
19:31:37 <terrylhowe> I find the bugs easier to go through than blueprints
19:31:51 <terrylhowe> atm we don’t have too many relatively
19:32:09 <etoews> sgtm
19:33:03 <briancurtin> i'm going to look up how we can switch to numbered milestones instead of the names, and keep the niceties that doug mentioned about the release script closing out bugs and whatnot
19:33:27 <briancurtin> that'll make this stuff easier to track to match up with versions we're actually releasing
19:39:28 <briancurtin> terrylhowe: im going to check with -infra if we can just tag a release and go and have it just work fine. this should probably be 0.6 since we've changed a bunch of names around. is there anything else we want to get in there?
19:40:31 <briancurtin> one more renaming that i might want to squeeze in is volume to block_store (https://review.openstack.org/#/c/190233/) but it's in a merge conflict so i'll adjust it right after this
19:41:01 <briancurtin> we still have the keystore/keymanager/keywhatever to think about as well
19:41:11 <terrylhowe> yeh I was about to mention keymanager
19:41:15 <terrylhowe> and maybe https://bugs.launchpad.net/python-openstacksdk/+bug/1465813
19:41:16 <openstack> Launchpad bug 1465813 in OpenStack SDK "Neutron docs say router:external by implementations use router_type" [Undecided,New]
19:41:31 <terrylhowe> wrong thing there
19:41:48 <terrylhowe> I meant https://review.openstack.org/#/c/188622/
19:42:40 <briancurtin> yep, etoews that one's good, just needs an update ^
19:43:36 <etoews> i'm trying to figure out what the hell i did there and why it's in merge conflict.
19:44:02 <etoews> i think i based it on another branch of mine but i haven't tracked that other branch down yet.
19:44:27 <etoews> i'll figure it out right after this.
19:45:31 <terrylhowe> not all of that is required and most other things can wait I think
19:46:46 <briancurtin> terrylhowe: what should we do on key manager? im not really worried about consistency with what other things call this type of thing when we have to worry about we call everything else in the openstack space
19:48:06 <etoews> with the rename of the project...it that just for python packaging or are we renaming the git repo and launchpad site too?
19:48:56 <terrylhowe> I’m flexible on the key-manager vs key-management thing
19:49:41 <briancurtin> etoews: just the PyPI package name for right now. it might make sense to rename the git repo but i would just save that for if we ever have to move the git repo, such as under /openstack
19:49:55 <etoews> agreed
19:50:42 <briancurtin> terrylhowe: key_management follows that projects.yaml file, but it still reads fine as "the key manager service". i don't love key_manager but it's not really confusing anything by having it
19:50:52 <terrylhowe> in the context of git, I think it makes some sense to have python-
19:51:19 <briancurtin> as long as its clearly identifiable what the service is, and it's not a code name, and it's at least very close to formal definitions of what the thing is, it's probably fine
19:53:47 <etoews> my preference is to go with naming similar to what's in https://github.com/openstack/governance/blob/master/reference/projects.yaml
19:54:59 <briancurtin> etoews: we started with key_manager as requested by doug from barbican, but i suggested key_management per that file and terry updated it, but doug then -1'ed that change set
19:55:05 <etoews> it's the closest thing we have to a source of truth
19:55:11 <briancurtin> etoews: https://review.openstack.org/#/c/187716/
19:55:12 <etoews> :(
19:56:45 <etoews> i guess we can see if doug wants to update projects.yaml...
19:56:59 <etoews> otherwise it just inconsistent for no good reason
19:57:11 <etoews> s/it/it's/
19:57:33 <terrylhowe> sounds reasonable to me
19:57:54 <briancurtin> yeah. if we're creating this to give people consistency, we really should stick with it. if we have to concede this isn't the end of the world in a naming sense, so it's not terrible, but i'll follow up there
20:01:17 <briancurtin> #endmeeting