12:00:18 #startmeeting nova api 12:00:18 Meeting started Tue Sep 15 12:00:18 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:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:00:22 The meeting name has been set to 'nova_api' 12:00:31 who is here today? 12:00:31 o/ 12:01:10 hi 12:01:28 hello johnthetubaguy oomichi 12:01:47 alex_xu_: Nihao 12:01:50 waiting one more minutes if more people join in 12:01:55 oomichi: Nihao :) 12:02:02 hi 12:02:16 gmann_: hi 12:02:28 ok, let's get start the meeting 12:02:34 #topic actions from last meeting 12:02:39 alex_xu open a bug for fix the hostname 12:02:47 I created one 12:02:48 #link https://bugs.launchpad.net/nova/+bug/1495388 12:02:49 Launchpad bug 1495388 in OpenStack Compute (nova) "The instance hostname didn't match the RFC 952 and 1123's definition" [Undecided,Incomplete] 12:02:59 looks like already get some feedback 12:03:23 is there anyone interesting work in more detail on this? 12:03:57 interested in seeing it fixed, but other than that, worth answering the questions on there I guess 12:04:08 maybe link to the IRC meeting 12:04:16 yea 12:04:40 yea that will be nice 12:04:54 at least I think this isn't release block bug, right? 12:05:29 alex_xu_: the corresponding schema was changed 2 week ago, right? 12:05:45 yeah, I don't think it blocks the release 12:05:48 oomichi: yes, maybe one week 12:05:53 although still would like it fixed 12:05:55 oomichi: the server name 12:06:17 alex_xu_: if so, how about reverting the patch and re-doing it only for v2.0? 12:06:23 as one option 12:06:43 oomichi: the server name fixed didn't effect this bug 12:07:22 really? I am misunderstanding something 12:07:53 alex_xu_: I guess the schema contains hostname definition as a server name. 12:07:54 so we let spaces in for v2.1 compat 12:08:00 oomichi: yes, the server name fixing just enable some spaces in the middle, those spaces will strip in the hostname 12:08:13 that kinda re-creates the bug we always had with v2.0 12:08:22 so its not really a regression as such 12:08:36 more an un-fixed thing 12:09:00 the rfc doesn't allow spaces in the middle, right? 12:09:22 yea, rfc does not allow 12:09:46 but hostname going to strip those 12:09:52 right, its not allowed in a hostname 12:09:58 but its totally fine in a display name 12:10:01 oomichi: this https://github.com/openstack/nova/blob/master/nova/utils.py#L774 will strip out that 12:10:06 we happen to mess that up and it does both 12:10:13 so with server name fix, we didn't change anything about hostname 12:10:31 yeah 12:10:49 but actually, some projects are using it wrongly, so current implementation is fine for me. 12:10:51 its not clean, but we are restoring what happens with v2.0, as we have to 12:11:28 nova-network adds the name into DHCP, for flat DHCP, if I remember correctly 12:11:30 alex_xu_: johnthetubaguy :that hostname is being used for each server in DNS entry etc right? 12:11:46 it does some clean up, but not enough 12:11:52 that bug is saying, go fix the rest 12:12:08 gmann_: yea 12:13:05 gmann_: yeah, that was the reason why we used the hostname definition for server name 12:13:20 oomichi: yea. 12:13:24 oomichi: but the spaces in the name is used by actually user 12:13:33 alex_xu_: yeah, nice point. 12:13:51 oomichi: so the user code was broken by that 12:13:53 as other resource display name 12:14:08 alex_xu_: I was surprised that happened in openstack projects. but the existing users are doing it. 12:14:27 oomichi: yea 12:14:35 so let us fix the hostname 12:14:38 in that bug 12:15:01 gmann_: can we separate these names on API call ? 12:15:17 the ship has sailed here, v2.0 does what it does 12:15:29 oomichi: yea but in that case we need to take both as separate input from user 12:15:36 we can consider better APIs for later microversions, but I think we should move on 12:15:50 +1 12:16:01 johnthetubaguy: +1 and -1 12:16:34 may be excepting hostname from user along with display name but that should bein mocroversion 12:16:40 johnthetubaguy: at this time, it is hard to decide it but it did break our microversions contract. 12:17:06 oomichi: yea that is my worry also :( 12:17:14 johnthetubaguy: if reverting it back and doing it only for v2.0, we can revert the contract also 12:17:39 johnthetubaguy: but that means we will face the same problem again on these projects. 12:17:44 I don't remember what we decided on that now 12:17:58 so I can accept current implementation 12:18:01 as its a relax not a restriction, I am less worried 12:18:32 v2.0 compat mode needs to accept them, beyond that, I can be persuaded either way I think 12:19:06 I thought we only relaxed it for v2.0 compat mode? did we do it for all versions in the end? 12:19:11 johnthetubaguy: completely agree that v2.0 compatible mode should accept the name contains spaces 12:19:30 johnthetubaguy: yea its all version 12:19:38 yea, we did it for all version 12:19:39 johnthetubaguy: but the patch has changed v2.1 also 12:19:55 because we think it is bug 12:19:58 without microversion bump 12:20:08 alex_xu_: yeah, right 12:20:24 oomichi: it can't have a bump, well a bump makes little sense, because it affects older versions 12:20:29 johnthetubaguy: I remember that point for v2.1 was, v2.0 users can move on v2.1 12:20:46 NestleWhitey! 12:20:55 gah, wrong window 12:21:04 gmann_: yeah, I just remember deciding I don't mind either way for that thing 12:21:06 sorry 12:21:15 alaski: hi :) 12:21:30 oomichi: hi :) 12:21:35 * alaski lurking 12:21:37 johnthetubaguy: but i like your point that its just a relax not restriction 12:22:01 gmann: successfully request keep succeeding, thats the key thing 12:22:04 so old v2.1 users are not effected 12:22:11 the spaces in the name is real use-case,so we think it is bug. 12:22:15 johnthetubaguy: yea 12:22:21 if it is bug, we should fixed both in v2 and v2.1... 12:22:34 we are using v2.1 as standard api on the gate. so if reverting back, the reverting will break the other project gate 12:23:12 I don't we should revert 12:23:17 yeah, I can accept it as the bug without the bump 12:23:24 +1 12:23:34 alex_xu_: yeah, we cannot do it 12:23:44 oomichi: gmann_ thanks 12:23:48 so we can move on? 12:23:54 so i think we should backport that on kilo too (v2.1)? 12:23:59 gmann_: yes 12:24:14 let's move on 12:24:15 gmann_ post patch put v2.1 compat and v2 legacy jobs as experimental 12:24:19 #link https://review.openstack.org/#/c/221608/ 12:24:24 because i saw device name thing are done for kilo, matt patch 12:24:25 gmann_: thanks to gmann_ 12:24:50 is there anyone interesting in the backport? 12:24:54 * bauzas waves super late :( 12:25:06 alex_xu_: so the report you pointed first should be closed, right? 12:25:21 oomichi: I guess, not 12:25:29 oomichi: you mean the hostname bug? 12:25:31 alex_xu_: 1495388 12:25:36 alex_xu_: i can do backport 12:25:43 gmann_: thanks 12:25:56 alex_xu_: np 12:25:57 #action gmann_ backport the server name fix 12:26:02 alex_xu_: https://bugs.launchpad.net/nova/+bug/1495388 12:26:03 Launchpad bug 1495388 in OpenStack Compute (nova) "The instance hostname didn't match the RFC 952 and 1123's definition" [Medium,Incomplete] 12:26:20 thats importnat 12:26:23 oomichi: I think the bug still existed 12:26:29 alex_xu_: why? 12:26:35 when we set the hostname, we need to remove spaces, etc, so we can use it as a hostname 12:26:41 oomichi: like only one character 'a' 12:26:44 as we discussed in last weeks meeting 12:27:06 oomichi: and I think that we need more unittest for the hostname 12:27:21 oomichi: the bug just for we won't forget this, we need someone take a look at it more 12:27:42 alex_xu_: that is different from server name? 12:27:47 oomichi: yes 12:28:09 if no one interesting on this bug, I can continue take a look at it 12:28:36 alex_xu_: ok, I also will check it later 12:28:47 oomichi: thanks 12:28:54 np:) 12:28:58 #action alex_xu_ and oomichi take a look at https://bugs.launchpad.net/nova/+bug/1495388 more 12:29:01 Launchpad bug 1495388 in OpenStack Compute (nova) "The instance hostname didn't match the RFC 952 and 1123's definition" [Medium,Incomplete] 12:29:04 so let's move on 12:29:20 #link https://review.openstack.org/#/c/221608/ 12:29:30 hope everybody can review this ^ 12:29:38 for gate cleanup 12:29:59 the last action was "everyone review kenichi's json schema for 2.0 patch - https://review.openstack.org/221129 as a way to enforce differently for v2.0" 12:30:13 that patch already merged 12:30:20 thanks to oomichi work on it 12:30:27 alex_xu_: yeah, thanks everyone ;) 12:30:34 oomichi: :) 12:30:42 #topic API Bug 12:30:50 #link https://bugs.launchpad.net/nova/+bug/1491511 12:30:52 Launchpad bug 1491511 in OpenStack Compute (nova) "Behavior change with latest nova paste config" [Critical,In progress] - Assigned to Alex Xu (xuhj) 12:30:58 ok...we back to server name again 12:31:18 looks like oomichi still doesn't like it 12:31:30 alex_xu_: yeah still -1, sorry 12:31:31 what are the outstanding patches on that, just the server name? 12:31:38 for the strip leading/trailing spaces part 12:31:50 johnthetubaguy: for all resource names 12:31:55 OK, is that the only one now? 12:31:55 #link https://review.openstack.org/220791 12:32:20 another one for support that fix 12:32:21 #link https://review.openstack.org/222032 12:32:34 johnthetubaguy: yes 12:32:44 yeah, I see that now, cool 12:33:09 oomichi: what fix are you wanting to see here? 12:33:11 at least, if we don't want to fix that, we should close that critical bug first 12:33:39 johnthetubaguy: I don't want to strip spaces automatically on nova side 12:33:52 but thats what v2.0 was doing, in most cases? 12:34:05 so we have to do it for the v2.0 compat mode, right? 12:34:06 johnthetubaguy: that was wrong behavior on v2.0, and we cannot find the reason 12:34:27 johnthetubaguy: and actual use cases 12:34:39 oomichi: but thats irrelavant, it could be adding "@" for every space, and we would have to copy it 12:35:00 johnthetubaguy: but the patch, we are saying "this is a standard way in nova" 12:35:02 v2.0 compat needs to be the same as v2.0 right? 12:35:35 johnthetubaguy: the first purpose of v2.0 comp was just for relaxing at the summit 12:35:39 oomichi: we are making it consistent for the v2.0 compat, I believe v2.1 actually stops those trailing things being passed it, so it doesn't do anything for v2.1 12:36:50 johnthetubaguy: and I hope we can avoid unreasonable code in v2.1. 12:37:05 oomichi: but we need v2.0 compat to work 12:37:15 I just can't see another option here 12:37:20 johnthetubaguy: for avoiding breaking the existing users 12:37:27 oomichi: yes 12:37:35 at least that patch avoid breaking some users 12:37:45 johnthetubaguy: so if we can find actual use cases for that, I +1 on it. 12:37:50 right, it keeps v2.1 unchanged, and makes v2.0 compatible 12:37:52 but indeed part of api not strip the spaces 12:37:53 i am worried we have lot many cases to fix for v2.0 comp mode 12:37:59 johnthetubaguy: but we cannot find it yet 12:38:11 and due to lack of testing coverage we do not know those yet 12:38:22 oomichi: the use case is not important, its just what the API does, so it needs to keep doing it 12:38:40 its sucks, we all agree that, but it has to stay the same to be compatible 12:38:57 so how about running current code without the patch and waiting for the bug report? 12:39:30 we can see actual use cases after the report 12:40:00 when we remove v2 compat mode? 12:40:19 alex_xu_: we can not do that forever, I guess 12:40:20 in theory, if we ever increase the min_version, we can drop that code 12:40:33 I can't imagine when that would be, but yeah 12:40:56 yea, I see, it almost forever 12:41:21 then I'd like to keep the code clean without unreasonable code 12:41:49 we need to keep the v2.0 contract though, else folks just will never deploy this compat mode 12:41:51 alex_xu_: if all user start liking and move to some great useful microversion :) 12:42:05 gmann_: yea, hope so 12:42:32 allowing trailing spaces, and then storing in the DB is a massive API change 12:42:42 yea, at least this patch avoid people breaking 12:42:51 we had people compain about us blocking the trailing spaces, hence we are looking at this 12:43:04 we need to keep the old behaviour 12:43:24 johnthetubaguy: are there actual users complaining it? 12:43:25 one more point 12:43:46 if we are not strip the spaces, that look like problem for people switch to v2.1 api 12:43:57 if so, we can see actual use case and I can agree with the patch 12:44:13 oomichi: I thought we did get people with breaking tests for the spaces issue, but I honestly don't remember the details now 12:44:32 oomichi: we can't hope to know how our API is used 12:44:45 our python-novaclient and tempest were both sending bad requests, and we only just spotted that 12:45:18 johnthetubaguy: ok, I agree with affecting it to v2.0 comp mode. 12:45:27 oomichi: so thats all the patch does 12:45:36 as I understand it, anyway 12:45:44 but I'd like to find the more clean way 12:46:11 oomichi: can we merge the behavior fix, then do a refactor then? 12:46:12 at least, I'd like to say "this behavior is not standard" anyway ;) 12:46:30 johnthetubaguy: when is the deadline? 12:46:43 johnthetubaguy: how we will find such more cases (v2.0 comp mode), wait for bug report and fix case by case? 12:46:54 oomichi: we have a release in a few weeks, I would rather we fixed it before then 12:47:19 gmann_: so liberty turns it on by default, that should help force the issue 12:47:28 johnthetubaguy: ok, thanks. I will +1 on the patch if I cannot find it this week 12:47:41 oomichi: thanks 12:47:46 gmann_: that switch is how we came across all these 12:48:13 johnthetubaguy: ohk 12:48:41 ok, so we agree on continue this fix, at least oomichi will take a look at it 12:48:52 alex_xu_: I agree :) 12:48:53 oomichi: 21st september is about the date RC1 is expected 12:49:05 johnthetubaguy: ok, thanks 12:49:15 johnthetubaguy: rax tried it or after liberty release? 12:49:16 so it would be good to get one of those fixes merged by friday 12:49:36 #action oomichi will take a look at https://review.openstack.org/220791 more to find out more clean way 12:50:22 ok, so the time is tight 12:50:25 gmann_: its not been tried yet, mostly as we are waiting for all the known bugs to be fixed first, and then we have to port all our old extensions into v2.0 compat mode, somehow 12:51:07 WARN: 10 mins left 12:51:09 johnthetubaguy: ok 12:51:14 so let's move on 12:51:27 #link https://review.openstack.org/222033 12:51:32 It is broken by changing the object's name field to enum. It is broken after v2.1 release, but I think it's fine, as this API only used by openstack service internal. So I want to fix it without microversion. 12:51:53 anyway I don't this important bug 12:52:08 if agree one this, we can move on, and people review it off the meeting 12:52:33 s/one/on/ 12:53:09 alex_xu_: its a 500 error, never a need for a bump 12:53:29 johnthetubaguy: it is restrict the name validation 12:53:48 johnthetubaguy: before it is anytihng in the name. now it is enum. 12:53:55 anyway I don't it need a bump also 12:54:01 alex_xu_: its 500->400 that seems fine 12:54:11 johnthetubaguy: ok, cool 12:54:18 so let's move on? 12:54:35 #topic Removal of v3 naming from source tree 12:54:42 alex_xu_: yea 500->400 seems fine. 12:54:43 #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1462901,n,z 12:54:48 gmann_: thanks 12:54:54 so I have an issue with this one: https://review.openstack.org/#/c/223071/3 12:55:09 can we just delete the ViewBuilderV21 classes? 12:55:19 should we not have v2.0 and v2.1 being the same? 12:55:30 I guess I am missing something? 12:55:40 squashed together extensions maybe? 12:56:10 I can dig it later 12:56:11 johnthetubaguy: good question...at least I know some of extension merged in the v2.1 API, so the viewbuilder will be different. the v2.1 viewbuilder will add some extend attribute which in the v2 12:56:39 but can we do that before we remove extension support for v2.0 12:57:00 gmann_: it already did 12:57:07 lets dig in that review 12:57:14 anyway, let us check that more in the review 12:57:22 alex_xu_: but only deprecated not removed 12:57:23 I want to cover the docs though, since thats the most important thing for us to work on right now 12:57:26 #topic API Documentation Improvement 12:57:27 yea 12:57:31 olla 12:57:42 I remember we say we need improve the concept doc 12:57:44 so where are we ant with the concepts guide update? 12:58:06 I know sdauge was hoping to take a look at one point, not sure if he has managed that 12:58:26 I see this as release critical really, more so than the v3 rename patches 12:58:26 yea, he isn't here today, let me catch him when he online 12:58:53 yea 12:59:12 so let me catch sdague later 12:59:36 annegentle: sorry, no more update at here today :( 12:59:37 * bauzas hopes noone will say WSME autodocs 12:59:47 nope 13:00:00 bauzas: we have swagger 13:00:07 I think I owe sdague a publishing job but I can't get the "run across repos" working 13:00:21 still, we are publishing what we have so far 13:00:21 let word, we may need begin to thing about summit and the thing for M release 13:00:29 we may need discussion that in next few meeting 13:00:44 annegentle: 13:00:47 annegentle: ok 13:00:54 anything it time to close meeting 13:00:57 thanks all 13:01:01 thanks 13:01:04 #endmeeting