00:01:33 <cyeoh> #startmeeting nova api
00:01:34 <openstack> Meeting started Fri Mar  6 00:01:33 2015 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:38 <openstack> The meeting name has been set to 'nova_api'
00:01:44 <cyeoh> is anyone around today?
00:02:30 <gmann> hi
00:03:35 <oomichi> hi
00:04:08 <cyeoh> hey
00:04:30 <cyeoh> so first microversion is merged and second is in the gate - thanks for sorting that Ken'ichi
00:05:01 <oomichi> cyeoh: np :) and that is nice for us :)
00:05:12 <gmann> good news :)
00:05:27 <cyeoh> I guess the question is what next?
00:05:46 <oomichi> a nice question :)
00:05:52 <oomichi> so pci extension ?
00:06:13 <cyeoh> it should go back in. I noticed there was an email thread related to it this morning
00:06:42 <oomichi> oh, I missed that
00:06:49 <cyeoh> but what they want doesn't seem to match with that was there originally - I need to read it better, but its possible a modified version will go back in
00:07:37 <cyeoh> need to clarify who (if anyone) was actually using it
00:08:26 <oomichi> cyeoh: yeah, and necessary to consider the API design on devstack-dev ml
00:08:33 <cyeoh> #action chris to sort out what is needed for os-pci and who uses it (since it has always AFAICT been a v3 only thing)
00:08:40 <oomichi> according to the mail.
00:08:46 <oomichi> +1 for the action :)
00:09:20 <cyeoh> yea if its signifcantly different it will need to go back to a spec for L I suspect
00:10:13 <oomichi> yeah, right.
00:10:28 <oomichi> we need a small spec for api changes.
00:10:53 <cyeoh> so other things I can think of: test cleanup (don't think we need a spec)
00:11:11 <cyeoh> start pushing your json home stuff again?
00:11:26 <oomichi> cyeoh: yeah, will do it soon.
00:11:39 <oomichi> and gmann is working for test cleanup.
00:11:51 <cyeoh> cool.
00:12:02 <cyeoh> and I guess moving from tempest to functional in Nova itself
00:12:24 <oomichi> cyeoh: yeah, that is a right direction for nova and tempest.
00:12:39 <gmann> cyeoh: oomichi : As Sean stated in mail, we should have 1 set of tests and sample files
00:13:00 <cyeoh> yep
00:13:19 <oomichi> cyeoh: but the cleanup of service clients is difficult on tempest side, and we need more time for moving tempest tests.
00:13:30 <gmann> that is good idea. only thing we need to twist our tests for merged/split extensions between v2 and v2.1
00:14:06 <gmann> and i remember as you stated it will impact doc. so do not know it that ok?
00:14:15 <cyeoh> ah yea
00:14:32 <cyeoh> so we will need to finish some developer doc for that
00:15:00 <cyeoh> and I need to finish a bunch of developer doc as well for v2.1/microversions
00:15:44 <cyeoh> I think changing the tests is fine, just need to make sure operators know how to transition from v2 to v2.1 and have the REST API look the same from the client point of view
00:17:01 <cyeoh> is there anything anyone else wanted to talk about - in practice anything big we need to plan for L and start getting specs up
00:17:30 <oomichi> cyeoh: nothing from me :)
00:17:56 <oomichi> cyeoh: so what is the big plan for L, you have?
00:18:31 <gmann> cyeoh: after test merge  v2 API doc will not be having the separate extension doc fro example flavor disabled etc
00:18:47 <oomichi> cyeoh: will you revert v3 changes with microversions?
00:18:53 <cyeoh> I don't have anything big for L. I'd like to concentrate on stabilisation. make sure v2 is truly redundant and then we can remove it
00:19:34 <oomichi> yeah, +1 for that
00:19:51 <cyeoh> gmann: yea developing a better (more automated) workflow will be better there. And there's little things like having the api version history automatically published etc
00:20:46 <cyeoh> oomichi: so I think we've got agreement we can make the changes when were changing something anyway - eg a pushed some keypairs changes in the last one that change the api to the direction we want
00:20:56 <gmann> ok
00:20:59 <cyeoh> but we won't make a global camelcase change.
00:21:11 <cyeoh> but we should look for opportunities when people propose api changes
00:21:42 <oomichi> ah, I see the change process on that
00:21:56 <gmann> same direction for status code also?
00:22:12 <cyeoh> yes definitely
00:22:49 <cyeoh> and definitely block any api changes to the old v2 code
00:22:52 <oomichi> if spec of api-wg is concreate, we can change status codes based on that, I feel
00:23:59 <oomichi> but I don't want to make a lot of microversions due to small changes of each api status code
00:24:08 <cyeoh> if its in an api which is not otherwise changing i think we'll have to consult the mailing list first
00:24:47 <cyeoh> its the operators which are going to feel the pain from it. maybe can talk about it at summit while everyone is there?
00:25:04 <oomichi> agree, we don't have enough samples on microversions, so mailing list is nice for discussing
00:25:17 <gmann> +1
00:25:36 <oomichi> cyeoh: will you go to the next summit?
00:25:58 <cyeoh> oomichi, unfortunately looks like I wont be able to again :-( Will find out in a couple of weeks
00:26:09 <cyeoh> just medical reasons again
00:26:28 <oomichi> cyeoh: oh, that is sorry for us.
00:26:47 <oomichi> cyeoh: I will go to the next summit
00:26:51 <cyeoh> sorry for me too - would love to visit vancouver ;-)
00:27:01 <gmann> humm
00:27:09 <cyeoh> oomichi: excellent! And the Tokyo one will be close for you!
00:27:33 <mtreinish> cyeoh: I'll be at the ops midcycle next week if you guys wanted to get some feedback on something. I can ask there
00:27:45 <oomichi> cyeoh: the next next summit is japan, so I'd like to say to you "welcome" :)
00:28:01 <cyeoh> oomichi: heh :-)
00:28:33 <cyeoh> mtreinish: its more of getting the balance right between fixing errors in the API (eg incrorrect status codes) versus the pain from api users when they change
00:29:00 <cyeoh> mtreinish: finding out what people prefer we lean towards
00:29:38 <cyeoh> mtreinish: currently attitude is if we have to make change in the api anyway which will cause some pain we'll probably fix incorrect status codes at the same time.
00:29:50 <cyeoh> but if not we're a lot more likely to leave them wrong
00:30:14 <cyeoh> if lots of people say no we're happy to take the pain on status codes then we're happy to fix them
00:30:58 <cyeoh> mtreinish: similarly for types or CamelCase/Snake_Case for parameter names
00:31:57 <mtreinish> cyeoh: ok, sure I'll try to remember to ask. It definitely is a balancing act on that kind of change
00:32:43 <cyeoh> mtreinish: thanks! yea, probably something to put on the next survey
00:33:14 <cyeoh> anything else from anyone? Otherwise we'll take an early minute
00:33:22 <gmann> whats about adding new response attribute which we removed recently? i think those can go like keypair one.
00:33:54 <cyeoh> gmann: have you got an example of that
00:34:22 <oomichi> AccessIPv4 from "create a server" response?
00:34:32 <oomichi> as a sample
00:35:06 <cyeoh> oh that was a v3 thing? I think we'd need to go through specs for L
00:35:13 <gmann> oomichi: yes, i also remember that only at moment
00:35:42 <oomichi> cyeoh: +1, that seems nice dev process.
00:36:17 <gmann> another is OS-EXT-STS:locked_by in server show/detail
00:36:55 <cyeoh> did locked_by never make V2?
00:37:49 <gmann> i think no
00:37:57 <cyeoh> that one went through specs originally so I'll have a look but we can probably add it back as microversion and quote the original spec
00:38:38 <oomichi> ok, maybe we cannot push more microversions in Kilo if changes are without specs.
00:39:16 <cyeoh> yea we're also pass feature proposal freeze too I think - but something for early in L
00:39:34 <gmann> yea
00:40:37 <cyeoh> ok. anything else?
00:40:50 <gmann> nothing from my side
00:41:17 <cyeoh> ok cool, thanks everyone for coming. Seeya next week!
00:41:28 <cyeoh> #endmeeting