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