12:00:07 #startmeeting nova api 12:00:08 Meeting started Tue Jan 19 12:00:07 2016 UTC and is due to finish in 60 minutes. The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:12 The meeting name has been set to 'nova_api' 12:00:18 who is here today? 12:00:21 o/ 12:00:24 hi 12:00:53 jichen: Kevin_Zheng hello 12:01:13 let's wait one more minute for more people join 12:01:20 sure 12:01:37 hi 12:01:52 o/ 12:02:27 ok, cool, looks like have enough people now, let's start the meeting 12:02:34 #topic content patches up for review 12:02:42 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/complete-todo-in-api-concept-doc,n,z 12:02:57 looks good, just need more review 12:03:21 I added one more about extension 12:03:35 #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:fix-compute-api-ref,n,z 12:03:51 we have a lot of api ref fix merged last week, that thanks to jichen :) 12:04:09 alex_xu: :) 12:04:24 o/ 12:04:27 jichen: from your view, do we still have a lot of bugs in the doc? 12:04:30 nice, thanks jichen. 12:05:05 alex_xu: I guess so, we might need more work on the wording and some consistency between code and doc 12:05:17 jichen: ok, thanks 12:05:25 np 12:05:26 #link https://etherpad.openstack.org/p/nova-v2.1-api-doc 12:05:45 from this etherpad looks like still have note didn't address yet for api ref 12:06:02 #topic most needed next content patches 12:06:27 for api concept, just left few concept in servers. 12:06:58 hope we can at least have some initial doc for those 12:07:21 if no more question, let's move on 12:07:40 #topic remove project id 12:07:54 sdague: looks like we have agreement on the solution last week 12:08:15 #link https://review.openstack.org/233076 12:08:22 yes, I responded to your review comments just now 12:08:34 sdague: ^ this is ready to merge, right? I already begin to review it 12:08:54 well, I have to rebase because another v2.16 merged 12:09:01 * gmann_ will review it tomorrow 12:09:14 so it will be v2.17, it will take me a bit 12:09:35 sdague: should i hold all extension patches? not sure those will lead to conflict with this. need t check 12:10:01 #link https://review.openstack.org/#/q/topic:bp/api-sample-tests-with-all-extensions 12:10:08 on https://review.openstack.org/#/c/233076/21 I added review comments 12:10:38 gmann_: it would be nice if we could get this landed because we generate a bunch of additional comments 12:10:48 sorry, conflict 12:10:52 just waking up still :) 12:11:05 sdague: yea, sure. no issue. 12:11:25 sdague: ok I got it 12:12:14 I missed that point 12:12:45 sdague: alex_xu quick question (still need to look into patch) 12:12:59 we will not generate api samples for without project_id? 12:13:09 gmann_: no, not yet 12:13:38 auggy is working on some unit testing for the matcher in api_samples 12:13:51 sdague: ok. i see 12:14:04 once she completes that, we can refactor that so we can have 1 template set, and 2 samples trees 12:14:14 but there is so much magic in there, I didn't want to change it without tests 12:14:26 sdague: yea. 12:14:57 sdague: do we still think about legacy v2 problem? 12:15:06 sdague: lot of magic logic will go away with all extension. and it will be more clear to refactor tests 12:15:16 alex_xu: which problem is this? 12:16:00 sdague: the project_id will optional for legacy v2 compatible mode also 12:16:19 alex_xu: yes, that's true 12:16:33 there are only so many things we can do with route changes like this 12:16:51 the microversion here is really a signal for new allowed behavior 12:17:34 anyway with project_id still work with legacy v2 mode 12:17:39 right 12:17:51 ok, it isn't a big problem 12:18:28 ok, so we are good at here, any more question on this? 12:18:43 so we just need help on another around review 12:19:09 +1 12:19:17 cool, let's move on 12:19:24 #topic API futures - patches for approved specs 12:19:34 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-sample-tests-with-all-extensions 12:19:42 thanks gmann_ work on this 12:20:01 alex_xu: yea it was on hold for long time. 12:20:11 I think we should metion this work on the meeting, otherwise I afraid we always forget to help on review those patches 12:20:21 yea 12:20:43 so hope people help on review! 12:20:54 i will try to push more on this tomorrow but will check project_id patch should not conflict with this 12:21:02 +1 12:21:07 gmann_: thanks 12:21:28 looking at first glance it should not but will confirm and update accordingly 12:21:31 alex_xu: np 12:21:42 I'm just thinking we should show all the fields in the sample file. that will be more useful in the api-ref 12:22:07 but that may can be done separately 12:22:27 alex_xu: +1, once we get rid of extensions specific tests, i will go through all with schema files and add if anything mising 12:22:36 gmann_: thanks a lot 12:22:54 ok, so next one 12:22:58 #link https://review.openstack.org/#/c/254950/ 12:23:05 I have question for this patch. I found rebuild action allow to change the instance name, if the name changed, the meaning of description may changed also. So I think user should have requirement update description when rebuild instance also. 12:23:06 alex_xu: i found some tests missing there for 2.3 12:23:24 only doc sample files are there but no template and tests. ll add that too 12:23:25 gmann_: emm...interesting 12:23:35 gmann_: thanks again :) 12:23:38 alex_xu: np 12:23:48 alex_xu: is name change mandatory? 12:24:14 * alex_xu is checking 12:24:43 sdague: no, it's not 12:24:47 optional 12:25:07 sdague: i think no, that is optional same as update API 12:25:09 yea 12:25:17 so description being optional is probably fine 12:25:17 only image is mandatory 12:25:41 ok, probably need update spec also 12:25:53 but that will be quickly, hope it still can catch up the freeze 12:26:03 sdague: alex_xu related to this, i feel update should show only updated field in response 12:26:33 update response is kinda replica of show server and keep adding more and more attribute with show API changes 12:26:33 gmann_: currently it isn't only show updated field? 12:26:43 alex_xu: no it shows all the filed 12:27:05 I'm not, but I think that should be another propose 12:27:22 s/I'm not/I'm not sure/ 12:27:23 alex_xu: yea another not in this 12:27:44 gmann_: why do you only want to show updated fields? 12:28:03 the point of UPDATE is that you update some number of things, and you get a whole resource back 12:28:11 alex_xu: with rebuild addition spec for that patch should add about adding the description field in update Response also 12:28:28 gmann_: ok, got it 12:28:34 sdague: but with that it will be more clear what all being updated. 12:29:11 sdague: show resource should be showing all the info 12:29:37 i feel that but may be m missing any such use case of update 12:30:08 is there any chance one field updated may lead to other field changed also? but for now, I guess we don't have this case. 12:30:13 gmann_: the idea is we are working with a server representation 12:30:31 that could be passed around 12:31:18 I guess I don't understand what use you would have with partial resource returns 12:31:52 sdague: but in current case also update API does show all info as Show does 12:32:05 some attribute is in Show only 12:32:33 before I hope we have some return for show and update 12:33:13 I guess we should fix that in the future? 12:33:17 like https://github.com/openstack/tempest-lib/blob/master/tempest_lib/api_schema/response/compute/v2_1/servers.py#L159-L178 12:33:37 i feel either we should show all or only updated one 12:33:55 right, I think we should be returning everything, or nothing honestly. 12:34:28 sdague: yea 12:34:53 +1 12:35:16 let find some point to fix that in the future 12:35:27 alex_xu: yea +1 12:35:40 gmann_: it would probably be good to write up the issue, maybe as a spec, and where it shows up 12:35:54 sdague: +1 12:35:59 sdague: sure, will add spec 12:36:27 so let's move to next one 12:36:31 #link https://review.openstack.org/#/c/128940/106 12:36:44 For this patch, I just think we should give some help. As it already have 106 patchsets.... 12:37:01 API layer patch looks like pretty closes 12:38:05 anyway people free to help review it 12:38:29 OK 12:38:30 alex_xu: is author active or need help on implementation ? 12:38:46 alex_xu: i can help if needed 12:38:55 gmann_: author is active, implementation looks good 12:39:12 alex_xu: ok, will review then. Thanks 12:39:23 in my memory, this patch already been here 2 or 3 release. I guess due to wait too long time, people begin to forget it.... 12:39:29 gmann_: thanks 12:40:04 good to see we have a helpful team 12:40:17 #topic open 12:40:18 any open today? 12:40:23 yes 12:40:34 Kevin_Zheng: please go ahead 12:40:47 I have a question like this 12:40:56 I have a microversion 12:40:59 say 2.18 12:41:14 it added vm_state and task_state 12:42:07 John and Sean suggested that we shouldn't let list and show API in lower microversion to show those states 12:42:39 but to doing this, I may have to add microversion for list and show API also? 12:42:54 yes, I guess so 12:43:13 also in 2.18? 12:43:24 Kevin_Zheng: yes, this should all be in the same bump 12:43:28 i think we have those in show API right 12:43:40 hm... 12:43:50 basically when < 2.18 those values should show up to something that could exist earlier 12:44:01 OK then 12:44:11 I will work on that 12:44:41 cool~ 12:44:42 alex_xu: https://review.openstack.org/233076 is rebased now, if you could take a look before you stop your day it would be appreciated. 12:44:56 sdague: yea, I will check after the meeting 12:45:01 hi , thanks for talking https://review.openstack.org/#/c/257261/ , last week ;we had a discussion, as follow up, I can't find use case for mac address, but I think the 'ip' type should be something helpful to user? 12:46:37 is there any other way to get the type? for neutron, I guess probably user need check the network type 12:47:44 jichen: maybe we can update the usecase in the spec, then let people feedback on the spec? 12:48:11 um.. I can do that, let me update the spec and invite folks to take a look 12:48:25 jichen: cool, thanks 12:48:34 thanks 12:48:50 if no more open, I will close the meeting early 12:49:13 3... 12:49:17 2.. 12:49:19 1. 12:49:24 thanks all! 12:49:31 Thanks all 12:49:32 #endmeeting