12:00:09 #startmeeting nova api 12:00:10 Meeting started Tue Sep 22 12:00:09 2015 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:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:14 The meeting name has been set to 'nova_api' 12:00:19 o/ 12:00:23 Hello, who is here today? 12:00:35 edleafe: you are faster than my question 12:00:41 o/ 12:00:49 always! :) 12:01:07 * alex_xu will use copy/paste next time 12:01:07 o/ 12:01:31 hello everyone, let's start the meeting 12:01:33 #topic actions from last meeting 12:01:41 alex_xu_ and oomichi take a look at https://bugs.launchpad.net/nova/+bug/1495388 more 12:01:43 Launchpad bug 1495388 in OpenStack Compute (nova) "The instance hostname didn't match the RFC 952 and 1123's definition" [Medium,In progress] - Assigned to Eli Qiao (taget-9) 12:01:57 #link https://review.openstack.org/224438 12:02:04 Thanks to eliqiao work on it 12:02:18 I think the patch is close. hope everybody review i 12:03:03 the empty hostname is the only bug we find for hostname 12:03:04 so, I thought on linux the max hostname was 64 characters 12:03:13 dnsmasq doesn't work if you have things longer than that 12:03:56 sdague: oops, I didn't try that. just read rfc, there is relax for that 12:04:06 sdague: I think on windows its even smaller 12:04:16 but yeah, its dnsmasq that is the issue here 12:04:33 alex_xu: yeh, so the dnsmasq thing should be figured out 12:04:39 ok, I will ask eliqiao help to recheck those cases 12:04:55 * bauzas waves late and lurks 12:04:55 also, just truncating the hostname might lead to weird results. If truncation happens there should be a WARN message about it 12:05:14 that has definitely tripped us up at times on the mulitnode job 12:05:31 #action alex_xu eliqiao check max length of hostname on linux and windows again 12:06:26 sdague: ok, that make sense 12:07:00 anyway thanks sdague, will work on that continue 12:07:02 let's move on 12:07:04 gmann_ backport the server name fix 12:07:10 gmann: are you here? 12:07:48 I didnt saw the patch, let me catch gmann or I help on work the patch if I have time 12:08:11 #action alex_xu catch gmann about backport patch or work on it if have enough time 12:08:19 oomichi will take a look at https://review.openstack.org/220791 more to find out more clean way 12:08:25 ok, the hard one 12:08:44 oomichi -1 on this https://review.openstack.org/220791 12:08:51 oops, -2 12:09:01 and oomichi not here :( 12:09:05 so we have a -2 and not replacement patches, which is what I thought we agreed we would not do 12:09:34 is there are better time to catch him, I should come on a few hours early tomorrow if he is around? 12:10:15 johnthetubaguy: maybe, I also can try in the morning, but he isn't on the irc all the time, or we can catch gmann to catch oomichi 12:11:04 ok, so all the people at here have agreement, let's move on 12:11:21 #topic API Bug 12:11:37 emm....we already talk all the bugs...so anyone I missed? 12:11:49 oops, there is one 12:11:51 #topic Removal of v3 naming from source tree 12:12:01 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1462901,n,z 12:12:17 I think just need review, no more problem 12:12:23 so let's move on? 12:12:34 alex_xu: sounds good, I'll look at those reviews shortly 12:12:38 * alex_xu feel we will have short meeting today 12:12:42 sdague: thanks 12:12:48 #topic Reviews 12:12:53 well, I'd like to figure out exactly what we are going to do about https://review.openstack.org/220791 12:12:53 Service Catalog standardization 12:13:26 johnthetubaguy do you want to talk with oomichi before moving forward? or move forward and work with him later? 12:13:31 sdague: I can find out the irc log link for you, then you can know the oomichi's point 12:13:38 because when's the RC point 12:13:44 sdague: I think we should go for both in parallel 12:13:59 sdague: so I pushed out RC until thursday at this point 12:14:01 johnthetubaguy: ok, so alex_xu will colapse the 2 patches into 1 12:14:20 and we'll use the base patch which doesn't have the -2 on it and move it forward? 12:14:20 sdague: ok, no problem 12:14:36 sdague: was thinking the same thing 12:15:10 now, alex_xu if you can reach out to oomichi, that would be good, and I can try catch him while he is around as well 12:15:14 alex_xu: you good with that plan? 12:15:27 johnthetubaguy: yea, will do 12:15:32 sdague: ea, I'm good 12:15:37 s/ea/yea/ 12:15:38 ok, great 12:15:47 so let's move on 12:15:51 #link https://review.openstack.org/#/c/181393/ 12:16:12 ^ I guess this show up in previous meeting...it isn't me adding the link 12:16:45 if no more talk about hat, just please review it 12:16:48 then let's ove on 12:16:57 s/ove/move/ 12:17:13 #topic API Documentation Improvement 12:17:20 #link https://review.openstack.org/#/c/226253 12:17:26 thanks to johnthetubaguy ! 12:17:37 johnthetubaguy: yeh, seriously, thanks for that 12:17:51 do we want to track the todo? 12:17:58 so took a quick look at what we had and added some boiler place 12:18:03 now I am think we merge the TODOs 12:18:09 then have follow on patches to fix them 12:18:19 +1 12:18:51 totally open to alternative ideas mind, that just seems a simple way forward 12:19:29 so please review it! 12:19:41 now there is a bit of repetition between that and the complete reference, but I think we should probably just get links into the complete reference to point back to the concept guide. 12:20:12 johnthetubaguy: the todo model seems good to me 12:20:29 is anyone looking at adding the missing stuff into this doc: http://developer.openstack.org/api-ref-compute-v2.1.html 12:20:46 alex_xu I think you made a good list in an etherpad as a starting point 12:21:02 #link https://bugs.launchpad.net/openstack-api-site/+bug/1488144 12:21:04 Launchpad bug 1488144 in openstack-api-site "Collection of Compute v2.1 API doc bugs" [High,In progress] - Assigned to Atsushi SAKAI (sakaia) 12:21:11 johnthetubaguy: ^ doc team work on it 12:21:20 #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:bug/1488144,n,z 12:21:37 not sure the progress, but as you said, we should help on review 12:23:11 johnthetubaguy: is it ok? 12:23:18 hmm, interesting, I guess we should reach out to those folks 12:23:26 does anyone have contact with them? 12:23:45 emm...no, I think 12:24:15 I can contact him 12:24:32 OK, so I can try reach out to them, via other folks, and see what I can do 12:24:44 johnthetubaguy: thanks 12:24:48 the topic is a great start at least 12:25:07 johnthetubaguy: do you want an action 12:25:21 yes please 12:25:56 #action johnthetubaguy contact the doc team to see what we can help on missing stuff in the doc http://developer.openstack.org/api-ref-compute-v2.1.html 12:26:35 so let's move on 12:26:39 ? 12:27:07 #topic open 12:27:15 #link https://blueprints.launchpad.net/nova/+spec/cloudlet 12:27:34 who own this item? 12:27:54 that seems like it needs a spec for sure 12:27:55 oh, I forget their IRC handle now 12:28:03 I'm not really sure what that is 12:28:06 yeah, I have emailed them about creating a spec 12:28:16 I have a feeling they got some conference talk approved in some track 12:28:18 me too, not veryclear what is 12:28:39 so it turns out, I think its about having VMs follow you around a cell network 12:28:55 using something that sounds a bit like what you do with containers 12:29:26 johnthetubaguy: not sure, it about import vm snapshot, then resume vm...and create snapshot again from the doc... 12:29:34 I am currently a -2 on the spec, if its what I thought it was 12:29:41 yeh, so we should just push them back to writing a spec 12:29:56 yes, please write a spec, is the key part 12:30:15 ok, if I saw the irc, will tell them 12:30:23 I thought I added that on the whiteboard already, adding another comment 12:30:41 at least a link to the cloudlet project 12:30:47 so that we have an idea what it is 12:31:13 ok, so let's move on 12:31:15 #link https://bugs.launchpad.net/nova/+bug/794730 12:31:16 Launchpad bug 794730 in OpenStack Compute (nova) "API doesn't specify what limit=0 means" [Wishlist,Confirmed] - Assigned to Zhenyu Zheng (zhengzhenyu) 12:31:35 Zheny, are you around? 12:31:44 oops, sorry, Zhenyu 12:32:07 limit=0 seems like it should be ignored like it is now, forcing it to be an empty container seems silly 12:32:45 sdague: maybe we should check other project behaviour first, and there better have api-wg guideline about pagination 12:32:47 so there has been a lot of chatter about the images API 12:33:16 and the image api is proxy api, so that should depend on glance's behaviour? 12:33:21 my take is we proxy things from glance v1 right now, so glance v1 is owning the limiting of the results, mostly because it always has 12:33:32 yeah, +1 I think 12:33:49 yeh, and honestly, I think their behavior is wrong 12:33:57 because it's kind of pointless 12:34:05 #link https://review.openstack.org/190743 12:34:07 I don't know of what value that would be 12:34:19 limit=0 should actually be a 400 BadRequest honestly 12:34:20 yeah, thats another issue 12:34:21 there is patch for paginiation guideline, but not finish yet 12:34:32 yeah, it does seem invalid 12:34:49 better to means no limit? 12:34:49 if you want to return none, its a HEAD request not a GET 12:34:54 some like to read "limit=0" as "no limit" 12:34:58 agree that that's wrong 12:35:02 yeah 12:35:49 so we like 400? 12:36:22 it looks like everyone arguing for limit=0 to return an empty container want it to use list as count 12:36:26 fwiw I do agree that the limit=0 should be unlimited like we treat such in any config option as well 12:36:38 https://review.openstack.org/190743 looks like already begin to fight on limits=0 12:37:28 jokke_: that sounds good point, consistent behaviour between configure file and api 12:37:32 I can see the desire for a way of specifying "give me everything", but "limit=0" seems like it's not a good fit 12:38:25 edleafe: "everything" is typically a ddos 12:38:34 services have max_limit set in code for a reason 12:38:37 sdague: heh 12:38:48 sdague: limits=0 should be the max_limit 12:39:05 anyway, that seems like an API WG issue that needs to be pushed forward 12:39:07 "give me the max" 12:39:21 yea 12:39:29 edleafe: don't specify limit then 12:39:38 so if you have opinion please continue the discussion on https://review.openstack.org/#/c/190743 12:39:41 it's not a required parameter 12:39:50 sdague: good point 12:40:16 not specifying limit means "up to the max allowed". 12:40:37 that seems the most sensible approach to me 12:40:43 but I guess others want "give me everything, even if it's more than max allowed." 12:41:06 agree that that's a ddos scenario 12:41:24 yeah, that should not be an option 12:42:26 anyway there is no result at here. so anything more want to talk about, or we close meeting early, back to coding? 12:42:56 3... 12:43:09 12:43:12 2.. 12:43:23 1. 12:43:28 so thanks all! 12:43:40 #endmeeting