21:00:44 <mriedem> #startmeeting nova
21:00:45 <openstack> Meeting started Thu Jan  7 21:00:44 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:49 <openstack> The meeting name has been set to 'nova'
21:00:51 <tonyb> o/
21:00:57 <claudiub> o/
21:00:58 <alaski> o/
21:00:58 <cburgess> o/
21:01:03 <cdent> o/
21:01:05 <dansmith> o/
21:01:16 <rlrossit> o/
21:01:20 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/Nova
21:01:22 <russellb> o/
21:01:27 <edleafe> \o
21:01:35 <macsz> \\//,
21:01:38 <scottda> hi
21:01:38 <auggy> o/~
21:01:40 <mriedem> there are a few things so let's get started
21:01:43 <mriedem> #topic release status
21:01:48 <sdague> o/
21:01:55 <mriedem> Jan 21: Nova non-priority feature freeze
21:01:56 <mriedem> Jan 19-21: mitaka-2
21:02:02 <bauzas> \o
21:02:11 <mriedem> so 2 weeks
21:02:25 <mriedem> any questions about that?
21:02:41 <mriedem> #topic regular reminders
21:02:48 <mriedem> review priorities are here https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
21:02:53 <mriedem> #link review priorities https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
21:03:14 <mriedem> #topic bugs
21:03:25 <mriedem> gate has been okish except for the py34 job
21:03:29 <mriedem> super flaky with mox lately
21:03:37 <mriedem> hence an effort to cleanup mox usage in tests
21:03:39 <mriedem> starting with https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-mox
21:03:43 <mriedem> #link remove-mox cleanup https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/remove-mox
21:04:07 <mriedem> aside from that, we've been trying to keep on top of known racy py34 failures with the blacklist in tree
21:04:18 <bauzas> that's a large story
21:04:25 <mriedem> in here
21:04:25 <mriedem> https://github.com/openstack/nova/blob/master/tests-py3.txt
21:04:37 <sdague> yeh, I'd like to turn some of the fakes into real fixtures during the process. But if we can hack away at known races with mox3 it might help.
21:04:39 <mriedem> yeah, so the first step is an easy one, which is replacing self.stubs.Set with self.stub_out
21:04:53 <mriedem> which uses fixtures
21:05:05 <mriedem> else let's blacklist known bad things to stop any bleeding
21:05:15 <sdague> right, it's super straight forward, it's just a lot of patches
21:05:16 <bauzas> can I actually ask why we shouldn't put non-voting py34 until the series merges ?
21:05:26 <sdague> bauzas: so... 2017?
21:05:33 <bauzas> I dunno
21:05:38 <mriedem> it came up
21:05:44 <bauzas> but it seems we're hitting more races now
21:05:52 <dansmith> sdague: wasn't that originally your desire? to make it non-voting?
21:05:53 <sdague> git grep 'self.stubs.Set' | wc -l
21:05:53 <sdague> 2003
21:06:01 <sdague> dansmith: take it off the gate
21:06:13 <dansmith> so only voting on check you mean?
21:06:17 <sdague> yes
21:06:22 <dansmith> okay
21:06:23 <bauzas> that sounds fair
21:06:42 <sdague> except, that might be tricky because of the way the job def is
21:06:53 <mriedem> it's part of a group isn't it?
21:06:55 <mriedem> like python-jobs?
21:06:58 <sdague> yeh
21:06:58 <bauzas> oh
21:07:11 <sdague> anyway, lets see if transition off mox helps
21:07:12 <mriedem> you'd have to not use the group i'd thing
21:07:22 <mriedem> yeah, i think the fake image stub thing will help a bit
21:07:26 <mriedem> since it's global and pervasive
21:07:33 <mriedem> it's what the vmware api tests were choking on in the gate all week
21:07:38 <mriedem> moving on
21:07:59 <mriedem> third party ci status
21:08:07 <mriedem> i haven't really been paying attention lately honestly
21:08:18 <mriedem> #link 3rd party ci status http://ci-watch.tintri.com/project?project=nova&time=7+days
21:08:38 <mriedem> ok
21:08:42 <mriedem> onto critical bugs
21:08:46 <mriedem> #topic critical bugs
21:08:55 <mriedem> there is a series for a security bug that starts here https://review.openstack.org/#/c/264812/
21:08:59 <mriedem> #link security bug fix starts here https://review.openstack.org/#/c/264812/
21:09:07 <mriedem> the first patch has a +@
21:09:09 <mriedem> *+2
21:09:21 <mriedem> and there are backports proposed to stable/liberty and kilo already,
21:09:34 <mriedem> but since it's a 3-patch series per branch, i want to make sure master is good before we take them into stable
21:09:43 <mriedem> any other critical bugs to bring up?
21:10:02 <mriedem> moving on
21:10:14 <sdague> that wasn't reviewed before going public?
21:10:20 <mriedem> probably
21:10:29 <sdague> typically those don't go public until they have both +2s good to go
21:10:31 <mriedem> i didn't know how much we just rubber stamp those
21:10:32 <dansmith> I believe it was, but it still gets normal review in gerrit
21:10:50 <dansmith> I was told that the disclosure has to have code available, and code in gerrit == available
21:10:54 <dansmith> not in a build or anything
21:11:12 <dansmith> we wait until it has high confidence of being the right solution before disclosure, which is why we pre-review
21:11:12 <tonyb> It'd be great to get them but blocking for good reassons is fine.
21:11:17 <sdague> ok, when I was part of these in the past we didn't move to gerrit until the approvals were lined up
21:11:49 <dansmith> sdague: sure, but that doesn't mean slam them in with no other eyes
21:11:50 <dansmith> that's all
21:11:53 <sdague> ok
21:12:03 <tjones> mriedem: is the fake image stub thing the same as changing self.set.Stubs to stub_out or is it something else?
21:12:11 <mriedem> tjones: same
21:12:15 <mriedem> the patch is already approved
21:12:29 <tjones> gracias
21:12:30 <mriedem> like 10 min ago though
21:12:38 <mriedem> any more on that security bug?
21:13:02 <mriedem> markus_z had a request for volunteers to be on bug duty https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
21:13:09 <mriedem> there was a ML thread on it also
21:13:28 <mriedem> looks like a rotating 1 week thing
21:13:42 <mriedem> anyway, read on if you're interested
21:13:49 <mriedem> #link bug volunteers for a week https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty
21:14:01 <mriedem> #topic stable branch status
21:14:10 <dansmith> "effed"
21:14:12 <mriedem> heh
21:14:23 <mriedem> yeah so i managed to merge a thing that broke triple-o on stable/liberty last night
21:14:25 <mriedem> but i blame jenkins
21:14:30 <mriedem> among others...
21:14:42 <mriedem> anyway, here are the stable/liberty open reviews https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/liberty,n,z
21:14:47 <mriedem> #link stable/liberty nova reviews https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/liberty,n,z
21:15:01 <mriedem> i'd like to get as much of that flushed through this week so we can release 12.0.1 next week
21:15:07 <mriedem> but that is going to need to wait for the backport of that security fix
21:15:23 <mriedem> i see 3 changes out there that have a +2 but missing the approval
21:15:41 <mriedem> stable/kilo reviews https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo,n,z
21:15:53 <mriedem> i haven't looked at kilo since the break
21:15:58 <mriedem> looks like there are quite a few out there
21:16:16 <mriedem> anything else for stable?
21:16:35 <mriedem> oh yeah, upper-constraints for stable/liberty is having some growing pains, tracked here https://etherpad.openstack.org/p/stable-liberty-constraints-sanity
21:16:43 <sdague> so, I thought kilo was just security fixes at this point, right?
21:16:45 <mriedem> for those that like to make their lives worse
21:16:56 <sdague> I'm surprised that things like https://review.openstack.org/#/c/264795/ are backports
21:17:17 <mriedem> i'd have to check the actual dates
21:17:23 <tonyb> sdague: kilo is security only liberty is more open
21:17:25 <mriedem> i wasn't sure if that's after juno was eol
21:17:55 <sdague> ok, so I think a lot of those kilo backports should probably be nixed given that
21:18:11 <mriedem> yeah maybe
21:18:26 <mriedem> critical impact type bugs which are not necessarily security issues have been given a pass in the past too
21:18:37 <mriedem> like things that impact the gate for example
21:18:46 <sdague> sure, performance tweaks seem to be out of scope though
21:18:47 <mriedem> but yeah, most of that list needs a good scrubbing for sure
21:18:57 <mriedem> well, cern reported that one when they upgraded to kilo
21:19:05 <mriedem> and it's 5 LOC
21:19:48 <mriedem> moving on?
21:20:03 <mriedem> #topic stuck reviews
21:20:05 <bauzas> tbh, cern can disable that if needed
21:20:14 <bauzas> but let's discuss that offline
21:20:23 <mriedem> i posted to the ML on a cells v2 patch that adds the flavors tables to the API DB
21:20:31 <mriedem> #link cells v2 flavors api db ML thread http://lists.openstack.org/pipermail/openstack-dev/2016-January/083518.html
21:20:40 <mriedem> the question is if we should allow those to be soft-deletable
21:20:59 <mriedem> since we've previously said no more soft delete, but it turns out the flavor API can read deleted flavors if you have the id
21:21:04 <mriedem> and you can get the id from an instance get
21:21:18 <mriedem> so i'm torn
21:21:29 <mriedem> we can discuss in the ML through, it's also cross posted to the ops ML
21:21:36 <mriedem> *though
21:21:40 <sdague> but only accidentally until you run a db purge right?
21:21:44 <mriedem> right
21:21:45 <bauzas> do we have kind of permalinks ?
21:21:51 <bauzas> for flavors
21:21:51 <melwitt> back before flavor was stored with the instance, it was how you could still get instance details for an instance whose flavor had since been deleted
21:21:51 <dansmith> not accidentally,
21:21:53 <sdague> it's not like we guaruntee they will be there forever
21:21:53 <dansmith> that's the design
21:21:59 <dansmith> but yes, "until a purge"
21:22:09 <sdague> dansmith: right, not really accidental
21:22:18 <sdague> but there is no contract around their longevity
21:22:18 <dansmith> melwitt: there's no way to get the current data either.. we need to add a thing I think
21:22:25 <dansmith> melwitt: embed the flavor in the instance result
21:22:34 <mriedem> yeah, we could add a microversion to the server get to show the flavor info
21:22:35 <melwitt> dansmith: oh, okay. didn't know that
21:22:36 <sdague> right, we need a new rest api for that
21:22:37 <dansmith> sdague: correct, but it's also a permalink which is the concern
21:22:54 <mriedem> we also have no CLIs to purge the api db (yet)
21:22:56 <edleafe> just add a visble column - don't keep calling them deleted
21:22:59 <mriedem> so this would set precedence
21:23:08 <sdague> dansmith: yeh, our permalinks are a bit less permanent then we'd like
21:23:34 <dansmith> sdague: yep, I'm not saying we shouldn't do it, I'm just explaining why it gives us heartburn
21:23:44 <sdague> honestly, given that we don't have a contract around how long things will stick around there, I feel like saying the answer is 0 is fine
21:23:46 <mriedem> i'd realy like operator input on that one before we move forward,
21:23:47 <dansmith> I think the purge case is a good enough reason to be able to drop it
21:23:57 <mriedem> but it is blocking cells v2 progress so it's kind of urgent
21:24:17 <alaski> I agree that we should drop it, but want to wait for the operator feedback
21:24:18 <dansmith> sdague: if we drop the flavor link in the same rev that we add the flavor dump to the instance, that will help avoid it sticking around any longer
21:24:20 <mriedem> given the guys writing the patch are cern i'm assuming they will provide input at some point
21:24:20 <dansmith> and
21:24:38 <dansmith> this might be a good reason for people to move up a few microversions if losing flavor stuff immediately makes them uncomfortable
21:24:38 <sdague> dansmith: that's an API change, we need a microversion
21:24:49 <sdague> yeh
21:24:49 <dansmith> sdague: we need a microversion for both changes
21:24:56 <sdague> ah, ok
21:24:57 <dansmith> sdague: I'm saying do both the drop and add in the same one,
21:25:09 <dansmith> s/,$//
21:25:15 <mriedem> i'm not sure how we have a microversion for the flavors db model thing in the api db
21:25:17 <sdague> yeh, that seems fine. Is anyone working on the API change?
21:25:28 <mriedem> sdague: no, it came up as an idea in the cells meeting yesterday
21:25:30 <sdague> GET /servers/{id}/flavor
21:25:42 <dansmith> sdague: oh wait
21:25:47 <sdague> and start using that as our permalinks
21:25:49 <dansmith> sdague: that's not what I was thinking, but that's a great idea
21:26:13 <sdague> oh, I though that's what we'd decided at summit, just hadn't gotten around to yet
21:26:14 <dansmith> the thing I hated, was that we'd be returning a wrong permalink because $api
21:26:20 <alaski> mriedem: we don't microversion the flavor migration, but deleted flavors look like purged flavors at that point
21:26:22 <dansmith> but if we did that then we could just say stored permalinks are wrong,
21:26:54 <dansmith> I feel like the link/ref thing returned in something like instance is the link to it right now, not necessarily that you can capture that url forever and expect it to work
21:27:05 <dansmith> so just changing how/where we point the permalink seems totally  fine to me
21:27:39 <sdague> ok, I can help dig on the API side early next week, especially if it will help unblock cells v2 stuff
21:27:42 <edleafe> permalink for some value of perma
21:27:57 <dansmith> edleafe: it's actually not a permalink, it's an "href"
21:27:59 <mriedem> so it sounds like we have a path forward and opinion on what we'd like to do
21:28:02 <dansmith> edleafe: literally a pointer to the flavor
21:28:17 <mriedem> and the api would probably be a dep on the cells v2 change, but we'd have focused review on the spec and change
21:28:34 <mriedem> sdague: dansmith: alaski: please express opinions/etc in the ML thread
21:28:39 <sdague> ok, will do
21:28:45 <mriedem> moving on
21:28:54 <mriedem> #topic open discussion
21:29:10 <mriedem> #link midcycle details https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprint
21:29:22 <mriedem> #link ideas for midcycle https://etherpad.openstack.org/p/mitaka-nova-midcycle
21:29:37 <dansmith> I have an idea for the midcycle
21:29:37 <mriedem> it sounds like the cinder midcycle is happening in the US at the exact same time
21:29:49 <anteaya> so far the neutron folks attending are armax and carl_baldwin
21:29:49 <dansmith> "tell rob__ to cut it out"
21:29:55 <anteaya> mriedem: and keystone
21:30:19 <mriedem> anteaya: keystone huh
21:30:22 <_gryf> dansmith, that the same thing…
21:30:37 <mriedem> i guess the only keystone related stuff i know of going on are the keystoneauth changes
21:30:44 <stevemar> mriedem: darn those keystone guys
21:30:46 <mriedem> and whatever project/service catalog work sdague is doing
21:30:55 <anteaya> #link https://wiki.openstack.org/wiki/Sprints/KeystoneMitakaSprint
21:31:06 <anteaya> keystone is also happening at the same time
21:31:08 <mriedem> multiattach is a major thing for cinder
21:31:18 <mriedem> so it sounds like some of the cinder people want to do a hangout at some point during the week
21:31:34 <mriedem> problem with the multiattach stuff is it's not a priority and our meetup is the week after non-priority FF
21:31:39 <anteaya> mriedem: sorry I changed thoughts without indicating I was changing
21:31:58 <mriedem> that's fine, just trying to figure out what the cross-project impacts are
21:32:09 <anteaya> mriedem: yup
21:32:10 <mriedem> i don't know what hot button things neutron people care about for nova in mitaka
21:32:30 <mriedem> anyway, if nothing else on the midcycle, moving on
21:32:34 <anteaya> okay if there are any I'll encourage them to communicate
21:32:40 <mriedem> thanks
21:32:48 <mriedem> #link TC review on containers in nova's mission https://review.openstack.org/#/c/256440/
21:32:59 <mriedem> ^ has a healthy dose of -1 on it
21:33:15 <sdague> unrelated to that, has there been any motion on privsep?
21:33:16 <mriedem> so if you have an opinion, i guess state it there
21:33:30 <mriedem> sdague: i heard someone in cinder say this week that it would be N at the earliest
21:33:36 <sdague> because osbrick and osvif are both in a weird place without it
21:33:41 <tonyb> sdague: the os-brick stuff is in progress
21:33:57 <tonyb> sdague: I think that there is enough privsep in place to enable os-vif
21:34:01 <sdague> mriedem: really?
21:34:01 <mriedem> sdague: yeah, os-brick is looking to move some more common lvm stuff out of nova and cinder into os-brick but it needs more rootwrap type stuff with it
21:34:23 <mriedem> only what i heard in the cinder meeting this week
21:34:26 <mriedem> i don't know the details
21:34:38 <tonyb> FWIW gus will be at the MC
21:34:51 <dansmith> sheesh
21:35:01 <mriedem> dansmith: plan on talking about a lot of things
21:35:01 <dansmith> how far away do we have to have the midcycle to get the aussies to not come?
21:35:07 <sdague> ok, that's something we should reset on. Because we've crippled upgrade
21:35:33 <mriedem> sdague: something for the oslo meeting?
21:35:35 <dansmith> sdague: wait, what?
21:35:36 <tonyb> dansmith: keep trying
21:35:41 <dansmith> tonyb: :P <3
21:36:09 <sdague> every new thing that goes into osbrick that requires filter adjustment means lock step nova/cinder/osbrick upgrade
21:36:19 <dansmith> ah
21:36:36 <mriedem> i'm not aware of anything new really in that regard yet for mitaka
21:36:40 <tonyb> can we do the provsep conversion in nova/cinder and then move it?
21:36:42 <mriedem> but i haven't checked
21:36:59 <sdague> tonyb: that's what I was hoping the plan was going to be
21:37:08 <mriedem> so is anyone stepping up here to push on this?
21:37:17 <mriedem> push it real good?
21:37:24 <tonyb> sdague: then I think we should try to make that the plan
21:37:26 <sdague> mriedem: who is point on os-brick?
21:37:29 <mriedem> hemna:
21:37:40 * mriedem assumes
21:37:54 <scottda> mriedem: yes, it would be hemna
21:38:04 <hemna> wha?
21:38:08 <sdague> ok, I'll poke a bit
21:38:15 <mriedem> #action sdague to poke hemna
21:38:26 <mriedem> (about os-brick and privsep)
21:38:30 <hemna> oh privsep
21:38:42 <hemna> so, it looks like angus has put a small WIP patch up against os-brick
21:38:53 <hemna> but honestly, it seems a long ways away
21:39:19 <hemna> https://review.openstack.org/#/c/258252/
21:39:23 <sdague> right, so I think that os-brick has to be in filter freeze until that is in
21:39:25 <hemna> that one and it only covers a small piece
21:39:37 <tonyb> hemna: but can we say no new filters in os-brick yet?
21:39:38 <mriedem> #link WIP os-brick patch for privsep integration https://review.openstack.org/#/c/258252/
21:39:39 <sdague> https://review.openstack.org/#/c/247372/5 ends up forcing another coupling
21:39:49 <hemna> tonyb, currently we don't
21:40:10 <hemna> and the filters that are defined in os-brick aren't actually used anywhere
21:40:11 <hemna> :(
21:40:24 <hemna> we are stuck w/ copy/paste into nova and cinder's filters
21:40:34 <hemna> sadness
21:41:22 <hemna> I'm unfamiliar with a filters freeze
21:41:36 <hemna> I presume we mean rootwrap filters in the case.
21:41:37 <sdague> ok, we can probably take this offline
21:41:39 <hemna> and when is that date ?
21:41:40 <hemna> ok
21:41:48 <hemna> sdague, ping me in cinder channel whenever
21:42:00 <sdague> hemna: yeh, the point is any rootwrap filter changes end up coupling upgrades
21:42:18 <sdague> which we really really don't want to be doing
21:42:26 <hemna> sdague, yup.  totally agree
21:42:37 <hemna> I'll see if I can ping angus and help his efforts
21:42:47 <sdague> hemna: thanks!
21:42:53 <hemna> np
21:43:00 <mriedem> ok, last thing in open discussion
21:43:05 <mriedem> rlrossit has a specless bp https://blueprints.launchpad.net/nova/+spec/rm-object-dict-compat
21:43:11 <dansmith> let's do it
21:43:12 <mriedem> to remove the dict compat mixin from nova objects
21:43:17 <mriedem> yeah, this is really just a formality
21:43:18 <dansmith> (since he already is)
21:43:20 <dansmith> (doing it)
21:43:25 <cdent> +1
21:43:25 <alaski> +1
21:43:36 <bauzas> +1
21:43:38 <mriedem> sounds like we're all happy with this
21:43:41 <mriedem> dansmith: want to approve?
21:43:41 <bauzas> (who else?)
21:43:44 <rlrossit> woo
21:43:50 <dansmith> mriedem: I want to approve that so hard
21:43:57 <mriedem> can i watch from the corner?
21:44:12 <mriedem> alright,
21:44:16 <mriedem> anything else for open discussion?
21:44:29 <dansmith> heh
21:44:36 <mriedem> going once
21:44:41 <dansmith> I just blew up rlrossit's inbox
21:44:41 <mriedem> twice
21:44:49 <dansmith> because launchpad is awesome like that
21:44:53 <rlrossit> you blew up more than just that ;)
21:45:03 <mriedem> geez you weirdos
21:45:07 <mriedem> alright thanks everyone
21:45:08 <mriedem> #endmeeting