00:00:48 #startmeeting nova-api 00:00:49 Meeting started Fri Oct 10 00:00:48 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:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:53 The meeting name has been set to 'nova_api' 00:01:09 Hi - who's here today for the nova api meeting? 00:01:12 hi 00:02:00 hi 00:02:48 gmann: do you know if oomichi is going to be able to make it today? 00:03:29 cyeoh: He is busy in other meeting, so he might not be able to join 00:04:01 ok, np. lets get started then 00:04:14 #topic v2.1 on v3 00:04:34 as everyone has probably seen by now we've got the v2.1 on v3 spec re-approved for kilo :-) 00:04:56 yea 00:05:22 so anything on #link https://etherpad.openstack.org/p/v2_1_WorkList we can work on 00:05:22 approved so quick 00:05:26 hi there, sorry I'm late :) 00:05:40 yea we were first :-) 00:05:43 r1chardj0n3s: np 00:06:12 I'd recommend people rebase any existing patch older than a couple of weeks 00:06:16 some context: I'm working on a new pure-Javascript client for OpenStack APIs 00:06:51 currently I'm targetting v2 because that's what's in devstack 00:06:59 writing a client from scratch has exposed some fun issues with the APIs and their documentation 00:07:08 and if the patch copies any of the v2 files just to recheck that no patches were applied to the original during the feature freeze 00:07:29 so I was wondering what advice I might receive, what help I might offer that would be useful? 00:07:34 cyeoh: yes 00:07:47 as there were quite a log of bug fixes then went into the nova api during ff 00:07:47 one other update to patches is that we no longer need to do the url_prefix work for v2 vs v3 urls 00:07:59 so they can be removed from patches. Kenichi's wsgi_app_v21 patch has merged so we can just use the common url 00:08:52 also, I have written https://review.openstack.org/#/c/120964/14 which I'd like to see included in various APIs, so comments on it earlier rather than later would be appreciated :) 00:09:06 cyeoh: for wsgi_app_v21, shall we start cleanup the existing one also. 00:09:22 (the CORS stuff is far from just my baby, too, I'm just the sucker writing the spec/code) 00:11:20 I also wanted to find out what people thought about eventually just removing the content of HTTPBlankRequest calls for cases where we call the controller directly 00:11:21 rather than wsgi_app 00:11:23 when we call the controller directly the url never actually gets used (except perhaps is it does parameter parsing which very few methods doo) 00:11:25 the url string never gets parsed/checked in anyway so tests will pass even if its garbage. 00:11:28 I wonder if in those cases we should use an empty string instead? 00:12:05 sorry I'm having a few network disconnects. 00:12:55 r1chardj0n3s: certainly submit bug reports on any issues you find http://bugs.launchpad.net/nova - tag them with api would be useful 00:13:24 cyeoh: ok, so bug reports against v2 would be accepted? 00:13:40 r1chardj0n3s: yes definitely, they may well be in the v2.1 api as well 00:13:41 cyeoh: it's almost always more about the documentation, to be honest 00:14:36 r1chardj0n3s: yep we're trying to move to a model where we automate generation of documentation eventually which should fix some of those issues but for now a bug would be very useful 00:14:42 cyeoh, what is HTTPBlankRequest? I don't know it, is there any related patch? 00:14:45 cyeoh: ok 00:14:45 hi all :) 00:14:54 eliqiao1, hi :) 00:15:17 cyeoh: I agree we can remove the url string as of now. but i feel we need consistency across UT 00:15:21 gmann: so for cases where we create a fake request and pass it to the controller the url is ignored, but if we pass it to wsgi_app_v21 we do need a valid url 00:15:41 gmann: yea to be honest I'm not sure about the change, I just wanted to bring it up for discussion 00:16:03 gmann: because its not checked there are cases where its just plain wrong which can be misleading. But maybe we just live with that? 00:16:38 alex_xu: oh so I mean HTTPRequest.blank('/v2/....') 00:17:28 r1chardj0n3s: can get to you review in a sec if you want (to be honest I don't know anything about CORS) 00:18:07 cyeoh, alex_xu: I am +1 to remove those which are present in many test class. 00:18:15 cyeoh, I remember we said we prefer test controller directly than wsg_app_v21 before, because we don't want to run whole stack in unittest, and we already have api sample test 00:18:30 cyeoh: https://review.openstack.org/#/c/119485/ is the spec, which may help :) 00:18:58 alex_xu: yea I think where we can its preferable as its much closer to a unit test (as long as we have good api sample test coverage) 00:19:19 cyeoh: though the spec needs to be updated for some of the configuration minutae 00:19:44 alex_xu: yes, i am litle bit not comfortable about having mixed way of call, some with wsgi some directly controller... 00:19:45 gmann, alex_xu: so perhaps one of the cleanup things we put on the todo list for kilo is converting wsgi_api based tests to direct controller tests 00:20:10 #link https://etherpad.openstack.org/p/Nova_API_Kilo_Planning 00:20:17 the controller tests also run a lot of faster. 00:20:42 cyeoh, yes, but should be low priority 00:20:53 alex_xu, yep sure 00:21:17 cyeoh: nice idea :) 00:21:30 so we are planing to refactor the wsgi_api test to direct controller tests? 00:21:54 eliqiao1, yea 00:22:23 alex_xu: got it, thx. 00:23:16 #topic CORS 00:23:53 r1chardj0n3s: did you want to say anything else about CORS? 00:24:09 r1chardj0n3s: I'll admit this all new to me :-) 00:24:31 thanks, apart from what's in the spec, probably not 00:24:35 though some history, perhaps 00:24:53 originally CORS was going to be implemented in an existing middleware, but that approach was nixed 00:25:30 the next thought was to punt the integration of it off on deployers who wanted it, but that ended up being a bit of a nightmare for deployers (who would need to know way too much about the API in question to get it right) 00:26:00 so the current apprach is to try to get the APIs themselves to include the middleware by default, though with a configuration that basically says "no, we don't allow CORS" 00:26:16 deployers may then make a relatively trivial edit to the paste configuration to allow CORS if they wish to 00:26:37 but that relies on buy-in from folk like yourself :) 00:26:47 ok so excuse my ignorance, but its basically just adding and accepting some new headers? 00:26:55 yes 00:27:27 ok that sounds fairly harmless :-) 00:27:34 yep 00:28:01 I will also note though, that my main day work at the moment is to rewrite Horizon as a pure Javascript application 00:28:21 Ah ok I see 00:28:46 and for that, I've avoided the CORS issue completely by using a super-thin API proxy that presents all the OpenStack service APIs through a single origin (in the CORS sense of "origin") 00:28:49 is it just your org who is interested in CORS support or are there others as well? 00:29:05 no, there seems to be broad interest in enabling CORS 00:29:39 but as I mention, ironically I probably won't use it, even though others will 00:29:49 heh :-) 00:30:23 ok I guess it'd be nice to get people from various orgs to comment on the spec so we know there is user demand for it. 00:30:38 seems reasonable 00:30:48 anyway my first impression of it seems like it should be ok - fairly harmless and disabled by default 00:31:02 (I'm kinda new at OpenStack - only 3.5 months in now - so I'm unsure how to progress things like that) 00:31:34 r1chardj0n3s: I think it's probably a good idea to post a reference to it to openstack-dev if you haven't already done so 00:31:42 ok, will do 00:31:52 under [all]? 00:32:00 yep 00:32:44 ok, moving on... 00:32:50 #topic microversions 00:33:03 (thanks, cyeoh) 00:33:19 I've put up another version of the microversions spec. Please review/comment: 00:33:30 #link https://review.openstack.org/#/c/127127/ 00:33:39 r1chardj0n3s: np 00:34:02 oomchi and I have been discussing JSON-HOME on that spec as well 00:34:35 if anyone wants to write up a JSON-HOME spec too I think that'd be useful (I don't know yet if it would fit into kilo yet - I think its non trivial to implement) 00:35:36 any comments on the microversions? I hope to have some sample code by next week 00:36:00 cyeoh, JSON-HOME should begin after we implement micro-version? 00:36:39 alex_xu: so I might be wrong, but the way I see it, microversions allows us to give client control to what API they say (by passing a version) 00:36:40 cyeoh, looks like implement JSON-HOME need depend on how we implement micro-version 00:36:56 alex_xu: whereas JSON-home allows us to describe what that API looks like 00:37:19 I think it'd be possible to do a JSON-home document for the v2 api - since it's essentially static 00:37:40 which may be a good testcase (still needs to handle what plugins are actually loaded though) 00:37:43 Json-home also describe each version api..so I think it may a little dependence 00:38:16 alex_xu: I think if we go that route the json home document is going to *very* complicated 00:38:53 because I think we should plan on lots of minor version updates during each cycle, plus a few major ones 00:39:18 agree 00:39:44 I was thinking (and perhaps this is just all wrong) that we could make the json-home document dependent on the client header for microversions 00:40:21 so it would be simple as it would only have to describe the api for a single snapshot of the API at a time, rather than its whole history 00:41:05 you mean only newest version or all the version in one json-home? 00:41:42 so I was thinking if the client header said v2 api, then the json home document would just describe the API as it behaves in v2 mode 00:41:59 if they say version=4.12.3 then the JSON home document would describe that 00:42:27 With all the plugins that we have the size of the API is huge and that already makes for a very large document 00:43:42 I guess we could have a json home document that also describes all the functionality for all the versions. But it would end up very large :-) And I doubt clients would want to be continuously pulling that down 00:44:07 cyeoh: JSON home document needed for mainly backward incompatibility version or for compatibility also 00:44:15 emm...yes, I can image it' very large :) 00:45:05 gmann: yea I'm not sure if I'm missing something with my understanding of json home documents 00:45:25 gmann: but I'm wondering why its needed for backwards incompatibility? 00:47:26 cyeoh: it should describe for all interface changes right? which include backwards incompatibility also 00:47:55 gmann: so we could use it to do that, though as I mentioned before I think that would mean it would get huge. 00:48:11 gmann: or we could just use it to describe the API at a specific version 00:48:23 I'm trying to think of how a client would use it. 00:48:52 I think most clients will just be written up against a specific version of the API and they won't look at the JSON home document 00:49:17 A sophisticated client might want to always work against the latest version of the API 00:49:43 in which case they would use the json home document to find out what is available 00:49:57 but wouldn't care about the api history 00:50:35 cyeoh, it should care which version avaliable 00:50:42 maybe a really fancy client would be able to operate against any version of the api in which case they would really want all this information from json home 00:51:04 cyeoh: yes. but sometime moving from version to version they required for all version 00:51:31 alex_xu: yes, that's true but that can just be done with a version list, or the standard /versions output 00:51:58 cyeoh, yea, right 00:52:29 so I guess what I'm saying is that if the client can dynamically adapt to a changing api by parsing json home then why would it ever want to use anything but the latest version of the api? 00:53:19 if it can't then its probably fixed to a specific version anyway 00:53:37 gmann: I don't think I understood what you were saying 00:55:04 cyeoh: i mean the same if some client care about all API version and we need to provide JSON Home for those 00:56:32 gmann: oh I see, yes I agree 00:57:28 gmann: well I think this discussion has helped my understanding quite a bit anyway ;-) 00:57:44 thx! Is there anything else people want to talk about re: json/home or microversions? 00:58:15 nothing from me, need review the spec first! 00:58:32 ok :-) Otherwise we're pretty much out of time 00:58:40 #topic open discussion 00:58:49 cyeoh: nothing from my side, i will also review spec 00:58:51 anything else from anyone for the 1 minute we have left? :-) 00:58:57 quick question 00:59:05 sure 00:59:12 Should I add policy stuff at here https://etherpad.openstack.org/p/kilo-nova-priorities 00:59:23 or that link just for very important feature 00:59:42 or every feature should add to that etherpad 01:00:08 alex_xu: I think its worth adding, but describe how it makes life easier for deployers 01:00:19 cyeoh, ok, I got it 01:00:24 cyeoh: I re spin tempest spec for Nova v2.1 - https://review.openstack.org/#/c/96661/ 01:00:42 cyeoh: please have look at convenient time 01:00:43 gmann: thx! I'll have a look at it 01:00:48 thx 01:00:57 ok we're definitely out of time. thx everyone 01:00:59 #endmeeting