00:01:03 <cyeoh> #startmeeting nova-api
00:01:05 <openstack> Meeting started Fri Mar 14 00:01:03 2014 UTC and is due to finish in 60 minutes.  The chair is cyeoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:05 <cyeoh> Hi - so is anyone here?
00:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:09 <openstack> The meeting name has been set to 'nova_api'
00:01:26 <ken1ohmichi> hi
00:01:29 <masayukig> hi o/
00:01:32 <changsimon_> hello
00:01:40 <mrda> o/
00:01:40 <alex_xu> hello
00:01:52 <alaski> here, but about to eat so may drop out
00:02:10 <cyeoh> alaski: cool - np.
00:02:50 <cyeoh> ok so I thought we might have to start with introductions, but I think most people already know everybody else already?
00:02:59 <cyeoh> so why don't we start with the v2 on v3 API POC
00:03:01 <cyeoh> #topic v2_on_v3_poc
00:03:09 <cyeoh> #link https://etherpad.openstack.org/p/NovaV2OnV3POC
00:03:29 <cyeoh> That's where we've been trying to map out what we want done as a POC for Atlanta
00:03:53 <cyeoh> I don't think anyone expect that we'll be finished by then but I think we want to be able to say what we're doing for the various cases
00:04:14 <cyeoh> and be able to get those bits up and running in devstack. Having some rough tempest stuff would be nice too
00:04:32 <cyeoh> I think there's a couple of important points of what we're aiming for.
00:04:45 <cyeoh> The first is that 2.1 will be 2.0 but with strong input validation
00:05:00 <cyeoh> does anyone think that will be an unreasonable restriction to add for V2.1?
00:05:29 <mrda> I think it's a good thing for us to be doing
00:06:03 <cyeoh> ok. It does make our life much easier and I have sent an email to the list asking if anyone had problems with it - but no responses.
00:06:04 <ken1ohmichi> yes, I also agree
00:06:19 <alex_xu> I agree too
00:06:43 <alaski> I think it's very reasonable
00:06:55 <alaski> even in the keep v2 proposal there was support for validation
00:07:13 <cyeoh> ok that sounds good then
00:07:22 <cyeoh> the second is around the list of extensions we display.
00:07:41 <cyeoh> since in V3 we have both split extensions (admin_actions) and collapsed a few - because they were just placeholders
00:07:46 <cyeoh> we don't have a complete 1:1 mapping
00:08:07 <cyeoh> so for V2.1 do we need to display the same list of extensions even if we are presenting the same API to users?
00:08:40 <cyeoh> I think if we really needed to we could fake it, but its custom code that would be nice to avoid having to do.
00:09:10 <cyeoh> I think along similar lines is if we want to display the same info in /extensions - since we don't have an updated parameter anymore
00:09:39 <cyeoh> anyone have any thoughts on this?
00:09:46 <alex_xu> I think yes, the list of extensions are used by user to check some api enabled or not before
00:10:02 <alex_xu> but how can we emulate enable or disable extension?
00:10:02 <mrda> perhaps this should be a point for discussion in Atlanta - i.e. we know how we could solve it, but we'd rather focus our efforts on other things.  How does that sound?
00:10:40 <cyeoh> alex_xu: yes that is my concern. There will be some restriction on being able to deploy one extension but not another in cases of collapsing extensions but I think all the cases are manageable
00:11:21 <cyeoh> mrda: yes given the timeframe that may be the best approach. I think its all fakeable. But we really need feedback from cloud providers and users as to how much pain this will cause
00:12:12 <mrda> agreed, as this is a POC it doesn't need to be drop-in-ready by Atlanta :)
00:12:38 <cyeoh> mrda: heh, no this a cycle's worth of work really ;-)
00:12:40 <mrda> I guess we can solve it if we have agreement on the approach.  I just don't think it's a core problem right now
00:13:10 <alaski> I think that extensions are going to have to match what v2 offers currently, which is unfortunate
00:13:12 <alaski> but I agree that it's manageable
00:13:29 <cyeoh> ok. I'm fine with that approach.
00:18:27 <cyeoh> so I've created a holding blueprint for the POC patches https://blueprints.launchpad.net/nova/+spec/v2-on-v3-api
00:18:27 <cyeoh> please add that to the proof of concept patches which you upload so we can easily find them. I know there are some out there already :-)
00:18:28 <cyeoh> #link https://review.openstack.org/#/c/77105/
00:18:28 <ken1ohmichi> I feel most important thing is backward compatibility, so it would be possible to drop some v3 API features for comatibility. I hope avoiding the situation, of course
00:18:28 <ken1ohmichi> and I do effort for keeping v3 features now:)
00:18:28 <cyeoh> #link https://review.openstack.org/#/dashboard/5754 (alex has a couple too)
00:18:30 <cyeoh> ken1ohmichi: so I think the worst case what we can do is have a plugins/v2/  directory
00:18:30 <cyeoh> which loads a v2 specific plugin which proxies to v3
00:18:30 <cyeoh> but I think the vast majority of cases will be much simpler and we can do it through decorators
00:18:31 <cyeoh> we just need a fallback plan where that doesn't work.
00:18:31 <ken1ohmichi> oh, not so bad:)
00:18:31 <cyeoh> in general I'd like to keep the simple cases (eg just success code translation/request body translation) solved using very simple solutions
00:18:31 <ken1ohmichi> but yes, we need to make it simple.
00:18:31 <alex_xu> I guess, this is the fallback plan https://review.openstack.org/#/c/78906/
00:18:31 <alex_xu> But i agree, we should to try it simple first
00:18:31 <cyeoh> I think a useful thing to keep in mind when doing this is can we apply these same sort of principles in the future to handle backwards incompatible changes?
00:18:32 <cyeoh> yes, if you have time please look at some of alex_xu's patches - there are some alternative strategies (with increasing complexity) in different patchsets
00:18:55 <cyeoh> and I think we should just try to fit the most simple solution on a case by case basis
00:19:33 <ken1ohmichi> cyeoh: agree, it can keep maintenance cost low
00:19:48 <cyeoh> So the the etherpad link tries to keep track of all the different v2 on v3 scenarios we have to handle - if you find another one please add it.
00:20:14 <cheetah2> whats the best way to run openstack?
00:20:21 <cheetah2> bare metal?
00:20:22 <cyeoh> is there anything else anyone would like to discuss re: the v2 on v3 POC?
00:20:42 <cyeoh> cheetah2: I think you want to ask those sorts of questions in the #openstack channel
00:27:22 <cheetah2> oj
00:27:22 <cheetah2> ok
00:27:23 <cyeoh> #topic api response validation in tempest
00:27:24 <cyeoh> #link https://etherpad.openstack.org/p/nova-api-attribute-test
00:27:24 <cyeoh> ken1ohmichi has some really nice stuff merged where we can now verify that the attributes we expect in response bodies actually are there and are of the right format/type
00:27:24 <cyeoh> this will really help us with v2.1 validation
00:27:25 <ken1ohmichi> yes, that would be necessary for v2.1 PoC
00:27:25 <cyeoh> ken1ohmichi: yes I don't think we necessarily have to have it finished by Atlanta, but we need to show that we can do it (and its good to have whatever route we take)
00:27:25 <cyeoh> I guess I'd like for us to decide whether we're going to go the check in client or test route before we merge any more patches though
00:27:25 <cyeoh> #link https://review.openstack.org/#/c/80202/
00:27:25 <cyeoh> that's the WIP I have for the check in client route
00:27:25 <cyeoh> (I think the Jenkins failure in that one is probably bogus)
00:27:25 <ken1ohmichi> agree, and I picked up some APIs as PoC targets. so I think we need to implement these APIs validation in Tempest. It would be enough to merge these APIs by Atlanta.
00:27:26 <ken1ohmichi> cyeoh: I like https://review.openstack.org/#/c/80202/ idea
00:27:26 <cyeoh> ken1ohmichi: yes that sounds good. So I'll start working on trying to identify the list of extensions that we want to target
00:27:26 <GMann_> I also agree with this design. This add one more benefit that in each test each response will get validated even of different client.
00:27:26 <cyeoh> does anyone have any problems with the direction that 80202 is taking?
00:27:27 <mrda> lgtm
00:27:27 <cyeoh> GMann_: yea that's a nice side effect
00:27:28 <cyeoh> ok if no one has any problems then I think we can just comment on the existing validation patches in the queue out there asking them to rework them
00:27:46 <ken1ohmichi> GMann_: yes, the design is perfect for me.
00:27:49 <mrda> so we're happy holding up 80202 as the canonical design approach?
00:28:37 <cyeoh> mrda: yea, I think we should point people to that one and I'll remove the WIP flag.
00:29:02 <ken1ohmichi> mrda: I agree to seeing it as the canonical design approach
00:29:10 <mrda> cool
00:29:27 <cyeoh> anyone have anything else on the response validation?
00:30:19 <cyeoh> I guess I should mention that I think in the long term we should Nova producing the schema files - so they can be used for unittests, docs and tempest tests
00:30:41 <cyeoh> but for now generating them in tempest is fine.
00:30:48 <mrda> cyeoh: agreed
00:31:06 <ken1ohmichi> yes, that is fine now.
00:31:25 <cyeoh> As part of the design process for new API's I'd like to ask people to write json schema for both the request and responses though.
00:31:29 <GMann_> yes. looks ok
00:31:51 <cyeoh> because it forces people to think a lot more about what their API looks like to users (and the wierd edge conditions)
00:32:23 <mrda> cyeoh: great idea - might as well start off on the right foot, and prevent API degredation
00:33:12 <cyeoh> mrda: yea we've really struggled with some api reviews in icehouse and a lot of it has come down to not enough design work being done before coding ...
00:33:31 <ken1ohmichi> cyeoh: asking for request schema would be fine. but the one of response schema is a little overload, because Nova does not use it now.
00:34:32 <cyeoh> ken1ohmichi: that is true. Api samples give us an insight to the responses atm. But one common problem I've seen is that people always right the most simple api sample test they think they can get away with
00:34:33 <ken1ohmichi> cyeoh: you image Nova will use resonse schema in the future?
00:34:50 <cyeoh> so we don't actually see all of what Nova could return
00:35:02 <cyeoh> ken1ohmichi: yea I think we really should be using the response schema in the future
00:35:19 <cyeoh> ken1ohmichi: its kind of required if we're going to have a discoverable api like sdague has been pushing for
00:35:30 <mrda> ken1ohmichi: I think if we show as part of this POC how it can be useful, we might convince the better approach in the long run
00:35:32 <cyeoh> and it makes the whole docs process a lot easier
00:36:01 <ken1ohmichi> cyeoh: I got it, thanks. and the other guy also gave the same idea when reviewing request body schema.
00:36:20 <cyeoh> ken1ohmichi: cool
00:36:45 <cyeoh> #topic open discussion
00:36:59 <cyeoh> alaski: did you want to talk about tasks at all?
00:37:00 <GMann_> I would like to add one point- should we define new directory structure for schema file like /tempest/api_schema/comute/.. instead of current one /tempest/api/compute/..
00:37:33 <alaski> cyeoh: I don't have much more beyond what came out of the mid cycle meetup at this point
00:37:55 <alaski> the work has been deferred for feature freeze, but I hope to have something up shortly after
00:38:23 <cyeoh> alaski: ok, sounds good. I guess at some point we'll need to work out what we're doing re: v2 vs v3 too...
00:38:29 <tinoue> alaski: +1
00:38:42 <alaski> cyeoh: yep
00:38:55 <alaski> everything except multiple create fits in fairly well
00:39:12 <cyeoh> GMann_: will get to you in a sec
00:39:20 <alaski> and I think we can come up with something for that
00:39:31 <cyeoh> alaski: yea there is a patch that does multiple create out there now
00:39:33 <GMann_> sure.
00:39:35 <cyeoh> (without tasks)
00:39:49 <cyeoh> I'm just trying to remember who did it
00:40:08 <alaski> it may have been melwitt, iirc
00:40:15 <cyeoh> yea, that's right.
00:40:18 <alaski> I need to look that one over again
00:40:36 <cyeoh> So I think the one thing it might need is to handle multi status 207
00:40:57 <alaski> ok
00:41:03 <alaski> I'll read up on that code
00:41:08 <alaski> status code
00:41:18 <cyeoh> so although we return a list of server responses if one or more of them fail, they individually get a status code
00:41:54 <alaski> nice, that would be ideal
00:42:43 <cyeoh> so server_external_events is an example of how we handle a 207 now
00:43:41 <alaski> cool, I'll check that out
00:44:13 <cyeoh> GMann_: I think you brought up a good point before. I don't have any strong feelings over this, but it does sort of make sense that eventually we will have schema to check all the services
00:44:37 <cyeoh> and if we change the directory we should do it now before too much gets merged :-)
00:44:52 <GMann_> yes,
00:45:40 <cyeoh> ken1ohmichi: what do you think?
00:45:49 <ken1ohmichi> GMann_'s idea seems good,
00:53:32 <cyeoh> ok anything else people would like to discuss?
00:54:09 <cyeoh> thanks everyone for attending!
00:54:21 <cyeoh> #endmeeting