14:00:18 <mriedem> #startmeeting nova
14:00:18 <openstack> Meeting started Thu Aug 11 14:00:18 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'nova'
14:00:28 <alaski> o/
14:00:30 <markus_z> o/
14:00:30 <takashin> o/
14:00:31 <auggy> o/
14:00:31 <johnthetubaguy> o/
14:00:34 <cdent> o/
14:00:43 <rlrossit_> o/
14:00:48 <abhishekk> 0/
14:00:49 <dansmith> oj <-- headset emoticon, finishing another call
14:00:51 <doffm_> o/
14:01:16 <mriedem> dansmith: i thought you were snorkling
14:01:19 * edleafe is shocked to learn that dansmith is oJ!
14:01:30 <edleafe> \o
14:01:49 <mriedem> ok let's get started
14:01:52 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova
14:01:59 <mriedem> #topic release news
14:02:07 <mriedem> #link Newton release schedule: https://wiki.openstack.org/wiki/Nova/Newton_Release_Schedule
14:02:12 <mriedem> #info Aug 22-26: final non-client library release (oslo) - so if you  need things released from dependent libraries get them done soon
14:02:19 <mriedem> ^ just another reminder
14:02:26 <mriedem> #info Call for extra ATCs for Newton: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101360.html
14:02:46 <mriedem> if you're looking for ATC credit for summit w/o a commit, see ^
14:02:54 <mriedem> and let me know
14:03:05 <mriedem> mikal had posted some names in the ML thread and some i was actually surprised by
14:03:09 <mriedem> since i thought they had commits
14:03:23 <mriedem> any questions on the release? FF is 9/2 so we have about 3 weeks left
14:03:37 <mriedem> #topic bugs
14:03:53 <mriedem> gate CI status is OK
14:04:09 <mriedem> the check queue was super backed up yesterday, 500+
14:04:27 <mriedem> but i'm not aware of any blocking failures
14:04:42 <mriedem> #link 3rd party CI status http://ci-watch.tintri.com/project?project=nova&time=7+days
14:04:48 <mriedem> #info Intel NFV CI is failing on stable branches because it doesn't install Tempest in a venv
14:04:55 <mriedem> wznoinsk: do you have any updates on that?
14:05:33 <mriedem> anyway, they are aware and are working on it
14:05:43 <mriedem> i'm not aware of any critical bugs,
14:05:57 <auggy> there were two yesterday and fixes were released
14:05:59 <mriedem> we did have a regression with one of the config option cleanup changes reported in channel yesterday
14:06:29 <mriedem> auggy: ok,
14:06:34 <mriedem> this is the one i was thinking of https://bugs.launchpad.net/nova/+bug/1611940
14:06:34 <openstack> Launchpad bug 1611940 in OpenStack Compute (nova) "vncserver_proxyclient_address changed from stropt to ipopt, breaking backwards compat without deprecation" [High,Fix released]
14:06:40 <johnthetubaguy> mriedem: yeah, that was a good catch
14:06:50 <johnthetubaguy> I added another for the service.py file for listen_addresses
14:07:06 <auggy> the ones fixed yesterday were https://bugs.launchpad.net/nova/+bug/1609625 and https://bugs.launchpad.net/nova/+bug/1609691
14:07:06 <openstack> Launchpad bug 1609625 in OpenStack Compute (nova) "The 'create:forced_host' policy is set to 'rule:admin_or_owner' by default" [Critical,Fix released] - Assigned to Takashi NATSUME (natsume-takashi)
14:07:08 <openstack> Launchpad bug 1609691 in OpenStack Compute (nova) "Non-admin users can lists VM instances of other projects (tenants) by default" [Critical,Fix released] - Assigned to Takashi NATSUME (natsume-takashi)
14:07:25 <johnthetubaguy> here is my patch around that: https://review.openstack.org/#/c/353917/
14:07:28 <mriedem> ah, ok, so policy slips
14:07:57 <mriedem> johnthetubaguy: cool, i'll look after the meeting
14:08:02 <johnthetubaguy> yeah, not sure if some where v2.1 back to beginning of time
14:08:08 <wznoinsk> mriedem: I'm sorry to be late, yes, the stable branches were affected because of a not-so-great workaround we had in place, it's now removed and the tempest/urllib issue is now gone
14:08:19 <mriedem> wznoinsk: great
14:08:24 <mriedem> thanks for quickly fixing that
14:08:33 <johnthetubaguy> mriedem: using a hostname is a bit unreliable (does dns resolve, uses first ip it gets back), but legit and we used to allow, so we still should
14:09:09 <mriedem> johnthetubaguy: yeah so maybe for these cases we should open a bug to eventually deprecate them from using hostname, but give that signal before we switch to IPs
14:09:36 <mriedem> moving on
14:09:38 <johnthetubaguy> mriedem: yeah +1, give me the action to sort that out
14:10:08 <mriedem> #action johnthetubaguy to sort out the deprecation plan for changing StrOpt configs to IPOpt for things that allow hostnames today
14:10:18 <mriedem> thanks
14:10:20 <mriedem> #topic reminders
14:10:27 <mriedem> #link Newton review focus list: https://etherpad.openstack.org/p/newton-nova-priorities-tracking
14:10:33 <mriedem> #help https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty Volunteers for 1 week of bug skimming duty?
14:10:50 <mriedem> looks like next week is open for bug triage
14:11:00 <mriedem> #topic stable branch status
14:11:06 <mriedem> stable/mitaka 13.1.1 was released this week
14:11:18 <mriedem> we have some good fixes lined up for review in stable/mitaka related to shelve bugs
14:11:38 <mriedem> would be nice to get those in before 9/2 so we can do a small patch release
14:11:55 <mriedem> #topic subteam highlights
14:12:01 <mriedem> alaski: cells v2 meeting highlights?
14:12:16 <alaski> dansmith and I are going to have a chat about grenade testing after this meeting
14:12:26 <alaski> otherwise we touched on reviews that are up and ready
14:12:47 <alaski> that was about it
14:12:54 <mriedem> yup, ok
14:12:59 <mriedem> thanks
14:13:06 <mriedem> edleafe: jaypipes: scheduler subteam meeting highlights?
14:13:09 <edleafe> Short meeting this week
14:13:14 <edleafe> Adding eyes on jaypipes's rt-unit-test series, Yinxin's flavor/capability proposal, and cdent's placement DB stuff
14:13:21 <edleafe> That's it
14:13:28 <mriedem> i had a question,
14:13:37 <mriedem> dynamic resource classes
14:13:42 <jaypipes> mriedem: yes?
14:13:43 <mriedem> the spec wasn't approved for that
14:13:47 * jaypipes perks up
14:14:05 <mriedem> is it still a thing being pushed on for newton? or is it just a distraction from the placement API stuff at this point?
14:14:21 <jaypipes> mriedem: that is the stretch goal for us in Newton, yeah.
14:14:36 <jaypipes> mriedem: it's part of the placement API. CRUD operations on resource classes.
14:15:03 <mriedem> so https://review.openstack.org/#/c/312696/
14:15:10 <mriedem> i see lots of -1s
14:15:19 <jaypipes> mriedem: the integration of Ironic node resource class and dynamic resource classes isn't something we're aiming for in Newton, though. The stretch goal is only to add the REST API CRUD operations for user-defined resource classes.
14:15:23 <jaypipes> to the placement API.
14:15:30 <mriedem> so https://review.openstack.org/#/c/312696/ is something else then
14:15:49 <jaypipes> mriedem: no.. that is the right spec.
14:16:06 <mriedem> heh, ok :)
14:16:08 <jaypipes> mriedem: the -1s are for really minor things or not related to the spec frankly.
14:16:21 <jaypipes> mriedem: I'd REALLY appreciate a review on that from you and spec cores.
14:16:37 <mriedem> my concern is if time is being spent on a stretch goal when the main thing isn't done yet and we have 3 weeks left
14:16:48 <jaypipes> mriedem: perfection enemy of the good and all that...
14:17:01 <mriedem> but i don't know the scope of the work proposed for newton for the CRUD ops and all
14:17:07 <mriedem> anyway, i'm just bringing it up
14:17:14 <jaypipes> mriedem: absolutely time is being spent 100% on the non-dynamic resource classes stuff right now.
14:17:32 <mriedem> and the RT unit test cleanups are paving the way for the RT calling the placement API?
14:17:38 <mriedem> sorry i haven't been through all of that yet
14:17:50 <jaypipes> mriedem: it's very small scope (maybe 4 patches) that add simple lookup and add/delete ops for resource class strings.
14:18:23 <jaypipes> mriedem: yes, absolutely. the rt-unit-tests line things up (and actually most are already merged, only a few left on top of that stack)
14:18:46 <dansmith> the rt-unit-tests set is really an excuse to pad my stats
14:18:46 <mriedem> ok, thanks for the update, i've been off on other things so needed that
14:18:51 <dansmith> and I commend jaypipes for doing it
14:18:52 <jaypipes> mriedem: and the final patch in that stack gets rid of the test_tracker.py/test_resource_tracker.py duplication, which is a nice win for clarity.
14:19:14 <mriedem> we can move on
14:19:19 <dansmith> jaypipes: hah, I read that as "a nice win for charity"
14:19:23 <jaypipes> heh
14:19:35 <mriedem> tdurakov: any highlights from the live migration meeting this week?
14:20:19 <mriedem> well,
14:20:32 <mriedem> my recollection is most discussion was around live migration CI
14:20:42 <tdurakov> mriedem: https://review.openstack.org/#/c/353002/ - merged, so hope we could add live-migration job to voting list soon
14:21:12 <mriedem> tdurakov: ok and rebase https://review.openstack.org/#/c/329466/
14:21:16 <mriedem> to enable nfs again
14:21:25 <tdurakov> yup
14:21:40 <mriedem> alright, thanks
14:21:53 <mriedem> mdbooth: did you want to mention anything about the image backend series?
14:22:27 <mriedem> starts here https://review.openstack.org/#/c/333242/
14:22:49 <mriedem> my impression is a lot of test re-write to get to some more meat
14:23:03 <mriedem> we can move on
14:23:08 <mriedem> sdague: alex_xu: api meeting highlights?
14:23:31 <sdague> mostly the merge of the user_id policy spec
14:24:05 <sdague> though, we're still figuring out exactly what the code will look like
14:24:11 <mriedem> i also started working on https://review.openstack.org/#/c/347514/ yesterday
14:24:19 <mriedem> and alex_xu has a thread about that here http://lists.openstack.org/pipermail/openstack-dev/2016-August/101402.html
14:24:39 <mriedem> i think we'll need to figure out if we're going to do a novaclient release before https://review.openstack.org/#/c/347514/ lands
14:24:52 <mriedem> because it has some backward incompatible changes in it
14:25:01 <mriedem> at least in it's current form
14:25:07 <sdague> mriedem: that was always the intent right
14:25:14 <mriedem> we talked about it at the midcycle
14:25:18 <mriedem> i'd have to dig up notes to see
14:25:21 <mriedem> we talked about a lot of things...
14:25:22 <sdague> given the way releases work, we can do that even after the patch lands
14:25:27 <mriedem> true
14:25:27 <johnthetubaguy> mriedem: you mean before or after the release freeze for newton?
14:25:38 <mriedem> johnthetubaguy: i meant before that patch lands,
14:25:46 <mriedem> but we can pick the hash so that matters less
14:25:49 <johnthetubaguy> ah, gotcha
14:25:54 <johnthetubaguy> yeah
14:26:00 <mriedem> it might be a 6.0.0 is what i mean
14:26:39 <mriedem> but i think it's in pretty good shape, just need to cleanup functional tests and test it against mitaka
14:26:58 <mriedem> lbeliveau: was there an sriov/pci meeting this week?
14:27:31 <mriedem> will move on
14:27:35 <mriedem> gibi: was there a notifications meeting?
14:28:12 <wznoinsk> mriedem: sriov/pci was skipped this week
14:28:17 <mriedem> ok
14:28:39 <mriedem> #topic stuck reviews
14:28:46 <mriedem> https://review.openstack.org/#/c/200870/19, please give your opinion about comment on PS19 (abhishekk)
14:28:55 <mriedem> abhishekk: jaypipes: dansmith: ^
14:29:07 <jaypipes> mriedem: yeah, so...
14:29:10 <lbeliveau> mriedem: yes, but was quick
14:29:16 <dansmith> melwitt is working on another angle at this,
14:29:18 <dansmith> from the RT side
14:29:26 <dansmith> I will reserve comment until I see that
14:29:34 <jaypipes> mriedem: I understand abhishekk and other's concerns on this.
14:29:39 <dansmith> but I'm definitely not okay with the one that's proposed,
14:29:40 <dansmith> and also don't think it's stuck
14:29:59 <jaypipes> mriedem: however, like dansmith I don't like the proposed solution.
14:30:13 <jaypipes> dansmith: I'm curious, what is melwitt's proposed solution involving the RT?
14:30:26 <mriedem> i haven't read into it so don't know the scope of the problem, but it sounded like 'resource providers fixes this, but that's not ready, and this bug has been open for 2+ years'
14:30:36 <abhishekk> jaypipes: like you suggested I will send the mail to ML
14:30:42 <dansmith> jaypipes: just not adding disk to the total we report as used if the instance is volume-backed, like I suggested in one of my comments
14:30:52 <dansmith> jaypipes: i.e. instead of harming the stored data about instances, just changing what is reported
14:30:56 <jaypipes> mriedem: that is a good summary, yes.
14:31:10 <dansmith> mriedem: N+ years.. since the beginning of volume-backed instances.. nothing new
14:31:28 <johnthetubaguy> dansmith: that doesn't fix the scheduler filers I guess?
14:31:35 <jaypipes> dansmith: you mean in the compute node's local_gb and local_gb_used fields, right?
14:31:41 <dansmith> jaypipes: yeah
14:31:45 <johnthetubaguy> dansmith: or at least, we need to do RT and when passing to scheduler I guess
14:31:46 <jaypipes> johnthetubaguy: it would fix those, yes.
14:31:58 <dansmith> johnthetubaguy: right, fix what we report that the scheduler users
14:31:59 <jaypipes> johnthetubaguy: since the scheduler goes from the compute node objects.
14:32:06 <johnthetubaguy> jaypipes: but it would request 50 GB from the scheduler, when it actually needs 0 GB?
14:32:27 <johnthetubaguy> agreed the reporting of used would be better, so the scheduler has the correct current state, if we fix the RT
14:32:29 <dansmith> johnthetubaguy: the current patch changes what we request, I'd rather change what we report
14:32:48 <dansmith> because what we report is a point in time, what we request exists for the lifetime of the instance
14:32:51 <johnthetubaguy> I just think we should do both, (although not the way that patch does it)
14:33:08 <dansmith> why both? that does't help
14:33:20 <johnthetubaguy> so agreed about reporting the usage
14:33:22 <jaypipes> dansmith: but in the boot from volume case, the requested disk_gb should actually be 0, no?
14:33:26 <alaski> just changing the rt means false negatives from the scheduler
14:33:31 <johnthetubaguy> jaypipes: right, thats the bit
14:33:55 <johnthetubaguy> for when you have a cloud with both bfv and non-bfv living next to each other
14:34:26 <dansmith> I'm missing something
14:34:43 <jaypipes> johnthetubaguy: right, and the alternative is essentially to create two different flavors, one for bfv cases and the other, with the increased disk_gb request, for non-bfv cases, right?
14:35:08 <johnthetubaguy> jaypipes: well, thats related to that spec we didn't get merged about having flavors that say BFV only
14:35:24 <alaski> dansmith: the request to the scheduler needs to have disk_gb = 0 or it may filter out computes that can host a BFV instance
14:35:27 <johnthetubaguy> dansmith: so the request to the scheduler, current it says 50GB rather than 0GB
14:35:27 <dansmith> there's been a feature requested for a while that we restrict the size of a root volume to what the flavor says you can have
14:35:39 <dansmith> and if we destroy the data we store about the flavor booted, we can't do that
14:35:55 <jaypipes> dansmith: if I boot a flavor that has 50GB local_gb in the request (spec), but use a boot-from-volume operation, that 50GB should be 0GB.
14:36:00 <dansmith> alaski: I see
14:36:08 <dansmith> alaski: is that in the reqspec though?
14:36:21 <alaski> it is, but it's put there from the flavor
14:36:37 <alaski> if the conversion can happen there that would work
14:36:42 <johnthetubaguy> yeah, needs to check for the bfv case
14:37:08 <dansmith> what is requested is zero, but that's not related to the flavor from which it was booted, which might have further requirements
14:37:22 <dansmith> like, how big of a volume it creates or allows, etc
14:37:23 <jaypipes> guh, we should just use containers and all our problems would go away. ;P
14:37:35 <edleafe> jaypipes: or rewrite in Go
14:37:39 * cdent gives jaypipes a cookie
14:38:19 <alaski> dansmith: yeah, that would work. just need that and the proper rt reporting
14:38:21 <jaypipes> dansmith: what is requested (in the request spec) is the *flavor's* local_gb, though, which if you boot-from-volume, should actually be ignored since the boot-from-volume case doesn't consume that space on disk.
14:38:39 <dansmith> jaypipes: currently, right
14:38:56 <dansmith> jaypipes: but I'm saying the reqspec _should_ be the things we're asking the scheduler to find for us,
14:38:59 <jaypipes> dansmith: so I agree with johnthetubaguy that we need to fix both the request spec and the usage reporting in the RT.
14:39:03 <dansmith> which in the bfv case should be zero
14:39:18 <jaypipes> dansmith: agreed.
14:39:30 <dansmith> but storing the flavor on the instance with a zeroed out disk doesn't make sense to me
14:39:40 <jaypipes> dansmith: why not?
14:39:47 <dansmith> jaypipes: this is the thing you're -2d for right?
14:40:09 <jaypipes> yes, but I -2'd it because in the resource providers world, all this accounting changes dramatically.
14:40:42 <johnthetubaguy> dansmith: FWIW, I hate that too, I just didn't see this alternative till after you pointed it out
14:40:49 <jaypipes> dansmith: because in the r-p world, there simply won't be a requested amount of DISK_GB resources.
14:40:57 <dansmith> jaypipes: right
14:41:25 <jaypipes> dansmith: a non-existing record in the request in the r-p world is different from a request for 0 amount of local_gb, that's all I mean..
14:41:39 <dansmith> when we create a volume for a nfv request, don't we use the flavor size to create the volume?
14:41:51 <jaypipes> dansmith: lol, bfv, not nfv. :)
14:41:58 <dansmith> hah
14:42:05 <dansmith> when we create a volume for a bfv request, don't we use the flavor size to create the volume?
14:42:09 <alaski> we don't use the flavor size at all in bfv
14:42:10 <jaypipes> dansmith: and no, I don't believe we use the flavor size.
14:42:18 <dansmith> what size do we use?
14:42:21 <mriedem> the size is passed in on the block_device_mapping
14:42:23 <johnthetubaguy> so I think the request spec conversion just ensures 0GB, and the RT reports 0GB usage when its a BFV thingy, isn't that what we want here? I like not hacking the stored flavor, if possible
14:42:26 <alaski> it's passed in as part of the request
14:42:35 <johnthetubaguy> dansmith: we optionally use the flavor size I thought
14:42:41 <johnthetubaguy> like if you don't give a size
14:42:43 <alaski> root_gb makes zero sense in bfv
14:42:43 <dansmith> johnthetubaguy: yeah, I thought so
14:43:01 <johnthetubaguy> I mean I hate it, I just thought thats what we did
14:43:09 <dansmith> alaski: unless you use it to prevent a user from booting a big root disk from a tiny flavor,
14:43:13 <dansmith> which is a request we've had outstanding for a while
14:43:24 <dansmith> alaski: i.e. don't boot an m1.tiny with a 25T root disk volume
14:43:35 <alaski> I disagree with it for bfv though
14:43:45 <alaski> but we can take that offline
14:44:20 <dansmith> I disagree with bfv
14:44:22 <dansmith> in general
14:44:29 <alaski> +1
14:44:54 <jaypipes> so, a decision needs to be made in the case of abhishekk's patch. I think I'd be OK letting this patch in -- possibly with an addition from melwitt around the RT accounting of things (if needed). And putting a giant TODO(jaypipes): Remove all of this in r-p world. To indicate it will all be ripped out when resource providers comes around.
14:45:04 <johnthetubaguy> well I disagree with shared storage and bfv being a thing, we should have one, but that ship sailed
14:45:07 <dansmith> why do that though?
14:45:18 <dansmith> we'll end up with some instances with different data for the flavor
14:45:21 <dansmith> for like six months,
14:45:26 <dansmith> and then we merge the real fix
14:45:32 <dansmith> this has been this way for YEARS
14:45:34 <johnthetubaguy> so we don't need to persisit it
14:45:35 <mriedem> i thought the agreement was (1) fix request spec and (2) fix RT
14:45:49 <johnthetubaguy> we could just convert it in request spec and RT, for the short term
14:46:41 <mriedem> i'm not seeing in the compute api where we ues the flavor size for a volume bdm
14:46:43 <jaypipes> dansmith: right, that's what we're saying. fix the request spec and fix the RT to report the compute_node's usage "properly" when a BFV instance is on it (i.e. don't use flavor.root_gb in the usage calcs on the RT for BFV instances_)
14:46:53 <jaypipes> dansmith: and do NOT change the stored flavor.root_gb value.
14:47:01 <mriedem> i even see
14:47:01 <alaski> mriedem: me neither
14:47:01 <dansmith> mriedem: if we can just convert it in the reqspec then I'm cool with that, but if that ends up storing zero disk in the flavor I'm unhappy aboutthat
14:47:02 <mriedem> # Target disk is a volume. Don't check flavor disk size because it
14:47:02 <mriedem> # doesn't make sense, and check min_disk against the volume size.
14:47:12 <dansmith> jaypipes: if we can do that then that's fine
14:47:37 <mriedem> i only see flavor size used for ephemeral and swap bdms
14:48:17 <jaypipes> mriedem: well, if that's the case, we only need to fix the RT.
14:48:25 <mriedem> BUT
14:48:28 <mriedem> this is bdm code we're talking about
14:48:37 <jaypipes> oh fuck.
14:48:40 <mriedem> so there is probably an OR or a default value somewhere
14:48:41 <jaypipes> never mind then ;)
14:49:04 <mriedem> we could, you know, just actually test the gd scenario and see what happens :)
14:49:55 <mriedem> bingo
14:49:56 <mriedem> def _volume_size(instance_type, bdm):
14:49:56 <mriedem> size = bdm.get('volume_size')
14:49:56 <mriedem> # NOTE (ndipanov): inherit flavor size only for swap and ephemeral
14:50:40 <mriedem> but let's move on, sounds like there is a path forward,
14:50:50 <abhishekk> hi all, could you please add your opinion on the patch as a comment, it will be helpful
14:50:56 <mriedem> with maybe an open question about flavor inherited size for bfv, maybe mdbooth or ftersin knows, but we could also test it
14:51:34 <mriedem> #topic open discussion
14:51:40 <mriedem> there wasn't anything on the agenda
14:51:43 <mriedem> does anyone have anything?
14:52:19 <mriedem> ok let's wrap up then
14:52:22 <mriedem> thanks everyone
14:52:25 <mriedem> #endmeeting