00:01:03 #startmeeting nova-api 00:01:05 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 Hi - so is anyone here? 00:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:01:09 The meeting name has been set to 'nova_api' 00:01:26 hi 00:01:29 hi o/ 00:01:32 hello 00:01:40 o/ 00:01:40 hello 00:01:52 here, but about to eat so may drop out 00:02:10 alaski: cool - np. 00:02:50 ok so I thought we might have to start with introductions, but I think most people already know everybody else already? 00:02:59 so why don't we start with the v2 on v3 API POC 00:03:01 #topic v2_on_v3_poc 00:03:09 #link https://etherpad.openstack.org/p/NovaV2OnV3POC 00:03:29 That's where we've been trying to map out what we want done as a POC for Atlanta 00:03:53 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 and be able to get those bits up and running in devstack. Having some rough tempest stuff would be nice too 00:04:32 I think there's a couple of important points of what we're aiming for. 00:04:45 The first is that 2.1 will be 2.0 but with strong input validation 00:05:00 does anyone think that will be an unreasonable restriction to add for V2.1? 00:05:29 I think it's a good thing for us to be doing 00:06:03 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 yes, I also agree 00:06:19 I agree too 00:06:43 I think it's very reasonable 00:06:55 even in the keep v2 proposal there was support for validation 00:07:13 ok that sounds good then 00:07:22 the second is around the list of extensions we display. 00:07:41 since in V3 we have both split extensions (admin_actions) and collapsed a few - because they were just placeholders 00:07:46 we don't have a complete 1:1 mapping 00:08:07 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 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 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 anyone have any thoughts on this? 00:09:46 I think yes, the list of extensions are used by user to check some api enabled or not before 00:10:02 but how can we emulate enable or disable extension? 00:10:02 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 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 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 agreed, as this is a POC it doesn't need to be drop-in-ready by Atlanta :) 00:12:38 mrda: heh, no this a cycle's worth of work really ;-) 00:12:40 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 I think that extensions are going to have to match what v2 offers currently, which is unfortunate 00:13:12 but I agree that it's manageable 00:13:29 ok. I'm fine with that approach. 00:18:27 so I've created a holding blueprint for the POC patches https://blueprints.launchpad.net/nova/+spec/v2-on-v3-api 00:18:27 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 #link https://review.openstack.org/#/c/77105/ 00:18:28 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 and I do effort for keeping v3 features now:) 00:18:28 #link https://review.openstack.org/#/dashboard/5754 (alex has a couple too) 00:18:30 ken1ohmichi: so I think the worst case what we can do is have a plugins/v2/ directory 00:18:30 which loads a v2 specific plugin which proxies to v3 00:18:30 but I think the vast majority of cases will be much simpler and we can do it through decorators 00:18:31 we just need a fallback plan where that doesn't work. 00:18:31 oh, not so bad:) 00:18:31 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 but yes, we need to make it simple. 00:18:31 I guess, this is the fallback plan https://review.openstack.org/#/c/78906/ 00:18:31 But i agree, we should to try it simple first 00:18:31 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 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 and I think we should just try to fit the most simple solution on a case by case basis 00:19:33 cyeoh: agree, it can keep maintenance cost low 00:19:48 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 whats the best way to run openstack? 00:20:21 bare metal? 00:20:22 is there anything else anyone would like to discuss re: the v2 on v3 POC? 00:20:42 cheetah2: I think you want to ask those sorts of questions in the #openstack channel 00:27:22 oj 00:27:22 ok 00:27:23 #topic api response validation in tempest 00:27:24 #link https://etherpad.openstack.org/p/nova-api-attribute-test 00:27:24 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 this will really help us with v2.1 validation 00:27:25 yes, that would be necessary for v2.1 PoC 00:27:25 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 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 #link https://review.openstack.org/#/c/80202/ 00:27:25 that's the WIP I have for the check in client route 00:27:25 (I think the Jenkins failure in that one is probably bogus) 00:27:25 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 cyeoh: I like https://review.openstack.org/#/c/80202/ idea 00:27:26 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 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 does anyone have any problems with the direction that 80202 is taking? 00:27:27 lgtm 00:27:27 GMann_: yea that's a nice side effect 00:27:28 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 GMann_: yes, the design is perfect for me. 00:27:49 so we're happy holding up 80202 as the canonical design approach? 00:28:37 mrda: yea, I think we should point people to that one and I'll remove the WIP flag. 00:29:02 mrda: I agree to seeing it as the canonical design approach 00:29:10 cool 00:29:27 anyone have anything else on the response validation? 00:30:19 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 but for now generating them in tempest is fine. 00:30:48 cyeoh: agreed 00:31:06 yes, that is fine now. 00:31:25 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 yes. looks ok 00:31:51 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 cyeoh: great idea - might as well start off on the right foot, and prevent API degredation 00:33:12 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 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 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 cyeoh: you image Nova will use resonse schema in the future? 00:34:50 so we don't actually see all of what Nova could return 00:35:02 ken1ohmichi: yea I think we really should be using the response schema in the future 00:35:19 ken1ohmichi: its kind of required if we're going to have a discoverable api like sdague has been pushing for 00:35:30 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 and it makes the whole docs process a lot easier 00:36:01 cyeoh: I got it, thanks. and the other guy also gave the same idea when reviewing request body schema. 00:36:20 ken1ohmichi: cool 00:36:45 #topic open discussion 00:36:59 alaski: did you want to talk about tasks at all? 00:37:00 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 cyeoh: I don't have much more beyond what came out of the mid cycle meetup at this point 00:37:55 the work has been deferred for feature freeze, but I hope to have something up shortly after 00:38:23 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 alaski: +1 00:38:42 cyeoh: yep 00:38:55 everything except multiple create fits in fairly well 00:39:12 GMann_: will get to you in a sec 00:39:20 and I think we can come up with something for that 00:39:31 alaski: yea there is a patch that does multiple create out there now 00:39:33 sure. 00:39:35 (without tasks) 00:39:49 I'm just trying to remember who did it 00:40:08 it may have been melwitt, iirc 00:40:15 yea, that's right. 00:40:18 I need to look that one over again 00:40:36 So I think the one thing it might need is to handle multi status 207 00:40:57 ok 00:41:03 I'll read up on that code 00:41:08 status code 00:41:18 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 nice, that would be ideal 00:42:43 so server_external_events is an example of how we handle a 207 now 00:43:41 cool, I'll check that out 00:44:13 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 and if we change the directory we should do it now before too much gets merged :-) 00:44:52 yes, 00:45:40 ken1ohmichi: what do you think? 00:45:49 GMann_'s idea seems good, 00:53:32 ok anything else people would like to discuss? 00:54:09 thanks everyone for attending! 00:54:21 #endmeeting