00:00:44 <cyeoh> #startmeeting nova api
00:00:44 <openstack> Meeting started Fri Sep 12 00:00:44 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:00:47 <openstack> The meeting name has been set to 'nova_api'
00:00:59 <cyeoh> Hi - who's here today?
00:01:02 <oomichi> hi
00:01:02 <alex_xu> \o/
00:01:06 <gmann> hi
00:01:31 <cyeoh> #link https://wiki.openstack.org/wiki/Meetings/NovaAPI#Agenda
00:01:42 <cyeoh> #topic V2.1 on V3 API
00:02:12 <cyeoh> ok so except for bug fixes we're not going to get anymore of the v2.1 on v3 patches into Juno
00:02:27 <cyeoh> but I think its fine for us to continue working on them and push them to gerrit
00:02:41 <cyeoh> oomichi or I can -2 them until Kilo opens in a few weeks
00:02:59 <oomichi> yeah, agree.
00:03:31 <oomichi> but it is a little difficult to handle a bug or v2.1 patches.
00:03:36 <cyeoh> there's still some networking related ones to port. And we need to do a pass through all of them to verify recent mergers to V2 are reflected in v2.1
00:03:57 <cyeoh> oomichi: I think we can merge v2.1 related bug patches?
00:04:09 <oomichi> eg: https://review.openstack.org/#/c/120328/
00:04:47 <cyeoh> oomichi: yea I think we wait until next week to approve
00:05:00 <cyeoh> but should be fine through the rc's
00:05:49 <oomichi_> maybe nova-network API should be deffered to Kilo as non-bug patches.
00:05:57 <alex_xu> sorry for introduce those bug by me
00:06:06 <cyeoh> oomichi: yes nova network should definitely be deferred to Kilo
00:06:24 <cyeoh> bugs we find through tempest testing I think is ok to apply as long as they are small
00:06:43 <gmann> cyeoh: oomichi: there is one more about server address for V2.1 and this has lot of file changes ~30 mainly in sample files
00:06:48 <oomichi_> cyeoh: that is fine for me.
00:06:57 <gmann> so can we release that as bug fix?
00:07:12 <oomichi_> gmann: too big..
00:07:45 <cyeoh> yea agreed if in doubt, just delay it. A few weeks delay won't hurt us
00:08:04 <gmann> ok.
00:08:12 <cyeoh> but do push them up to gerrit so we can see what is going on
00:08:23 <cyeoh> and I do like that you've been updating the etherpad with the results of your testing
00:08:24 <oomichi_> I'm not sure that we can decide it in juno, but it is ok to post it and i will review it.
00:08:40 <gmann> but  but that cause backward incompatibility between V2 and V2.1 for J, is it fine?
00:09:10 <gmann> oomichi_ ok. sounds good
00:09:12 <cyeoh> gmann: yea v2.1 for juno is purely experimental and disabled by default
00:09:41 <oomichi_> gmann: basically you are right. but it is also v2.1 bp work.
00:10:04 <gmann> oomichi_ yes :)
00:10:06 <oomichi_> gmann: that is a reason why I feel it is difficult to handle these patches.
00:10:20 <oomichi_> gmann: juno or kilo.
00:10:53 <cyeoh> we just didn't have enough time to do sufficient testing for v2.1 in Juno so I'm ok with it being pretty dodgy for Juno
00:11:09 <cyeoh> we need to get it right early in Kilo though (say by K-1)
00:11:16 <oomichi_> cyeoh: yes, agree.
00:11:19 <gmann> yes
00:11:50 <cyeoh> anything else on V2.1 on V3?
00:12:08 <oomichi_> nothing special from me
00:12:08 <alex_xu> there is patch for sync server external event https://review.openstack.org/#/c/108806/
00:12:55 <cyeoh> alex_xu: oh good catch. COuld you add that to the etherpad?
00:13:08 <alex_xu> cyeoh, ok
00:13:19 <cyeoh> #topic kilo cycle planning
00:13:29 <cyeoh> #link https://etherpad.openstack.org/p/Nova_API_Kilo_Planning
00:13:51 <cyeoh> So I've put some ideas up on what I think we should be working on API-related in Kilo
00:13:58 <cyeoh> please feel free to add
00:14:26 <cyeoh> Obviously completing v2.1 and tempest verification is the highest priority
00:14:38 <oomichi_> microversion is a big topic.
00:14:55 <cyeoh> and I suspect tempest coverage is incomplete so we might need to do some work there otherwise we'll get surprises later on
00:15:13 <cyeoh> yes, microversions I think we will need to do in parallel from the start of Kilo
00:15:26 <oomichi_> cyeoh: sounds good.
00:15:33 <cyeoh> oomichi_: hopefully we can have something to talk about at summit?
00:15:57 <oomichi_> cyeoh: yes, I also want to talk.
00:16:10 <cyeoh> oomichi_: is the response checking in tempest for nova complete now - or do we still need more work there?
00:16:40 <oomichi_> cyeoh: yeah, that is complete now.
00:16:59 <oomichi_> cyeoh: I don't think  we need more work for it.
00:17:04 <cyeoh> oomichi_: cool :-) btw I won't be at the summit so you'll be speaking for all of us re: microversions
00:17:23 <oomichi_> cyeoh: re: tempest, can we remove v3 api tests from tempest. or keep them now?
00:18:02 <cyeoh> oomichi_: I'm tempted to say we can remove them. I guess the v2.1 tempest microversion checking will look very different
00:18:04 <oomichi_> cyeoh: v3 api tests are disabled on the gate, it is ok to keep them at this time.
00:18:29 <cyeoh> well perhaps we could delay until we have further discussions about microversions
00:18:39 <cyeoh> because we may be able to reuse parts
00:19:01 <oomichi_> cyeoh: nice idea. I agree with keeping them until discussions.
00:19:31 <gmann> cyeoh, oomichi_ : i also think we can keep for re-usability if needed
00:19:44 <cyeoh> So the other thing I listed on the etherpad was cleanups/reducing technical debt
00:20:15 <cyeoh> and I think we should spend a reasonable time on this sort of stuff in Kilo to make life for us in the future easier
00:20:49 <oomichi_> I am interested in jaypipes's speedup task of sample tests :-)
00:20:56 <cyeoh> some of the unittest code is really really horrible with lots of duplicated stuff. Bits of stubs intermingled with mock etc
00:21:05 <cyeoh> and it makes it hard to understand and debug failures
00:21:14 <cyeoh> plus we end up with races
00:21:23 <cyeoh> oomichi_: yes that sounds very interesting!
00:21:55 <oomichi_> the etherpad is nice already, thanks
00:21:57 <cyeoh> also api samples is horrible code - and generating lots of identical template and responses for server creation is silly
00:22:08 <cyeoh> and we have gaps in what api samples are checked
00:22:48 <oomichi_> cyeoh: I agree. I have a plan replacing sample tests with the api definition of jsonschema
00:22:49 <cyeoh> so I think we should have a bit of a rethink about api samples and how we can autogenerate documentation in conjunction with the input validation schema
00:23:44 <oomichi_> cyeoh: oh, conflicting idea :-)
00:24:07 <cyeoh> the api sample tests are kind of useful in they pick up bugs which unittests don't - because they bring up a proper api server
00:24:18 <cyeoh> so plugins not loading properly etc gets detected
00:25:00 <cyeoh> also the json schema doesn't cover url parameters
00:25:45 <cyeoh> but I think we need to think about how we can autogenerate a lot of the api docs because thats a horrible manual workflow at the moment
00:25:51 <alex_xu> will we introduce response json-schema into nova?
00:26:19 <oomichi_> alex_xu: that is a plan of Tempest from qa-core.
00:26:25 <cyeoh> alex_xu: so I think the long term plan is to move the response json-schema tests from tempest to nova
00:26:48 <oomichi_> alex_xu: the plan is that current api tests of tempest are moved to each project from tempest.
00:26:49 <cyeoh> we need to setup the infrastructure to do that in Nova though (eg spinning up api servers etc)
00:27:13 <oomichi_> cyeoh: yeah, right.
00:27:22 <alex_xu> I'm still thinking of use json-schema to eliminate the json-format knowledge from python-code
00:27:36 <oomichi_> and response jsonschema also are moved from Tempest to nova.
00:27:50 <oomichi_> s/are/will be/
00:29:08 <alex_xu> what mean spinning up api servers? why move response json-schema into nova is long term, any block issue?
00:29:41 <cyeoh> alex_xu so in tempest we spin up a whole devstack instance to run our tests against
00:30:04 <cyeoh> we'll need to at least spin up a full Nova for the equivalent tests
00:30:12 <gmann> i think as response schema are ready we can have plan to move those in K and start validating the response through schema
00:30:32 <cyeoh> eg we don't want to be mocking Nova parts for the api tests
00:30:39 <alex_xu> spin up a full nova in nova integrated tests?
00:31:10 <cyeoh> gmann: that's true - we can apply response schema in real time and 500 if there's an issue
00:31:40 <cyeoh> gmann: I think we should do some performance testing though or make it optional - because the overhead may be signficiant if you're say listing 1000 servers
00:31:58 <oomichi_> cyeoh: that is a nice point.
00:32:08 <cyeoh> alex_xu: for the ported api tests from tempest yes
00:32:16 <oomichi_> cyeoh: the performance issue is my concern about strong validation.
00:32:29 <gmann> cyeoh: yes agree. performance can be issue.
00:32:44 <oomichi_> cyeoh: if adding it for response also, we need to check workload of it.
00:32:55 <cyeoh> oomichi_: yep for input I think we're ok. for output I don't know. We probably should setup a small set of baseline performance tests
00:33:47 <cyeoh> some base performance numbers would be very handy for checking that other api changes are ok too - eg lazy loading of server information etc
00:33:47 <oomichi_> cyeoh: perfect, that seems to fit to current direction of qa-program also :-)
00:34:48 <cyeoh> yup!
00:35:23 <cyeoh> ok so if you have any other ideas for what we should be doing in Kilo please add them to the etherpad. For some things we'll need to organise a nova-spec
00:35:44 <cyeoh> alex_xu: we should probably work on the api policy cleanup if we have time
00:35:52 <alex_xu> cyeoh, yes
00:36:06 <alex_xu> cyeoh, I wil work on it
00:36:15 <cyeoh> alex_xu: excellent :-)
00:36:22 <cyeoh> #topic server group quotas
00:36:38 <oomichi_> alex_xu: moving policy is not completed now?
00:37:03 <alex_xu> oomichi_, actually policy stuff didn't start yet...
00:37:27 <cyeoh> oomichi_: just small bits done
00:37:28 <alex_xu> oomichi_, the spec is pretty close, but block by v2 on v3 debt
00:37:37 <oomichi_> alex_xu: OK, I got it. I prefer it and I hope it is written on the etherpad.
00:37:54 <alex_xu> oomichi_, yes, will do
00:38:03 <oomichi_> alex_xu: thanks :-)
00:38:09 <alex_xu> oomichi_, np:)
00:38:52 <cyeoh> PhilD has the server group quota patches which hopefully will merge before the end of FFE - I think they might not be cutting Juno-3 until Monday?
00:39:23 <cyeoh> Anyway I'm sure he'd appreciate reviews of his patches - it'd be nice to get it merged
00:39:30 <cyeoh> as its very very close now I think
00:39:34 <oomichi_> cyeoh: yeah, I hope so.
00:39:42 <alex_xu> I'm doing last testing
00:39:56 <alex_xu> feel pretty close
00:40:02 <oomichi_> now the gate is very busy, and maybe the patches need to be approved today.
00:40:08 <oomichi_> http://status.openstack.org/zuul/
00:40:16 <cyeoh> yea 26 hours I think :-(
00:40:17 <oomichi_> 155 patches are on the gate..
00:40:33 <cyeoh> I think his tempest change is still 7 hours away
00:40:43 <oomichi_> the longest patch is in 31 hours on the gate..
00:41:00 <cyeoh> ah its getting longer....
00:41:18 <cyeoh> #topic open discussion
00:41:39 <cyeoh> does anyone have anything for open discussion?
00:41:56 <alex_xu> found one patch that fix some broken api https://review.openstack.org/#/c/117438/
00:42:09 <alex_xu> but that patch need rebase
00:42:58 <oomichi_> alex_xu: nice catch, I will review it.
00:43:04 <alex_xu> oomichi_, thanks
00:43:05 <cyeoh> hopefully he will rebase it soon...
00:43:41 <alex_xu> yea...
00:43:53 <oomichi_> alex_xu: btw, are you checking all patches on the gerrit ? you are a good catcher:-)
00:44:36 <alex_xu> oomichi_, thanks, just found by review, not checking all the patches :)
00:45:20 <oomichi_> alex_xu: sounds great, thanks for doing that
00:45:31 <alex_xu> oomichi_, np
00:45:44 <cyeoh> ok is there anything else for open discussion?
00:46:17 <gmann> nothing from my side
00:46:20 <alex_xu> that's all for me
00:46:45 <oomichi_> yeah, good for me already.
00:46:53 <cyeoh> ok thanks everyone. We'll end a bit early then.
00:47:06 <cyeoh> #endmeeting