14:01:21 <sdague> #startmeeting nova
14:01:21 <bauzas> bot on vacation ?
14:01:22 <openstack> Meeting started Thu Mar  5 14:01:21 2015 UTC and is due to finish in 60 minutes.  The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:26 <openstack> The meeting name has been set to 'nova'
14:01:30 <bauzas> ah
14:01:36 <alaski> o/
14:01:45 <ndipanov> o/
14:01:48 <sdague> ok, it might be a light meeting, mikal asked me to chair because he couldn't make it
14:02:06 <sdague> #link https://wiki.openstack.org/wiki/Meetings/Nova - today's agenda
14:02:06 <dims> o/
14:02:10 <edleafe-> o/
14:02:14 <lxsli> o/
14:02:22 <sdague> #topic Kilo Release Status
14:02:34 * bauzas waves again
14:02:38 <sdague> #info https://wiki.openstack.org/wiki/FeatureProposalFreeze has now hit
14:03:16 <markus_z> o/
14:03:16 <bauzas> can we still accept changes that are not explicitely linked to bugs in the commit msg ?
14:03:21 <sdague> so... basically patches need to be up now for features for consideration. mikal has a note in the agenda to remember to mark blueprints as NeedsCodeReview
14:03:23 * alex_xu follow the wave
14:03:38 <sdague> bauzas: yes, I think so still at this point
14:03:57 <sdague> but, I'll defer to mikal or john for sure on that
14:04:15 <bauzas> sdague: ok because I understand the rule for patches implementing blueprints, I was just wondering for those which are actually saying nothing, neither BPs nor bugs
14:04:58 <bauzas> last point, what about bugs which are marked as wishlist ?
14:04:59 <bauzas> :)
14:05:02 * lxsli watches bauzas file all the serial numbers off his patches
14:05:11 <sdague> so, that's a good point, we should get mikal and john to set the ground rules for that
14:05:22 <ndipanov> for wishlist?
14:05:26 <sdague> #action sdague to poke mikal about what's still approvable
14:05:31 <ndipanov> ok
14:05:36 <sdague> wishlist bugs are almost always features
14:05:41 <sdague> that's what we use it for
14:05:44 <ndipanov> right
14:05:50 <bauzas> sdague: agreed, hence my question
14:06:13 <bauzas> wishlist bugs are feature slash bug
14:06:30 <bauzas> so we can see either the empty half of the bottle or the contrary
14:06:48 <sdague> yeh, I don't want to mispeak on this one, my suggestion is take it to the list
14:07:05 <sdague> ok, lets move on to priorities
14:07:09 <bauzas> ack
14:07:29 <sdague> #topic Kilo Priorities
14:07:39 <sdague> #link https://etherpad.openstack.org/p/kilo-nova-priorities
14:07:51 <sdague> #link https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:08:07 <sdague> anyone have priority items that seem to be stalling on reviews?
14:08:39 * sdague needs to remember to list his function test patch stack under the functional test item there
14:09:08 <sdague> going once? going twice?
14:09:14 <alaski> cells could always use reviews, but there have been some recently so it's not really stalled
14:09:16 <bauzas> as we're close to FF, can we just make sure that cores are reading that etherpad quick on a daily basis ?
14:09:25 <bauzas> the same as for alaski
14:09:44 <bauzas> FF is in 2 weeks IIRC
14:09:48 <ndipanov> but there are no patches on that etherpad
14:09:59 <sdague> ndipanov: the patches are on - https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:10:00 <bauzas> ndipanov: https://etherpad.openstack.org/p/kilo-nova-priorities-tracking
14:10:41 <sdague> I wonder if there is a small enough number of topics to build a dashboard for these?
14:10:51 <ndipanov> nice
14:10:54 <sdague> which I would find easier than the etherpad
14:10:56 <ndipanov> will look at those
14:11:04 <sdague> ndipanov awesome, thanks
14:11:33 <sdague> #action sdague to try to figure out if we can dashboard the priority reviews by topic or commit message
14:11:56 <sdague> ok, anything else on priorities?
14:12:02 <bauzas> sdague: etherpads can't be scrubbed
14:12:08 <sdague> bauzas: ?
14:12:14 <bauzas> sdague: so we need to set the priority list on wiki
14:12:33 <bauzas> sdague: I mean that we can't get the list off the etherpad by fetching it
14:12:50 <sdague> bauzas: we should be able to
14:12:56 <bauzas> sdague: but that's details, let's discuss it offline
14:13:01 <sdague> yep, sounds good
14:13:11 <sdague> ok, next topic is slightly cryptic.
14:13:17 <bauzas> sdague: I already have a script for scrubbing a wikipage and generating a dashboard
14:13:20 <bauzas> (btw.)
14:13:22 <sdague> #topic EC2 deprecation
14:13:38 <sdague> #info Mikal has had a conversation with Thierry and Tom Fifield and believes he understands the way forward
14:13:49 <sdague> I don't actually know what that way is
14:14:02 <sdague> but hopefully that does mean we're still deprecating EC2 in kilo
14:14:16 <sdague> will need mikal back around to share that info
14:14:21 <edleafe> First Fermat, now mikal...
14:14:30 <sdague> edleafe: :)
14:14:32 <markus_z> hehe
14:14:34 <bauzas> s/scrub/scrap (for the records)
14:14:36 <sdague> #topic Gate status
14:14:53 <sdague> #link http://status.openstack.org/elastic-recheck/gate.html
14:15:24 <sdague> so... everything was a mess earlier in the week, mostly due to floating ip leakage in hp cloud, and rax rebooting the world for xen vulnerabilities
14:15:44 <sdague> however, it looks like both of those are addressed now, and we should be back to full capacity
14:16:06 <bauzas> some weird behaviour is happening now with patch series complaining that dependencies can't be merged while they *are* mergeable, sdague do you know about it ?
14:16:46 <sdague> bauzas: "This change depends on a change that failed to merge."?
14:16:57 <bauzas> sdague: exactly
14:17:15 <sdague> yeh, that's apparently a bug in 'Depends-On' implementation
14:17:18 <bauzas> I mean that's a question I should ask to infra
14:17:28 <sdague> there is a storyboard bit for it
14:17:32 <bauzas> but in case you were having some secret info
14:17:37 <bauzas> oh ok
14:17:49 <sdague> #link https://storyboard.openstack.org/#!/story/2000189
14:18:02 <bauzas> sdague: awesome, thanks
14:18:13 <sdague> probably worth adding some additional reference reviews there
14:18:29 <sdague> infra is putting zuul into debug mode to figure out what's going on
14:18:49 <bauzas> sure, will do
14:19:15 <dansmith> sdague: I know we've missed it, but I did talk to mikal about the deprecation thing and the results of that meeting
14:19:30 <sdague> #info Depends-On support has caused some bugs with "This change depends on a change that failed to merge." please add affected reviews https://storyboard.openstack.org/#!/story/2000189
14:19:41 <sdague> dansmith: ok, let's jump back there in a sec
14:19:46 <sdague> anything else on gate?
14:20:15 <sdague> #topic EC2 Deprecation (redux)
14:20:24 <sdague> dansmith: ok, want to fill us in?
14:20:50 <dansmith> I think he's planning a mail or a comment on that patch or something, but it sounds like the bottom line is: we can't use the word deprecation
14:20:57 <dansmith> for whatever "can't" means in this case
14:21:09 <dansmith> I think he thinks that deprecation is the right word, and I surely do
14:21:26 <dansmith> I don't think the _act_ of deprecating is the problem at all at this point
14:21:35 <dansmith> but rather just a quibble over the term
14:22:01 <sdague> ok, will eagerly await his mail on that
14:22:11 <dansmith> we should remind him
14:22:14 <dansmith> because this was like two days ago...
14:22:17 <sdague> yeh
14:22:31 <sdague> I think he's off on some camping trip with his kids school
14:22:41 <dansmith> ah
14:22:42 <sdague> ok, moving on
14:22:48 <sdague> #topic Bugs
14:23:15 <sdague> the trivial bug list remains pretty handy
14:24:13 * mriedem-away lurks
14:24:18 <sdague> anyone else have some hot bugs that they'd like to raise? (as we've got a bit of time)
14:24:53 <sdague> we can cycle back in open discussion if needed
14:25:00 <sdague> #topic Stuck Reviews
14:25:15 <sdague> #link https://review.openstack.org/#/c/159759/
14:25:18 <mriedem-away> just in time
14:25:20 <mriedem-away> i added that one
14:25:29 <alex_xu> yes
14:25:31 <mriedem-away> could use a few more eyes
14:25:58 <mriedem-away> basically, removing the @requires_admin_context for service_create in the db api
14:26:00 <bauzas> yeah we're removing a safety belt
14:26:04 <mriedem-away> there are no API entry points to service create
14:26:30 <mriedem-away> so i don't really see a need to remove the decorator in the db api, regardless of the fact you can just elevate your context in code or get the global admin context to satisfy the decorator
14:26:35 <alaski> because there are no API entry points I think it's fine, though I understand the concern
14:26:47 <sdague> yeh, honestly, I'd rather remove it
14:27:10 <sdague> because it seems like a really weird layer violation now that those permissions checking are at a higher level
14:27:30 * mdbooth looked at that and also wasn't in favour of removal, btw
14:27:33 <mriedem-away> i'm not vehemently opposed or anything, just wanted to bring it up for broader discussion
14:27:41 <mdbooth> It's a belt a braces thing, and it's not as if the check is expensive
14:27:48 <dansmith> but it's useless
14:27:51 <mdbooth> It doesn't call out to anything, for eg
14:28:03 <sdague> right, it's both useless, because it's trivially bypassable in code
14:28:04 <dansmith> it's checking a boolean in a dict passed over an unsecured channel
14:28:06 <alaski> checks like that also lead to using elevated contexts more than necessary
14:28:27 <sdague> and it's inconsistent because if it ever does get used, you can get conflicting checks
14:28:53 <sdague> we've decided to do permission checking at a different layer, we should do that, and remove it from this layer
14:29:07 <mriedem-away> works for me
14:29:15 <dims> mriedem-away: do we need a owner for this "Critical" bug? https://bugs.launchpad.net/nova/+bug/1323658
14:29:16 <openstack> Launchpad bug 1323658 in OpenStack Compute (nova) "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed]
14:29:51 <mriedem> dims: probably not critical anymore, it was a gate issue a long time ago
14:30:02 <dims> mriedem: ack will lower the priority
14:30:14 <mriedem> oh nvm
14:30:17 <mriedem> jogo recently upped it
14:30:18 <sdague> ok, so I'm going to +2 https://review.openstack.org/#/c/159759/
14:30:37 <dims> gah! flipped it back
14:30:39 <sdague> mriedem: you happy enough to flip votes o nthat?
14:30:52 <mriedem> sdague: just did
14:30:56 <sdague> mriedem: cool
14:30:57 <mriedem> i'll let alaski +W if he wants
14:31:06 <sdague> sounds good
14:31:08 <alex_xu> thanks all, cool for get aggrement
14:31:10 <bauzas> did I too for those who're interested: )
14:31:17 <ndipanov> sdague, dansmith https://review.openstack.org/#/c/155833/
14:31:29 <alaski> mriedem: sdague just did
14:31:31 <sdague> ok, so dims's bug
14:31:36 <dansmith> ndipanov: yeah, I saw that, was going to ask after the meeting what the deal is
14:31:56 <ndipanov> dansmith, removed it
14:32:02 <ndipanov> but see comment on previous patch
14:32:18 <ndipanov> that has already merged
14:32:20 <dansmith> ndipanov: link? it's merged now so it's hard to see what it was
14:32:51 <ndipanov> dansmith, https://review.openstack.org/#/c/155832/8
14:32:55 <dansmith> ndipanov: anyway, this isn't stuck I don't think so we should let the meeting continue
14:32:56 <dansmith> thanks
14:33:30 <sdague> ok, so are there other stuck reviews
14:33:38 <sdague> then we can discussion dims bug in open discussion
14:33:41 <mriedem> probably this one https://review.openstack.org/#/c/159890/
14:33:51 <mriedem> now that i see a -2 on it
14:34:14 <dansmith> whoa
14:34:21 <sdague> right, the evacuate saving through patch
14:34:41 <mriedem> nice d&d ref
14:35:04 <mriedem> i'm just reading through latest comments now so we could probably move on too
14:35:26 <sdague> ok, so I was +2 on that as a workaround because it seemed like we wanted to fix evacuate for reals in liberty
14:35:45 <sdague> but I guess we'll just take that to the review or the mailing list
14:35:51 <sdague> other stuff things?
14:35:56 <sdague> stuck things?
14:36:14 <sdague> #topic Open Discussion
14:36:15 <mdbooth> sdague: I've been -1 all along because it requires the user to manually, pre-emptively enable an obtuse knob for something which might lose their data.
14:36:45 <dims> back to this "Critical" bug? https://bugs.launchpad.net/nova/+bug/1323658
14:36:46 <openstack> Launchpad bug 1323658 in OpenStack Compute (nova) "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed]
14:36:46 <mdbooth> There are a couple of proposed fixes in the comments.
14:36:54 <sdague> dims: yep
14:37:07 <sdague> so critical bug, would be good to have an owner on that to dive on it
14:37:21 <sdague> any volunteers?
14:37:59 * dims doesn't know enough to own it
14:38:20 <sdague> we should probably figure out if we can get a smaller reproduce case.
14:38:45 <mriedem> mestery said he had reproduced locally in the bug comments
14:39:03 <mriedem> as i recall when this showed up we had a lot of random ssh failures (the other #1 gate bug for a long time)
14:39:08 <mriedem> so this got lost in the mix
14:39:36 <sdague> yeh
14:40:37 <sdague> so I think what we actually need is test which reproduces it more often, which might be as simple as a modification of the tempest test to just do this a lot more
14:40:58 <sdague> or in a tight loop
14:41:33 <mriedem> there are multiple comments that it's related to reboot
14:41:40 <mriedem> or shows up more often in reboot scenarios
14:41:58 <sdague> ok, well lets take actually sorting out the bug to an offline state
14:42:01 <mriedem> there have been long known issues with soft reboot and how we don't test it in tempest, because we can't tell when we actually did a soft reboot and didn't just fallback to hard reboot
14:42:13 <mriedem> alright
14:42:15 <sdague> mriedem: are you up for building a summary comment at the end of the bug for what's in there and been tried?
14:42:36 <mriedem> probably not this second, my day hasn't really started yet :)
14:42:39 <sdague> because it's a rambling conversation in the bug at this point, and it's pretty hard to follow
14:42:58 <sdague> mriedem: sure, but after coffee :)
14:43:11 <mriedem> i'll see what i can do
14:43:14 <sdague> thanks
14:43:35 <sdague> #info need bug owner for https://bugs.launchpad.net/nova/+bug/1323658
14:43:36 <openstack> Launchpad bug 1323658 in OpenStack Compute (nova) "Nova resize/restart results in guest ending up in inconsistent state with Neutron" [Critical,Confirmed]
14:44:00 <sdague> #action mriedem will attempt to summarize the 46 comments so far to level set on the bug
14:44:12 <sdague> ok, any other open discussion topics?
14:44:14 <dims> :) yay mriedem
14:45:28 <sdague> alex_xu: I actually had one for you, it seems weird that we've got 2 sets of tests in tree for api samples, one for v2 one for v3
14:45:46 <sdague> it seems like we should only have 1, as the APIs should all be the same nwo
14:45:57 <sdague> redrobot: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:rm_v3_paste,n,z
14:46:04 <alex_xu> sdague: yes, but we didn't merge them yet
14:46:39 <sdague> alex_xu: ok, lets talk after the meeting, I had another idea about it
14:46:46 <alex_xu> sdague: I saw Gman is working on it
14:46:52 <alex_xu> sdague: ok
14:47:09 <sdague> any other open discussion?
14:47:28 <sdague> if not, we can shut down the meeting and get back to real work
14:47:37 <sdague> going once.
14:47:43 <sdague> going twice.
14:47:48 <sdague> ok, thanks folks.
14:47:51 <sdague> #endmeeting