12:00:05 <alex_xu> #startmeeting nova api
12:00:07 <openstack> Meeting started Tue Dec 15 12:00:05 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:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:10 <openstack> The meeting name has been set to 'nova_api'
12:00:17 <alex_xu> who is here today?
12:00:22 <johnthetubaguy> hi
12:00:28 <jichen> o/
12:00:30 <oomichi> hi
12:00:54 <sdague> o/
12:01:00 <alex_xu> hello everyone, let's waiting one more minutes
12:01:08 <yalie> hi
12:01:32 <alex_xu> ok, let's get start meeting
12:01:41 <alex_xu> #topic actions from last meeting
12:01:47 <alex_xu> sdague make a patch for remove 1.1 and info the ops
12:02:00 <alex_xu> sdague: any update for this?
12:02:03 <sdague> doh, I totally spaced that one
12:02:16 <sdague> adding to my todo list for today
12:02:22 <alex_xu> sdague: :)
12:02:43 <alex_xu> #topic content patches up for review
12:03:10 <alex_xu> thanks for all the help on doc sprint
12:03:14 <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:03:43 <alex_xu> looks like we need more patch up
12:04:12 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/api-site+branch:master+topic:fix-compute-api-ref,n,z
12:04:30 <alex_xu> and looks like there isn't any active on api ref side.
12:04:36 <sdague> nice
12:04:46 <alex_xu> probably most of us focus on api concept side
12:04:47 <oomichi> nothing, cool :)
12:05:07 <oomichi> yeah, still a lot of TODO on concept side
12:05:15 <alex_xu> #topic most needed next content patches
12:05:34 <johnthetubaguy> yeah, on the ref side I double checked for missing things vs v2.0-ext doc again, and I think we are good now
12:05:40 <alex_xu> oomichi: yeh
12:05:56 <johnthetubaguy> the bits I added got merged, which is cool
12:06:09 <alex_xu> johnthetubaguy: cool
12:06:39 <alex_xu> probably I will try to fill more about extension and microversion next few weeks
12:06:57 <alex_xu> and we still have some TODOs for servers concept
12:07:16 <alex_xu> then I think we can move some focus to api-ref?
12:07:50 <oomichi> nice to move after the concept updates
12:07:52 <alex_xu> anyway free to submit patch for doc
12:08:16 <alex_xu> if no more question on doc, let's move on
12:08:27 <alex_xu> #topic remove project id
12:08:48 <alex_xu> sdague: do you want to say something, there are a lot of active around this
12:08:54 <alex_xu> include sample tests
12:09:10 <sdague> sure
12:09:30 <sdague> https://review.openstack.org/#/c/233076/ is the base functional patch
12:09:57 <sdague> alex_xu: I think you correctly asked if there is a way to turn this off in v2 compat mode, and I think we should do that
12:09:59 * gmann_ late due to network issue
12:10:10 <sdague> I just wasn't sure if there was a good hook or variable to know if we are in that mode
12:10:12 <alex_xu> sdague: I wrote a patch today for fix that
12:10:14 <alex_xu> #link https://review.openstack.org/257719
12:10:18 <sdague> alex_xu: ok, great
12:10:23 <sdague> I will look
12:10:34 <alex_xu> sdague: not sure this is good way, but works
12:10:40 <alex_xu> sdague: thanks
12:11:10 <sdague> the only issue we are running into right now is that because of how the api samples engine works, microversion is applied to docs and templates
12:11:34 <sdague> so having the v2.13 docs tree is currently not possible if we don't also have a v2.13 templates tree
12:12:08 <sdague> I've been trying to clean up a bunch of the api samples code in the process while considering how we want to move forward there
12:12:46 <gmann_> sdague: for refactoring the structure - https://review.openstack.org/#/c/255080/
12:13:03 <gmann_> sdague: for 2.13 version sample
12:13:49 <alex_xu> that is huge change
12:14:48 <sdague> gmann_: yeh, I'm not convinced that's what we want to do yet
12:15:03 <gmann_> sdague: oh
12:15:22 <sdague> honestly, I'm ok not quite having a solution until we clean up some of the api samples internals
12:15:23 <gmann_> sdague but for version which change all APIs, we might need sonething like this
12:15:32 <sdague> gmann_: we might
12:15:38 <gmann_> sdague: i see
12:16:23 <johnthetubaguy> I do keep wondering about how we have docs and tests use the same set of files, but that might be pushing it too far too quickly
12:17:12 <sdague> johnthetubaguy: sorry, I'm not sure I fully understand your point
12:17:15 <alex_xu> johnthetubaguy: sorry, I didn't get you
12:17:58 <gmann_> johnthetubaguy: you mean to have 1 set either under functional/api_samples or doc/api_samples
12:19:28 <alex_xu> so I think we just need help for sdague on cleanup sample tests, then waiting for figure out next step
12:19:41 <gmann_> alex_xu +1
12:19:59 <johnthetubaguy> sorry, got distracted there
12:20:01 * gmann_ having too much delay in msg
12:20:04 <sdague> alex_xu: yeh, I think that's the approach. I'm kind of puttering through some cleanups - https://review.openstack.org/#/c/257439/ reviews from there down would be good
12:20:18 <alex_xu> sdague: cool
12:20:19 <johnthetubaguy> gmann_ +1 to your description of what I was thinking
12:20:45 <sdague> johnthetubaguy: except they are 2 different things
12:20:50 <sdague> because we do a 3 way compare
12:20:59 <sdague> template to response, template to static document
12:21:27 <sdague> so that the code that fills things into the template doesn't end up something crazy
12:21:32 <gmann_> sdague 1 question on https://review.openstack.org/#/c/256387/
12:21:47 <sdague> and the docs files are used on our api site
12:22:01 <gmann_> sdague you are planning to update this or putting this idea into separate patches?
12:22:22 <johnthetubaguy> yeah, I guess we need the control the template gives us
12:22:25 <sdague> gmann_: I'm trying to clean up the rest of the api samples code first to make that patch simpler
12:22:49 <gmann_> sdague ok. Thanks
12:22:54 <sdague> johnthetubaguy: yeh, the philosophy of the api samples got a little lost over time.
12:23:24 <sdague> doing this patch https://review.openstack.org/#/c/257439 meant I had to touch nearly every file, and found some of drift
12:23:45 <sdague> I'll try to write up some test writing guide after this is all done
12:24:03 <johnthetubaguy> sdague: sweet, good to record the intent
12:24:15 <alex_xu> sdague: +1
12:24:24 <gmann_> sdagueyea nice idea
12:24:35 <gmann_> ops
12:25:01 <alex_xu> ok, I guess this all about sample tests, let's move on?
12:25:02 <sdague> anyway, reviews on those cleanups would be nice, I'm about 6 deep right now, plus the glance api servers series, and I'm out next 2 weeks
12:25:13 <sdague> so I'd like to get as much landed this week as possible
12:25:38 <alex_xu> I will focus on review those cleanup patch this week
12:25:53 <gmann_> me too.
12:26:19 <alex_xu> sdague: free to let me know if you need any coding help at here
12:26:29 <sdague> alex_xu: sure, will do
12:26:41 <alex_xu> ok, so let's move on
12:26:49 <alex_xu> #topic API futures - specs
12:26:57 <alex_xu> #link https://review.openstack.org/#/c/239276/
12:27:22 <alex_xu> I saw comments said this patch need discussion
12:27:24 <yalie> yes, this is for revming the verification of Ip address
12:28:16 <yalie> IP address is not mandarery in port of neutron now
12:28:39 <yalie> so we want to remove it in nova side too
12:28:43 <alex_xu> That changed the API behavior, so we need microversion at here
12:29:04 <yalie> yes, I just add a new patch which discribe it.
12:29:12 <johnthetubaguy> so... the change is
12:29:17 <oomichi> we need to change validation on json-schema or more deep code?
12:29:28 <alex_xu> johnthetubaguy: we already freeze the spec, so this change can we continue, except it is bug fix
12:29:33 <johnthetubaguy> when a port explicitly asks to not have an IP address, we should honour that
12:29:49 <alex_xu> s/so this change can/so this change whether can/
12:30:01 <sdague> I'm really not comfortable with "But
12:30:01 <sdague> there are some scenarios where the user doesn't want Neutron to handle any of
12:30:01 <sdague> the addressing or the IP level filtering because a completely separate system
12:30:01 <sdague> is managing that."
12:30:16 <yalie> johnthetubaguy: yes,
12:30:33 <johnthetubaguy> well, not sure its really a bug fix as such, but seems rude to block neutron if we can deal with it
12:30:34 <sdague> because I don't want nova having to plug into something beyond that
12:31:17 <alex_xu> johnthetubaguy: ok, got it
12:31:22 <sdague> what attribute in neutron specifies that a port has no address intentional?
12:31:28 <yalie> sdague: I think that is some IPAM backed to manager the IP address
12:31:31 <johnthetubaguy> sdague: it does seem to erode some assumptions that make me uneasy too
12:31:45 <sdague> yalie: right, and I think that should be a neutron backend
12:31:56 <sdague> that is kind of the whole point of having neutron
12:31:59 <yalie> sdague: yes
12:32:04 <sdague> that it provides that abstraction
12:32:11 <yalie> sdague: part of neutron
12:32:33 <johnthetubaguy> now, if there are ports that don't need an IP, because its just doing L2 forwarding, then make thats reasonable?
12:32:39 <yalie> sdague: but from vendor, maybe outside of neutron.
12:32:42 <johnthetubaguy> s/make/maybe/
12:33:00 <sdague> yalie: it should still be plugged in via neutron interfaces
12:33:10 <yalie> sdague: yes
12:33:25 <yalie> johnthetubaguy: yes
12:33:33 * edleafe yawns
12:33:43 <sdague> ok, so the question really is, is there an attribute set on a port today which says "I don't have an address, intentionally" and what is that?
12:34:00 <yalie> sdague: no, we don't have this attr
12:34:13 <sdague> because I'm ok if this is part of the trust arrangement with neutron that we don't error when neutron tells us not to
12:34:18 <sdague> but I don't want to do it in the common case
12:34:23 <yalie> sdague: neutorn port could have no IP address
12:34:27 <johnthetubaguy> sdague: right
12:34:32 <johnthetubaguy> so its this: https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address
12:34:34 <sdague> because I think that's a degradation for the majority of users
12:34:35 <johnthetubaguy> as I understand it
12:34:45 <sdague> yalie: ok, so that's what you need first
12:35:16 <johnthetubaguy> when the Port says "ME HAVE NO IP ADDRESS" I am OK with honouring that, I guess, but otherwise, we should still error if there is no IP address
12:35:31 <alex_xu> yalie: there will be no subnet in network when we didn't want ip in port?
12:36:00 <johnthetubaguy> hang on, not sure that spec has the extra port property we are neededing, my bad
12:36:00 <yalie> sdague: that's not for this, that attr is for control the L2ONLY spoofing
12:36:12 <yalie> sdague: when no IP address
12:36:47 <yalie> sdague: that neutron's port could have no IP don't depend on it, it has been supported for a while
12:37:10 <johnthetubaguy> yalie: so we added this check in Nova for a very strong reason
12:37:24 <johnthetubaguy> yalie: users got very confused, and ended up with VMs they couldn't use
12:37:32 <yalie> we can add/remove the IP addrss of the port from neutron API
12:37:44 <sdague> yalie: right, as johnthetubaguy said, we have this check because in the common case this completely confuses and breaks normal users
12:37:47 <johnthetubaguy> now if you explicitly say "hey this port should have no IP address", then thats cool
12:37:53 <sdague> this is clearly an exceptional case
12:37:59 <sdague> it should be treated as such
12:38:02 <johnthetubaguy> yalie: I consider that a neutron bug, honestly
12:38:04 <sdague> so require specific exception
12:38:18 <johnthetubaguy> sdague: +1
12:38:26 <sdague> which means the port needs to declare it's intent to not have an address
12:38:31 <sdague> not happen to not have an address
12:38:39 <johnthetubaguy> yep
12:38:48 <yalie> user could get a port no IP, and that would what they want to get.
12:39:03 <sdague> yalie: right, but I don't think you are listening, we want this explicit
12:39:16 <sdague> anyway, I left a -1 with review comments there
12:39:17 <yalie> I see
12:39:36 <johnthetubaguy> the check we added was due to real user issues
12:39:37 <alex_xu> I think probably we should send this to the email, then get neutron guys feedback?
12:39:46 <johnthetubaguy> we should reply on the spec
12:39:58 <alex_xu> johnthetubaguy: ok
12:40:04 <johnthetubaguy> its very confusing to split info between both the ML and the spec, really
12:40:11 <johnthetubaguy> unless we really need to
12:40:40 <yalie> ok
12:40:44 <alex_xu> johnthetubaguy: got it
12:40:46 <gmann_> separate question, any plan to remove proxy of other services from Nova with single microversion ?
12:41:09 <sdague> gmann_: not any time soon, maybe next cycle
12:41:35 <oomichi> gmann_: a single microversion will be huge impact to users..
12:41:36 <gmann_> sdague: ok, it will be nice to remove those :)
12:41:55 <gmann_> oomichi: hummm, may be service by service?
12:42:16 <oomichi> gmann_: that seems user-friendly :)
12:42:29 <gmann_> ok.
12:42:33 <alex_xu> I guess that is future thing
12:42:37 <alex_xu> so let's move on
12:42:42 <gmann_> alex_xu: yea
12:42:49 <johnthetubaguy> yeah, its next release
12:42:53 <alex_xu> #topic API futures - patches for approved specs
12:42:55 <johnthetubaguy> same for volume stuff
12:43:03 <alex_xu> #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/082113.html
12:43:22 <alex_xu> some contributor get trouble with this, I probably will try to help him
12:43:34 <alex_xu> we need pass the microversion info into the extension point
12:43:43 <johnthetubaguy> he did reach on IRC
12:44:02 <johnthetubaguy> the request does have the API version, so it can work correctly, roughly
12:44:05 <alex_xu> johnthetubaguy: yeh, he ping me last night, but he quits IRC when I wake up
12:44:33 <johnthetubaguy> but honestly, I think its probably better just to put that directly into the existing update method
12:44:49 <sdague> is there an existing patch up?
12:44:50 <johnthetubaguy> I know its got big, but it seems simpler to have that all in one place really
12:45:20 <alex_xu> johnthetubaguy: yea, that will be good, but what about existed server_create method in user-data, move that also?
12:45:37 <johnthetubaguy> sdague: I think it actually relates to this spec: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/user-data-modification.html
12:45:39 <alex_xu> sdague: not yet, at least I didn't saw one
12:45:45 <johnthetubaguy> alex_xu: I think so
12:46:11 <alex_xu> johnthetubaguy: probably I can have a patch up for merge user-data into servers
12:46:16 <sdague> alex_xu: so, honestly, I think we need to figure out how to start collapsing the extrypoint code. As we're moving to not letting people disable these, we should stop treating them as pluggable things in the code
12:46:20 <sdague> which might simplify
12:46:54 <alex_xu> sdague: yes, that means we need change our existed framework
12:47:01 <sdague> yeh
12:47:22 <gmann_> so no extension discovery at all right?
12:47:34 <johnthetubaguy> sdague: +1, once we remove that config
12:47:48 <alex_xu> sdague: but I'm not sure how much work on this, and it needs some review I guess, that will block other developer
12:47:48 <johnthetubaguy> gmann_: thats now microversions right?
12:48:07 <oomichi> gmann_'s point is nice
12:48:07 <sdague> johnthetubaguy: exactly
12:48:25 <gmann_> johnthetubaguy yea
12:48:28 <oomichi> list-extensions api cannot work if merging into a single place
12:48:30 <sdague> alex_xu: right, so for the user_data, I think just moving into servers is probably fine
12:48:33 <alex_xu> so probably two choices for now, merge the user-data into server or pass version to extension point
12:48:42 <johnthetubaguy> oomichi: it works, its just a static list now
12:48:47 <sdague> johnthetubaguy: right
12:48:50 <alex_xu> sdague: ok
12:49:08 <gmann_> but it might makes code little bit complex to have all merge in main fucntions?
12:49:12 <oomichi> johnthetubaguy: yeah, we can do that. but the code becomes really meaningless if doing that
12:49:14 <sdague> honestly, long term, it would be really nice if the API code looked like the REST tree
12:49:32 <oomichi> but can agree with that because of microversions
12:49:36 <alex_xu> #action alex_xu take a look at merge user-data into servers and contact the conributor
12:49:36 <johnthetubaguy> gmann_: it also makes it complex to split a single API across three files, with different bits of versions all over the place
12:49:48 <sdague> yeh, the current splits are really weird
12:49:54 <johnthetubaguy> sdague: +1
12:50:03 <gmann_> humm
12:50:05 <sdague> and you have extension file which are nearly all boiler plate
12:50:06 <johnthetubaguy> sdague: +1 for the code looking more like the REST API
12:50:20 <johnthetubaguy> oomichi: what do you mean the code becomes meaningless?
12:50:38 <gmann_> i think there are more cases of server create, other are few
12:50:49 <oomichi> current list of extensions are gotten from current extension framework
12:50:58 <sdague> oomichi: right, but we've deprecated that
12:51:03 <johnthetubaguy> gmann_: when everything is always on by default, there will be much less branching in there
12:51:08 <sdague> extensions are no longer a thing in the future
12:51:13 <oomichi> but if merging them into a single, nova needs to contain static list
12:51:22 <sdague> oomichi: right
12:51:24 <johnthetubaguy> oomichi: agreed
12:51:28 <gmann_> and implementation vise we can rearange the server create also but from single function
12:51:33 <sdague> it's only there for compatibility reasons
12:51:34 <oomichi> sdague: yeah
12:51:39 <alex_xu> one more work in this release, we should remove the extension white/block options
12:51:46 <alex_xu> s/block/black/
12:52:16 <sdague> alex_xu: honestly, that's also probably next cycle because we need a better story around policy
12:52:16 <oomichi> to be honest, I am still afraid to merge them into a single, because servers.py will be huge
12:52:23 <johnthetubaguy> alex_xu: honestly, I think we might want to wait until next cycle, its a big thing to remove
12:52:23 <oomichi> and unreadable
12:52:35 <alex_xu> ok
12:52:36 <johnthetubaguy> sdague: yeah, policy... arg
12:52:44 <sdague> ok, we're drifting
12:52:47 <alex_xu> for now, our developer have to something like this https://review.openstack.org/#/c/128940/90/nova/api/openstack/compute/extension_info.py ...
12:52:54 <sdague> so API related patches
12:52:59 <gmann_> oomichi yea, like legacy server create code
12:53:02 <sdague> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:glance_image_config,n,z
12:53:17 <sdague> this changes the way we configure glance servers
12:53:46 <sdague> it's needed to be able to root all the services at one http server on subtrees
12:54:17 <sdague> I also found a couple more XML references in our docs - https://review.openstack.org/#/c/257506/ and https://review.openstack.org/#/c/257507/
12:54:28 <johnthetubaguy> did we agree on the way forward for that extending of user_data, I think just do in inline right?
12:54:54 <johnthetubaguy> sdague: should we add the XML stuff into the above topic?
12:55:02 <alex_xu> johnthetubaguy: I'm ok with that
12:55:14 <oomichi> johnthetubaguy: +1
12:55:16 <sdague> so, we could, although honestly I'd rather just get a better dashboard
12:55:20 <gmann_> yup
12:56:24 <alex_xu> 5 mins left
12:56:26 <sdague> https://goo.gl/ji0NGf
12:56:33 <sdague> I think that catches most things
12:56:44 <alex_xu> let me jump to open directly, because I saw something in agenda
12:56:49 <alex_xu> #topic open
12:57:09 <gmann_> sdague Thanks, thats nice
12:57:26 <oomichi> sdague: cool dashboard
12:57:29 <alex_xu> sdague: cool
12:58:02 <Kevin_Zheng> HI, https://review.openstack.org/#/c/248989/
12:58:07 <Kevin_Zheng> this patch
12:58:16 <johnthetubaguy> added the dashboard into the bottom of https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
12:58:36 <Kevin_Zheng> it exposes Quiesce and Unquiesce API
12:58:53 <Kevin_Zheng> the spec has already approved
12:59:10 <Kevin_Zheng> Hope more people can review this one
12:59:38 <johnthetubaguy> Kevin_Zheng: I have marked the blueprint as NeedsCodeReview, so reviewers know its ready
12:59:42 <alex_xu> so one min left
13:00:04 <Kevin_Zheng> johnthetubaguy, Thanks alot
13:00:11 <Kevin_Zheng> johnthetubaguy: Thanks alot
13:00:23 <alex_xu> ok, thanks for all, free to openstack-nova to continue discussion
13:00:31 <alex_xu> #endmeeting