00:00:48 <cyeoh> #startmeeting nova-api 00:00:49 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:53 <openstack> The meeting name has been set to 'nova_api' 00:01:09 <cyeoh> Hi - who's here today for the nova api meeting? 00:01:12 <alex_xu> hi 00:02:00 <gmann> hi 00:02:48 <cyeoh> gmann: do you know if oomichi is going to be able to make it today? 00:03:29 <gmann> cyeoh: He is busy in other meeting, so he might not be able to join 00:04:01 <cyeoh> ok, np. lets get started then 00:04:14 <cyeoh> #topic v2.1 on v3 00:04:34 <cyeoh> as everyone has probably seen by now we've got the v2.1 on v3 spec re-approved for kilo :-) 00:04:56 <alex_xu> yea 00:05:22 <cyeoh> so anything on #link https://etherpad.openstack.org/p/v2_1_WorkList we can work on 00:05:22 <alex_xu> approved so quick 00:05:26 <r1chardj0n3s> hi there, sorry I'm late :) 00:05:40 <cyeoh> yea we were first :-) 00:05:43 <cyeoh> r1chardj0n3s: np 00:06:12 <cyeoh> I'd recommend people rebase any existing patch older than a couple of weeks 00:06:16 <r1chardj0n3s> some context: I'm working on a new pure-Javascript client for OpenStack APIs 00:06:51 <r1chardj0n3s> currently I'm targetting v2 because that's what's in devstack 00:06:59 <r1chardj0n3s> writing a client from scratch has exposed some fun issues with the APIs and their documentation 00:07:08 <cyeoh> 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 <r1chardj0n3s> so I was wondering what advice I might receive, what help I might offer that would be useful? 00:07:34 <gmann> cyeoh: yes 00:07:47 <cyeoh> as there were quite a log of bug fixes then went into the nova api during ff 00:07:47 <cyeoh> 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 <cyeoh> 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 <r1chardj0n3s> 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 <gmann> cyeoh: for wsgi_app_v21, shall we start cleanup the existing one also. 00:09:22 <r1chardj0n3s> (the CORS stuff is far from just my baby, too, I'm just the sucker writing the spec/code) 00:11:20 <cyeoh> 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 <cyeoh> rather than wsgi_app 00:11:23 <cyeoh> 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 <cyeoh> the url string never gets parsed/checked in anyway so tests will pass even if its garbage. 00:11:28 <cyeoh> I wonder if in those cases we should use an empty string instead? 00:12:05 <cyeoh> sorry I'm having a few network disconnects. 00:12:55 <cyeoh> 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 <r1chardj0n3s> cyeoh: ok, so bug reports against v2 would be accepted? 00:13:40 <cyeoh> r1chardj0n3s: yes definitely, they may well be in the v2.1 api as well 00:13:41 <r1chardj0n3s> cyeoh: it's almost always more about the documentation, to be honest 00:14:36 <cyeoh> 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 <alex_xu> cyeoh, what is HTTPBlankRequest? I don't know it, is there any related patch? 00:14:45 <r1chardj0n3s> cyeoh: ok 00:14:45 <eliqiao1> hi all :) 00:14:54 <alex_xu> eliqiao1, hi :) 00:15:17 <gmann> cyeoh: I agree we can remove the url string as of now. but i feel we need consistency across UT 00:15:21 <cyeoh> 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 <cyeoh> gmann: yea to be honest I'm not sure about the change, I just wanted to bring it up for discussion 00:16:03 <cyeoh> 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 <cyeoh> alex_xu: oh so I mean HTTPRequest.blank('/v2/....') 00:17:28 <cyeoh> 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 <gmann> cyeoh, alex_xu: I am +1 to remove those which are present in many test class. 00:18:15 <alex_xu> 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 <r1chardj0n3s> cyeoh: https://review.openstack.org/#/c/119485/ is the spec, which may help :) 00:18:58 <cyeoh> 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 <r1chardj0n3s> cyeoh: though the spec needs to be updated for some of the configuration minutae 00:19:44 <gmann> alex_xu: yes, i am litle bit not comfortable about having mixed way of call, some with wsgi some directly controller... 00:19:45 <cyeoh> 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 <cyeoh> #link https://etherpad.openstack.org/p/Nova_API_Kilo_Planning 00:20:17 <cyeoh> the controller tests also run a lot of faster. 00:20:42 <alex_xu> cyeoh, yes, but should be low priority 00:20:53 <cyeoh> alex_xu, yep sure 00:21:17 <gmann> cyeoh: nice idea :) 00:21:30 <eliqiao1> so we are planing to refactor the wsgi_api test to direct controller tests? 00:21:54 <alex_xu> eliqiao1, yea 00:22:23 <eliqiao1> alex_xu: got it, thx. 00:23:16 <cyeoh> #topic CORS 00:23:53 <cyeoh> r1chardj0n3s: did you want to say anything else about CORS? 00:24:09 <cyeoh> r1chardj0n3s: I'll admit this all new to me :-) 00:24:31 <r1chardj0n3s> thanks, apart from what's in the spec, probably not 00:24:35 <r1chardj0n3s> though some history, perhaps 00:24:53 <r1chardj0n3s> originally CORS was going to be implemented in an existing middleware, but that approach was nixed 00:25:30 <r1chardj0n3s> 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 <r1chardj0n3s> 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 <r1chardj0n3s> deployers may then make a relatively trivial edit to the paste configuration to allow CORS if they wish to 00:26:37 <r1chardj0n3s> but that relies on buy-in from folk like yourself :) 00:26:47 <cyeoh> ok so excuse my ignorance, but its basically just adding and accepting some new headers? 00:26:55 <r1chardj0n3s> yes 00:27:27 <cyeoh> ok that sounds fairly harmless :-) 00:27:34 <r1chardj0n3s> yep 00:28:01 <r1chardj0n3s> 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 <cyeoh> Ah ok I see 00:28:46 <r1chardj0n3s> 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 <cyeoh> is it just your org who is interested in CORS support or are there others as well? 00:29:05 <r1chardj0n3s> no, there seems to be broad interest in enabling CORS 00:29:39 <r1chardj0n3s> but as I mention, ironically I probably won't use it, even though others will 00:29:49 <cyeoh> heh :-) 00:30:23 <cyeoh> 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 <r1chardj0n3s> seems reasonable 00:30:48 <cyeoh> anyway my first impression of it seems like it should be ok - fairly harmless and disabled by default 00:31:02 <r1chardj0n3s> (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 <cyeoh> 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 <r1chardj0n3s> ok, will do 00:31:52 <r1chardj0n3s> under [all]? 00:32:00 <cyeoh> yep 00:32:44 <cyeoh> ok, moving on... 00:32:50 <cyeoh> #topic microversions 00:33:03 <r1chardj0n3s> (thanks, cyeoh) 00:33:19 <cyeoh> I've put up another version of the microversions spec. Please review/comment: 00:33:30 <cyeoh> #link https://review.openstack.org/#/c/127127/ 00:33:39 <cyeoh> r1chardj0n3s: np 00:34:02 <cyeoh> oomchi and I have been discussing JSON-HOME on that spec as well 00:34:35 <cyeoh> 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 <cyeoh> any comments on the microversions? I hope to have some sample code by next week 00:36:00 <alex_xu> cyeoh, JSON-HOME should begin after we implement micro-version? 00:36:39 <cyeoh> 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 <alex_xu> cyeoh, looks like implement JSON-HOME need depend on how we implement micro-version 00:36:56 <cyeoh> alex_xu: whereas JSON-home allows us to describe what that API looks like 00:37:19 <cyeoh> I think it'd be possible to do a JSON-home document for the v2 api - since it's essentially static 00:37:40 <cyeoh> which may be a good testcase (still needs to handle what plugins are actually loaded though) 00:37:43 <alex_xu> Json-home also describe each version api..so I think it may a little dependence 00:38:16 <cyeoh> alex_xu: I think if we go that route the json home document is going to *very* complicated 00:38:53 <cyeoh> because I think we should plan on lots of minor version updates during each cycle, plus a few major ones 00:39:18 <alex_xu> agree 00:39:44 <cyeoh> 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 <cyeoh> 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 <alex_xu> you mean only newest version or all the version in one json-home? 00:41:42 <cyeoh> 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 <cyeoh> if they say version=4.12.3 then the JSON home document would describe that 00:42:27 <cyeoh> 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 <cyeoh> 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 <gmann> cyeoh: JSON home document needed for mainly backward incompatibility version or for compatibility also 00:44:15 <alex_xu> emm...yes, I can image it' very large :) 00:45:05 <cyeoh> gmann: yea I'm not sure if I'm missing something with my understanding of json home documents 00:45:25 <cyeoh> gmann: but I'm wondering why its needed for backwards incompatibility? 00:47:26 <gmann> cyeoh: it should describe for all interface changes right? which include backwards incompatibility also 00:47:55 <cyeoh> 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 <cyeoh> gmann: or we could just use it to describe the API at a specific version 00:48:23 <cyeoh> I'm trying to think of how a client would use it. 00:48:52 <cyeoh> 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 <cyeoh> A sophisticated client might want to always work against the latest version of the API 00:49:43 <cyeoh> in which case they would use the json home document to find out what is available 00:49:57 <cyeoh> but wouldn't care about the api history 00:50:35 <alex_xu> cyeoh, it should care which version avaliable 00:50:42 <cyeoh> 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 <gmann> cyeoh: yes. but sometime moving from version to version they required for all version 00:51:31 <cyeoh> alex_xu: yes, that's true but that can just be done with a version list, or the standard /versions output 00:51:58 <alex_xu> cyeoh, yea, right 00:52:29 <cyeoh> 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 <cyeoh> if it can't then its probably fixed to a specific version anyway 00:53:37 <cyeoh> gmann: I don't think I understood what you were saying 00:55:04 <gmann> 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 <cyeoh> gmann: oh I see, yes I agree 00:57:28 <cyeoh> gmann: well I think this discussion has helped my understanding quite a bit anyway ;-) 00:57:44 <cyeoh> thx! Is there anything else people want to talk about re: json/home or microversions? 00:58:15 <alex_xu> nothing from me, need review the spec first! 00:58:32 <cyeoh> ok :-) Otherwise we're pretty much out of time 00:58:40 <cyeoh> #topic open discussion 00:58:49 <gmann> cyeoh: nothing from my side, i will also review spec 00:58:51 <cyeoh> anything else from anyone for the 1 minute we have left? :-) 00:58:57 <alex_xu> quick question 00:59:05 <cyeoh> sure 00:59:12 <alex_xu> Should I add policy stuff at here https://etherpad.openstack.org/p/kilo-nova-priorities 00:59:23 <alex_xu> or that link just for very important feature 00:59:42 <alex_xu> or every feature should add to that etherpad 01:00:08 <cyeoh> alex_xu: I think its worth adding, but describe how it makes life easier for deployers 01:00:19 <alex_xu> cyeoh, ok, I got it 01:00:24 <gmann> cyeoh: I re spin tempest spec for Nova v2.1 - https://review.openstack.org/#/c/96661/ 01:00:42 <gmann> cyeoh: please have look at convenient time 01:00:43 <cyeoh> gmann: thx! I'll have a look at it 01:00:48 <gmann> thx 01:00:57 <cyeoh> ok we're definitely out of time. thx everyone 01:00:59 <cyeoh> #endmeeting