12:00:21 <alexus> #startmeeting nova api
12:00:22 <openstack> Meeting started Fri Jul 17 12:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is alexus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:25 <openstack> The meeting name has been set to 'nova_api'
12:00:38 <alexus> Hello~ who is here today?
12:00:43 <johnthetubaguy> hi
12:00:45 <gmann> hi
12:00:51 <bauwser> \o
12:00:53 <Jeffrey4l> hi
12:01:02 <alexus> hey everyone!
12:01:10 <alexus> #topic status of liberty priority items
12:01:11 <Jeffrey4l> alexus, alex_xu?
12:01:19 <alexus> Jeffrey4l: yes, it is me
12:01:32 <Jeffrey4l> u got a new name
12:01:54 <alexus> There is too much thing today. Most of thing is on good status
12:02:09 <alexus> #link https://review.openstack.org/152569
12:02:25 <alexus> Microversion client implement is going to right direction I think
12:02:42 <johnthetubaguy> so my ask is, do let me know if anything is blocking you all, so I can get it unblocked at the midcycle (if possible)
12:02:59 <johnthetubaguy> alexus: ah, good news, I am glad we are getting agreement there now
12:03:11 <alexus> johnthetubaguy: cool, got it, will let you know
12:03:29 <alexus> johnthetubaguy: yea, we just need focus on coding detail now
12:03:49 <alexus> appreciate everyone can review it
12:04:08 <alexus> #link https://review.openstack.org/#/c/193725/
12:04:09 <johnthetubaguy> alexus: yeah, possibly just a case of keeping this etherpad up to date: https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
12:04:20 <johnthetubaguy> I am hoping that gets more attention now
12:04:46 <alexus> johnthetubaguy: ok, no problem
12:04:46 <bauwser> +1
12:04:59 <bauwser> I use this etherpad for knowing which reviews should be done
12:05:35 <alexus> I should add a calendar reminder for updating it every week
12:05:52 <bauwser> alexus: I can hassle you :p
12:06:28 <alexus> bauwser: cool,  I should thanks :)
12:06:41 <alexus> the previous link is remove v3
12:07:20 <alexus> the first patch is ready, and the author want to get some review to know they are one the right direction before they are going to send out other patches
12:07:49 <alexus> basically it is good for me, but hope the team give some review.
12:08:00 <bauwser> fatty !-
12:08:03 <alexus> and I should update https://etherpad.openstack.org/p/liberty-nova-priorities-tracking !
12:08:13 <bauwser> :(
12:08:29 <alexus> bauwser: yea, not so easy to review althought just renaming
12:08:56 <bauwser> alexus: yup, let's discuss that out, I have an idea for helping
12:09:11 <johnthetubaguy> sdague: seems like we have a review of doom to look at soon: https://review.openstack.org/#/c/193725/
12:09:15 <alexus> bauwser: cool, waiting for your idea
12:09:23 <johnthetubaguy> so thats a patch we could make sure we land next week
12:09:27 <sdague> johnthetubaguy: oh, the move
12:09:34 <sdague> yeh, is edleafe going to be in MN?
12:09:35 <johnthetubaguy> sdague: yeah
12:09:47 <sdague> honestly I'd rather just have a few of us sit around and just do that
12:09:56 <johnthetubaguy> sdague: unsure, I forget I am afraid, but yeah, thats what I am thinking
12:10:22 <bauwser> alexus: my take is that we should leave the existing module and redirect it to the newer
12:10:42 <sdague> alexus: I had a question on - https://review.openstack.org/#/c/150687/ - I was expecting the hard code permissions moves to include a policy patch at the same time, and if not, to explain why
12:10:44 <bauwser> alexus: it would prevent that big hairy change
12:11:39 <johnthetubaguy> bauwser: big and scary will be fine if we get a bunch of us in the same room, just like the unit test move
12:12:03 <bauwser> johnthetubaguy: the problem is that it's adding more than just a rename
12:12:12 <sdague> bauwser: that's fine, we'll look it over together
12:12:25 <sdague> but the current tree structure is confusing people
12:12:31 <bauwser> sdague: not at midcycle - IRL, trying to get virtually
12:12:37 <johnthetubaguy> sdague: +1
12:12:45 <alexus> sorry, I just reboot my compute, I can't type any word suddenly...
12:13:05 <sdague> bauwser: sure, but we'll have enough eyes at midcycle to move something like that through
12:13:06 <bauwser> sdague: I certainly appreciate the move, I just think it probably needs a soften approach
12:13:10 <sdague> it's agreed direction
12:14:03 <bauwser> moving on ? :)
12:14:17 <alexus> yea, I'm checking the word I missed
12:15:07 <alexus> sdague: I'm not quite understand your question
12:16:13 <alexus> sdague: anyway I will check the patch detail after the meeting
12:16:27 <alexus> #link https://review.openstack.org/202900
12:16:33 <alexus> I sent out the spec for remove extension
12:16:40 <sdague> alexus: so, if we remove a hard coded permissions check from the db layer
12:16:49 <alexus> sdague: yup
12:16:51 <sdague> that was the default permissions that we wanted
12:16:58 <alexus> sdague: yes
12:17:02 <johnthetubaguy> sdague: ed is registered, I just checked
12:17:09 <sdague> so I expect those changes also include a policy.json change
12:17:28 <sdague> or a comment about why they do not (it was already done previously)
12:17:59 <sdague> https://review.openstack.org/#/c/150687/ just removes a permissions check with no reference to either of those things
12:18:25 <alexus> we need ensure whether there is any API entry for this db call
12:18:45 <alexus> or maybe there elevated context in the code
12:19:23 <sdague> sure, anyway, I -1ed it for now based on those grounds, but for these kinds of reviews it would be really good to explain why other changes aren't needed if they are not. Otherwise I get concerned that we're just openning up security holes.
12:19:47 <johnthetubaguy> yeah, that extra context is really handy
12:19:53 <alexus> sdague: ok, agree, the commit message should describe something
12:21:17 <sdague> alexus: as it was another intel person, I thought maybe good to highlight and you might be regularly talking with them as well
12:21:24 <sdague> anyway, we can move on from that
12:21:30 <alexus> and I hope get some review for this https://review.openstack.org/188235 bug fix, it is waiting for a long time
12:21:46 <alexus> sdague: yea, I will check with the author
12:22:12 <alexus> it is related to policy
12:22:23 <johnthetubaguy> alexus: great stuff for that priority etherpad
12:22:41 <alexus> johnthetubaguy: yea, it's on the etherpad
12:22:58 <johnthetubaguy> alexus: yeah, I need to get more folks to read it!
12:23:41 <alexus> ok, that is all I have for the prority items
12:23:56 <alexus> anyone have question?
12:24:23 <gmann> Need review on https://review.openstack.org/#/c/198622/
12:24:50 <gmann> based on that we can move on removing vif extension from v2.1 list - https://review.openstack.org/#/c/198934/
12:25:00 <alexus> yea, that is bug
12:25:31 <johnthetubaguy> I did raise that in the nova meeting, and I need to take a look myself
12:25:41 <gmann> johnthetubaguy: Thanks
12:25:54 <alexus> johnthetubaguy: thanks
12:26:24 <sdague> johnthetubaguy: https://review.openstack.org/#/c/198622/ seems like it should be a fast approve, it's just completely a bug
12:27:19 <johnthetubaguy> sdague: its an API change though, it certainly skips the freeze
12:27:52 <johnthetubaguy> so, are we sure we want OS-EXT-VIF-NET in the bit we add to v2.1?
12:28:21 <johnthetubaguy> I guess we want that so it says the same as v2.0
12:28:49 <sdague> johnthetubaguy: oh, so the patch is to just fix v2.1 to not list OS-EXT-VIF-NET as an extension
12:29:04 <sdague> gmann: do you then intend to do a microversion bump to put it back in?
12:29:20 <johnthetubaguy> the spec is the microverison bump to add it in, I think
12:29:22 <alexus> johnthetubaguy: re-add that field by microversion
12:29:23 <gmann> johnthetubaguy: sdague : yea, users want to move for v2.1 and for vif-net they can have microversion ready to provide that
12:30:11 <alexus> I guess johnthetubaguy talk about spec, sdague talk about the bug patch
12:30:20 <gmann> sdague: we discussed of adding it directly but that will be API contract break s v2.1 released
12:30:23 <johnthetubaguy> so I read the spec upside down
12:30:31 <johnthetubaguy> the spec is doing what I expected
12:30:44 <gmann> https://review.openstack.org/#/c/198622/
12:30:50 <alexus> at line 60 describe the bug pach to remove extension entry https://review.openstack.org/#/c/198622/5/specs/liberty/approved/add-vif-net-id-in-vif-list.rst
12:30:57 <gmann> johnthetubaguy: yea
12:31:29 <gmann> L60 is just information but will not be part of microversion impl
12:31:54 <alexus> But I think we should merged https://review.openstack.org/198934 after spec approved, then everyone know the whole plan
12:32:31 <johnthetubaguy> should the patch not point at the blueprint the spec is creating?
12:32:39 <johnthetubaguy> I mean we could point the spec at the bug
12:33:05 <johnthetubaguy> anyways, we can tidy the paper work up later
12:33:15 <gmann> johnthetubaguy: ok, i will do that. that will be all info together
12:33:24 <johnthetubaguy> gmann: cool, thank you
12:33:33 <alexus> gmann: thanks
12:33:48 <sdague> yeh, it probably should Depends-On the spec
12:34:07 <sdague> just to keep the process right and not land it prematurely
12:34:20 <alexus> sdague: +1
12:35:03 <gmann> done
12:35:17 <alexus> #topic open
12:35:26 <alexus> anymore open?
12:35:54 <Jeffrey4l> https://bugs.launchpad.net/python-novaclient/+bug/1325304  this bug.
12:35:56 <openstack> Launchpad bug 1325304 in OpenStack Compute (nova) "hypervisors.staticstics().running_vms count includes shutdown vms" [Wishlist,In progress] - Assigned to Jeffrey Zhang (jeffrey4l)
12:35:58 <sdague> alexus / gmann either of you going to be in MN next week?
12:36:12 <alexus> sdague: I won't go there
12:36:37 <Jeffrey4l> I want't to know add a new field `total_vms` is a good directions?
12:36:42 <gmann> sdague: I also would not be able to make
12:37:04 <alexus> sdague: let us know if there are change happen at MN
12:37:33 <gmann> alexus: +1
12:37:34 <sdague> Jeffrey4l: that seems like a broader nova question beyond the api.
12:37:47 <Jeffrey4l> ok. I am sorry.
12:38:11 <johnthetubaguy> Jeffrey4l: I think its worth a spec, but I recon that could work in a microversion
12:38:32 <sdague> yeh, given that it will be an additional field added
12:38:41 <alexus> looks like we can't change existed field's meaning
12:38:54 <johnthetubaguy> Jeffrey4l: its probalby because in most deployments shutdown VMs are counted as running, because they still use resources (local storage, etc), and have the resources locked for that specific host
12:39:06 <Jeffrey4l> johnthetubaguy, yep. I am working on it. Just want to know is that a right directions.
12:39:08 <johnthetubaguy> Jeffrey4l: it depends what you want to do with running vms really
12:39:08 <bauwser> johnthetubaguy: +1
12:39:14 <bauwser> shelved instances too
12:39:16 * alexus ignore my word
12:39:45 <johnthetubaguy> bauwser: actually shelved probably shouldn't be counted, long term, but yeah, they do mess that up
12:40:03 <johnthetubaguy> (because they shouldn't lock the resources, once offloaded)
12:40:21 <bauwser> Jeffrey4l: from a Nova PoV, we count the total of existing instances, whether they are running or not
12:40:40 <bauwser> Jeffrey4l: that's only when an instance is deleted that we consider it out of the resources scope
12:40:48 <bauwser> but we're far off-topic :)
12:41:18 <Jeffrey4l> ok. Got it. we can continue the talk in the bp's bug.
12:41:24 <Jeffrey4l> sorry for the off topic.
12:41:30 <Jeffrey4l> let's move on.
12:41:38 <bauwser> Jeffrey4l: for sure, I'm tempted to consider it as invalid :/
12:41:52 <bauwser> Jeffrey4l: but let's consider that in the LP bug
12:41:59 <Jeffrey4l> ok\
12:41:59 <johnthetubaguy> Jeffrey4l: it would need a nova-spec to land that change, if that helps your thinking on that
12:42:05 <bauwser> ++
12:42:07 <johnthetubaguy> (because its an API change)
12:42:32 <bauwser> and because it's far more important than just counting, it means what we consider a running instance
12:42:48 <bauwser> oops
12:42:53 <johnthetubaguy> Jeffrey4l: just need to describe the use case behind why the existing count doesn't work for you, so we can understand the problem you have, and then we can help you fix that
12:42:54 <bauwser> s/running/active
12:43:22 <johnthetubaguy> Jeffrey4l: its a bit hard to tell from the bug, the current behaviour is intectional
12:43:39 <bauwser> moving on ? :)
12:43:44 <johnthetubaguy> yeah, a rename of running to active, would be a good thing in a microversion
12:43:49 <johnthetubaguy> yeah, I think we are all done
12:44:03 <Jeffrey4l> ok. I will add move in the LP bug.
12:44:04 <gmann> last from me. need to ask reviews for sample tests merge patches
12:44:04 <bauwser> johnthetubaguy: re: midcycle, saw your link
12:44:07 <gmann> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:merge_sample_tests,n,z
12:44:27 <johnthetubaguy> bauwser: my link?
12:44:29 <bauwser> johnthetubaguy: keep it up-to-date while you try to provide such remote connectivity
12:44:39 <bauwser> johnthetubaguy: oh sorry, the hangout link
12:44:39 <gmann> sdague: Thanks for reviewing, please review more. After those we will be able to remove v3 things from api-paste
12:44:53 <johnthetubaguy> bauwser: oh right, yeah, just going to talk in #openstack-nova about that, but lets not get off topic...
12:45:18 <bauwser> alexus: gmann: see the prio etherpad, there is a way to get some traction from the midcycle - but that would be async :)
12:45:32 <bauwser> johnthetubaguy: sure thing - diverting
12:45:47 <alexus> bauwser: ok
12:46:06 <alexus> so any question, then we close the meeting
12:46:14 <alexus> 3...
12:46:15 <gmann> bauwser: ok
12:46:19 <alexus> 2..
12:46:24 <alexus> 1.
12:46:30 <alexus> thanks all
12:46:33 <johnthetubaguy> alexus: thank you!
12:46:35 <gmann> Thanks all
12:46:39 <alexus> #endmeeting