#openstack-meeting log

12:00:02 <alex_xu> #startmeeting nova api
12:00:03 <openstack> Meeting started Tue Feb  2 12:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:06 <openstack> The meeting name has been set to 'nova_api'
12:00:13 <alex_xu> who is here today?
12:00:15 <cdent> o/
12:00:19 <gmann_> hi
12:00:21 <oomichi> hi
12:00:28 <eliqiao> o/
12:00:42 <johnthetubaguy> o/
12:00:49 * alex_xu found he have slow network
12:01:01 <alex_xu> welcome back everyone!
12:01:11 <alex_xu> let's run the meeting
12:01:15 <alex_xu> #topic content patches up for review
12:01:25 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/complete-todo-in-api-concept-doc,n,z
12:01:42 <alex_xu> thanks for the review about microversion!
12:01:56 <alex_xu> the last few concept about server we left
12:02:17 <alex_xu> I think we can finish them in Mitaka
12:02:33 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:fix-compute-api-ref,n,z
12:02:36 <jichen> o/
12:02:45 <sdague> o/
12:02:49 <alex_xu> jichen: still thanks for all your work on the api ref :)
12:03:03 <jichen> alex_xu: :)
12:03:08 <Kevin_Zheng> o/
12:03:14 <alex_xu> And as we have a lot of feature merged, so I think we should keep eye on some feature may need update api concept doc, we should ask people help us keep the doc update to date.
12:03:20 <alex_xu> So happy when I saw this patch https://review.openstack.org/#/c/273376/3
12:03:32 <oomichi> alex_xu: all TODOs can be removed with current patches from api-ref? or need more new patches?
12:04:00 <alex_xu> oomichi: need more patches, there are few in servers concept
12:04:12 <oomichi> alex_xu: ok, I see
12:04:27 <alex_xu> wait, I remember there are some about network and volume api, but I think servers concept is more important
12:04:51 * sdague stars all these reviews to come back to later
12:04:52 <johnthetubaguy> there was a discussion about network APIs this morning
12:05:07 <alex_xu> johnthetubaguy: discuss at where?
12:05:10 <johnthetubaguy> it would be good to describe our preference for configuring ports outside of Nova
12:05:26 <alex_xu> johnthetubaguy: +1
12:05:27 <johnthetubaguy> just in the nova channel, a few hours back
12:05:38 <alex_xu> cool, I will scrollback later
12:06:02 <johnthetubaguy> also the get me a network, that is on its way, makes the "do the default networking" think work for more use cases
12:06:19 <johnthetubaguy> but anyways, just an aside, it would be nice to get that into the docs
12:06:29 <alex_xu> and a little describe about image api also, about user should use glance api instead of image api in nova
12:06:29 <sdague> johnthetubaguy: I can't wait for that, I have some weird code in grenade to smooth over the nova-net / neutron differences
12:06:49 <gmann_> johnthetubaguy: +1 for documenting those
12:07:03 <sdague> alex_xu: right, I think a piece of that is we're going to need to start returning imageRef links directly back to glance, which we only do on the image proxy today
12:07:09 <johnthetubaguy> sdague: ack seems like loads of folks are feeling that pain
12:08:04 <alex_xu> cool, let us finish the concept doc in Mitaka, and we should begin to ask people update doc when there patch merged
12:08:06 <sdague> I think we're probably at the point in the cycle where we should get up a wish list for things we think should change in the API in the next cycle, and start prioritizing
12:08:12 <sdague> so we can hit the ground running
12:08:28 <alex_xu> sdague: +1
12:08:38 <jichen> +1
12:08:59 <sdague> I think structured errors in json would be one of the best adds, but it going to take a lot of people working together on it.
12:09:00 <alex_xu> sdague: how can we start that? create an etherpad first, then people begin put the idea in?
12:09:07 <sdague> alex_xu: yeh, I think etherpad
12:09:26 <sdague> you want to start one? and we can discuss during open discussion at the end of meetings over the next month
12:09:40 <alex_xu> sdague: yes
12:09:44 <alex_xu> #link https://etherpad.openstack.org/p/newtown-nova-api-idea
12:09:54 <alex_xu> create one is fast :)
12:09:56 <johnthetubaguy> I think its newton?
12:10:01 <gmann_> sdague: alex_xu structured errors in json ?
12:10:03 <alex_xu> oops, sorry...
12:10:13 <johnthetubaguy> but top idea to collect those now
12:10:22 <johnthetubaguy> I think that should include the policy discovery work
12:10:27 <sdague> johnthetubaguy: ++
12:10:33 <alex_xu> #link https://etherpad.openstack.org/p/newton-nova-api-ideas
12:10:38 <alex_xu> ^ the new one...
12:10:46 <johnthetubaguy> more documentation around the "find my external IP" workflows, and other interop like things
12:10:53 <sdague> yep, sounds great
12:11:03 <alex_xu> and swagger one
12:11:40 <alex_xu> johnthetubaguy: thanks, you already begin to edit it :)
12:12:13 * oomichi knows the next version is newton now
12:12:43 <alex_xu> do we want to discuss idea now, or leave it to next few weeks, just put the idea into the etherpad now?
12:13:05 <johnthetubaguy> lets just revisit at the next meeting?
12:13:13 <johnthetubaguy> while folks type ideas over the week?
12:13:17 <gmann_> +1
12:13:29 * johnthetubaguy needs to remember to talk about the ML thread about policy
12:13:42 <sdague> johnthetubaguy: ++
12:13:54 <alex_xu> cool
12:14:13 <alex_xu> bad news is Chineses new year in next week...
12:14:25 <alex_xu> but I may try to attend the meeting
12:14:37 <alex_xu> anyway let's move on
12:14:46 <alex_xu> #topic remove project id
12:14:53 <sdague> that code has landed
12:15:01 <sdague> it's microversion 2.18
12:15:02 <alex_xu> sdague: all of them?
12:15:13 <sdague> it was only one change at the end of the day
12:15:14 <alex_xu> oh, I remember that, I +w...
12:15:23 <sdague> there are some test cleanups that would be nice
12:15:24 <jichen> sdague: do we need changes in python-novaclinet?
12:15:25 <johnthetubaguy> alex_xu: lets say the week after for the deeper discussion, that seems OK
12:15:33 <sdague> jichen: those are already in
12:15:46 <jichen> sdague: ok,
12:15:55 <sdague> this devstack change would use this in normal runs - https://review.openstack.org/#/c/233079/
12:16:10 <alex_xu> johnthetubaguy: ok
12:16:20 <sdague> however, there is a tempest negative test class that fails under that scenario, I've suggested we remove it
12:16:27 <sdague> https://review.openstack.org/#/c/271467/
12:18:09 <alex_xu> ok, sounds good
12:18:20 <johnthetubaguy> sdague: good point, they are testing odd things really
12:18:59 <sdague> yeh, we just need to realize that sometimes the tests are no longer appropriate
12:19:31 <sdague> honestly, I'd like to drop all the negative testing out of tempest and only do it in our functional stack. Especially as it's all supposed to be caught by jsonschema now for the most part
12:20:01 <johnthetubaguy> yeah, agreed with that general direction
12:20:41 <oomichi> sdague: yeah, agree. but refstack is using some negative tests, so we need to take care for tempest consumers
12:20:44 <johnthetubaguy> its tempting to make defcore test certain error cases, but I am not quite sure how to deal with that
12:21:02 <sdague> oomichi: I didn't think refstack was supposed to be using negative tests
12:21:19 <oomichi> to be honest, I cannot find any merit why refstack is using them
12:21:34 <gmann_> sdague: oomichi i agree refstack should not tests so much negative testing at low level
12:21:38 <johnthetubaguy> I think its where a client needs to know how to recover from particular errors, but that probably isn't want most of those tests are doing anyways
12:21:51 <gmann_> its all component can make sure those.
12:21:56 <sdague> this test was a bad choice for compatibility for sure
12:22:12 <oomichi> sdague: yes
12:23:22 <alex_xu> ok, so sounds goods for now
12:23:32 <alex_xu> let's move on?
12:23:44 * edleafe_ yawns
12:24:01 <sdague> alex_xu: ++
12:24:02 <alex_xu> #topic API futures - patches for approved specs
12:24:12 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-sample-tests-with-all-extensions
12:24:22 <alex_xu> we merged part of those patches
12:24:34 <alex_xu> looks like we track the work have effect
12:24:41 <alex_xu> sdague: I saw you -1 one of them
12:24:53 <gmann_> alex_xu: yea, server things are making more clean
12:24:55 <gmann_> sdague: https://review.openstack.org/#/c/243396/
12:24:55 <alex_xu> but I think it is ok, as we deprecated extension for legacy v2 api also
12:25:08 <gmann_> sdague: actually for v2 also extensions are deprecated
12:25:12 <sdague> alex_xu: we deprecated it, we didn't drop it
12:25:19 <sdague> if we drop these tests, we're going to break it
12:25:28 <sdague> deprecated still means it needs to work
12:25:29 <gmann_> sdague: but same thing for v2.1 also
12:25:41 <sdague> I'm fine if we don't test this on v2.1
12:25:52 <sdague> but on the legacy v2 stack, I think we still need this
12:25:53 <alex_xu> sdague: emm...good point, deprecated != drop
12:26:09 <alex_xu> actually we already merge some sample tests for merge legacy v2 and v2.1 tests
12:26:21 <alex_xu> ok
12:26:24 <johnthetubaguy> its good for the v2.1 tests to always test with all extensions on, but yeah, v2.0 probably should keep the existing stuff
12:26:25 <sdague> my feeling is that extensions go away for real once we actually delete v2 legacy
12:26:26 <gmann_> yes, tests are shared among them and some are merged
12:26:39 <sdague> right, that's a bit problematic for what we want here
12:26:51 <johnthetubaguy> sdague: I think thats the truth
12:27:04 <alex_xu> ok, if we really feel uncomfortable for now, let wait for drop legacy v2
12:27:07 <johnthetubaguy> sdague: about the extensions being tied to legacy v2 that is
12:27:27 <johnthetubaguy> for v2.1 tests, I really would like them only to work with all extensions on
12:27:37 <johnthetubaguy> that might confuse things
12:27:38 <sdague> alex_xu: yeh. Also auggy is working through adding some test cases to the api samples testing engine, which might let us go both ways
12:27:44 <gmann_> johnthetubaguy: sdague so in that case we should keep doc too?
12:28:00 <sdague> honestly, I think we need to write down what we expect here
12:28:13 <alex_xu> sdague: that sounds cool, hope to see auggy's patch
12:28:14 <johnthetubaguy> yeah, it feels like we are confused
12:28:22 <sdague> maybe a spec or etherpad or something, just so we figure out where we are trying to get to
12:28:35 <johnthetubaguy> +1 for a quick etherpad
12:28:51 <johnthetubaguy> maybe use that newton one we just created?
12:29:04 <alex_xu> sdague: +1
12:29:12 <sdague> johnthetubaguy: sure, though I think a bunch of this can still happen in mitaka, as it's test / doc fixes
12:29:35 <johnthetubaguy> sdague: yeah, totally, thats a bit confusing I guess
12:29:46 <sdague> gmann_: can you start an etherpad for this? and we can make sure we're all on the same page before we move forward
12:30:23 <gmann_> sdague: sure, will create separate one and link that to newton one
12:30:30 <sdague> gmann_: great, thanks
12:30:38 <gmann_> sdague: ll be creating tomorrow morning
12:30:49 <johnthetubaguy> cools
12:30:57 <gmann_> i will hold current patches till then
12:31:06 <sdague> gmann_: works for me, just send a ping or an ML thread with the link and I'll put comments in it
12:31:22 <gmann_> sdague: sure.
12:31:28 <alex_xu> gmann_: thanks for all test merge works :)
12:31:35 <gmann_> alex_xu: np :)
12:31:43 <alex_xu> ok, cool, I think we can move on
12:31:51 <alex_xu> #topic open
12:32:04 <alex_xu> there is one open in the agenda
12:32:05 <alex_xu> NOTE about support "OS-SCH-HNT:scheduler_hints" as a subset of server dict in scheduler_hints.py:https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/scheduler_hints.py#L34-L37 "OS-DCF:diskConfig" is now a subset of server dict, quite strange to have scheduler_hints at top level. Question: should we do it in Newton? If do it, should we do it with microversion or not?
12:32:14 <alex_xu> Kevin_Zheng: ^ are you here
12:32:33 <Kevin_Zheng> yes
12:32:36 <Kevin_Zheng> I'm heare
12:32:38 <Kevin_Zheng> here
12:32:42 <alex_xu> Kevin_Zheng: cool, your turn
12:32:52 <Kevin_Zheng> Hi, a;;
12:32:53 <sdague> I think that probably needs a spec, because the fallout of who we might break is unclear to me
12:32:55 <Kevin_Zheng> sorry
12:33:00 <gmann_> I think we definitely need microversion
12:33:05 <sdague> but it seems pretty sane
12:33:13 <sdague> yeh, definitely a microversion, which means it needs a spec
12:33:15 <gmann_> sdague: +1 for spec first
12:33:16 <oomichi> alex_xu: nice point. From the client viewpoint, that makes difficult to implement client code.
12:33:17 <alex_xu> +1 for microversion
12:33:24 <Kevin_Zheng> OK then
12:33:35 <Kevin_Zheng> I will prepare a spec first
12:33:43 <oomichi> alex_xu: I faced the problem on tempest side also before
12:33:58 <Kevin_Zheng> And I have another question
12:34:00 <gmann_> yea even while v2.1 also
12:34:03 <Kevin_Zheng> or idea
12:34:23 <Kevin_Zheng> I saw this tag-instance bp was in the list
12:34:24 <alex_xu> oomichi: ok, I just say +1, then I got a nice point :)
12:34:41 <Kevin_Zheng> can we talk about it ?
12:34:51 <alex_xu> Kevin_Zheng: yes
12:35:23 <Kevin_Zheng> We want to use this feature in or productr
12:35:27 <Kevin_Zheng> product
12:35:38 <Kevin_Zheng> and we have a usecase like this
12:35:47 <alex_xu> actually I found a problem in tag instance bp, I don't think '/' works in our wsgi framework, we may return that is back to api-wg, to define a better tag-name schema.
12:35:57 <Kevin_Zheng> we want some tags only available for the admin
12:36:29 <Kevin_Zheng> but we don't want to change the policy file, because then the normal user couldn't use this feature
12:36:49 <Kevin_Zheng> how about add a column, admin_only to the table
12:37:01 <Kevin_Zheng> and only admin can change this field
12:37:15 <Kevin_Zheng> if it is admin only, then non-admin cant see it
12:37:27 <sdague> hmmmm
12:37:42 <johnthetubaguy> it feels like the protected properties that glance has
12:37:42 <sdague> it almost feels like tags should namespace to roles
12:37:58 <johnthetubaguy> hmm, maybe
12:38:01 <sdague> role:tag
12:38:07 <alex_xu> or just record the owner of tag
12:38:10 <sdague> and you can only see the tags for the roles
12:38:15 <sdague> that you are in
12:38:19 <johnthetubaguy> so we haven't yet merged the current tags blueprint, it needs more review
12:38:40 <johnthetubaguy> sdague: hmm, but when you add them, which role gets them? you always need the prefix?
12:38:43 <sdague> yeh, I do get the idea of different views on that though. Maybe we should debate that one in the spec
12:38:50 <Kevin_Zheng> yes it will be very useful to do ops
12:38:53 <sdague> do we have default role construct?
12:38:54 <johnthetubaguy> feels like a good spec debate
12:39:04 <sdague> yeh, this should also get a slot at summit I think
12:39:11 <johnthetubaguy> sdague: not AFAIK
12:39:18 <Kevin_Zheng> Hm, just want to raise this up
12:39:24 <sdague> because this is one of those things that 40 minutes face to face would help resolve
12:39:30 <johnthetubaguy> sdague: +1
12:39:38 <Kevin_Zheng> Hm, thanks alot
12:39:45 <alex_xu> cool
12:39:59 <sdague> Kevin_Zheng: in the mean time, please put your thoughts into the existing spec
12:39:59 <johnthetubaguy> sdague: actually, it might be member, or just being in the tenant, that is the default
12:40:12 <sdague> johnthetubaguy: sure, but there is a visibility thing which is interesting
12:40:19 <johnthetubaguy> sdague: +1
12:40:20 <Kevin_Zheng> sdague: sure I will do that
12:40:55 <johnthetubaguy> so I think we have merged the current spec, so its probably a new newton spec
12:41:13 <alex_xu> I also will check '\' case, then feedback to author, hope he can fix the schema early if there is a problem.
12:41:13 <johnthetubaguy> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/tag-instances.html
12:41:41 <sdague> alex_xu: ++
12:42:01 <alex_xu> ok, cool, the last thing
12:42:48 <alex_xu> appreciate who can chair this meeting in next week, I may not there for Chineses new year
12:43:46 <edleafe_> Too early for me, sorry
12:43:54 <sdague> alex_xu: I can do it
12:44:02 <alex_xu> sdague: thanks :)
12:44:14 <alex_xu> anymore open today?
12:44:31 * alex_xu pokes edleafe_ multiple times, help him get wakeup
12:44:31 <sdague> nothing from me
12:44:55 <alex_xu> 3...
12:45:02 <alex_xu> 2..
12:45:08 <alex_xu> 1.
12:45:13 <alex_xu> thanks all!
12:45:20 <alex_xu> #endmeeting