21:00:18 <mikal> #startmeeting nova 21:00:20 <openstack> Meeting started Thu Oct 8 21:00:18 2015 UTC and is due to finish in 60 minutes. The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:24 <openstack> The meeting name has been set to 'nova' 21:00:30 <mikal> #link https://wiki.openstack.org/wiki/Meetings/Nova 21:00:33 <mriedem> o/ 21:00:35 <mikal> ^-- agenda as usual 21:00:36 <edleafe> o/ 21:00:36 <jroll> \o 21:00:40 <bauzas> \........o 21:00:41 <ctrath> o/ 21:00:49 <dansmith> slurp 21:00:50 <mikal> #topic RC2 status 21:00:57 <mikal> So, I was asleep over night 21:01:03 <dansmith> mikal: ttx cut rc2 this morning 21:01:04 <mikal> Did we manage to get that thing out? 21:01:05 <dansmith> we got the last fix in 21:01:16 <mikal> Yay! 21:01:22 <mikal> So nothing else to discuss there really? 21:01:27 <dansmith> not imho 21:01:32 <mikal> Cool 21:01:37 <mikal> #topic Mitaka status 21:01:47 <dims> o/ 21:01:53 <mikal> So, the design summit session suggestion thing is now closed 21:02:08 <dansmith> john is going to submit the tentative schedule tomorrow morning he said 21:02:12 <mikal> johnthetubaguy is spending some quality time staring at the suggestions and will come up with a proposal for sessions real soon now 21:02:15 <mriedem> yeah, i don't have the etherpad anymore 21:02:22 <dansmith> we did that this morning 21:02:26 <dansmith> mikal: ^ 21:02:28 <mikal> #link https://etherpad.openstack.org/p/mitaka-nova-summit-suggestions 21:02:42 <dansmith> it's at the bottom 21:02:45 <mikal> Ahhh ok 21:02:54 <mikal> When I went to sleep it was still a todo item 21:03:07 <dansmith> well, it still has question marks around everything, but for no reason that I know of 21:03:12 <dansmith> johnthetubaguy likes question marks 21:03:17 <mikal> johnthetubaguy also wants us to try and sort specs into buckets 21:03:18 <dansmith> fear of commitment 21:03:26 <mikal> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking 21:03:54 <tonyb> do we know if danpb will be there? 21:03:54 <mikal> Which I guess is mostly about helping the review process out 21:03:58 <mriedem> tonyb: he will 21:04:02 <mikal> At the summit? 21:04:05 <mriedem> yes 21:04:06 <tonyb> mriedem: cool. 21:04:10 <mriedem> he's doing the neutron os vif lib session 21:04:32 <tonyb> mriedem: Oh good. that's the one I was thinking would be pointless without him 21:04:48 <mikal> Is there any point doing a blow by blow about the process for recovering specs / patches which didn't land in Liberty? Or do we think we all understand that? 21:04:56 <mikal> The process is unchanged from last release 21:04:57 <mriedem> no point 21:05:09 <mriedem> ping people to remove -2s 21:05:10 <dansmith> agreed no point 21:05:13 <mriedem> reporpose for mitaka 21:05:13 <mikal> Cool 21:05:14 <mriedem> done 21:05:28 <mikal> The only other thing I can think of here is are there already any specless blueprints we need to discuss / approve? 21:05:46 <dansmith> I think we discussed the only ones last week 21:05:51 <tonyb> john sent an email with the details didn't he? if we get questions we can just point at that 21:06:03 <mriedem> there are some in https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking 21:06:07 <mikal> Yeah, it should be well known 21:06:13 <mriedem> but i haven't looked 21:06:19 <mriedem> would need people here to bring them up 21:06:31 <bauzas> tonyb: yup http://lists.openstack.org/pipermail/openstack-dev/2015-September/075605.html 21:06:37 <mikal> There are a few specless blueprints in the etherpad 21:06:46 <mikal> #link https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking 21:06:52 <mikal> Line 61 onwards 21:07:24 <mriedem> looks like a couple are just re-proposals from liberty 21:07:29 <mikal> True 21:07:37 <mikal> I could seven not marked as approved in the etherpad 21:07:44 <mikal> We should discuss at least a few of those 21:07:53 <jlvillal> o/ 21:07:53 <mriedem> i ignore those that are struck out 21:08:05 <mikal> mriedem: yep, these are the non-struck out ones 21:08:08 <mikal> #link https://blueprints.launchpad.net/nova/+spec/hyper-v-block-device-mapping-support 21:08:16 <mriedem> approved in liberty, might as well re-approve it 21:08:22 <mikal> I think that one should get approved again 21:08:28 <mikal> mriedem: I think we should do a ten second discussion for each 21:08:35 <mikal> mriedem: instead of just blindly clicking 21:09:00 <mriedem> is time up yet? 21:09:02 <mikal> So are we still ok with the hyper-v bdm one? 21:09:12 <jroll> read: wait for mikal to say it should be approved again 21:09:17 <mikal> No objections, so I shall approve it 21:09:30 <mriedem> it's very sparse on details 21:09:32 <mriedem> but seems trivial 21:09:36 <mikal> #link https://blueprints.launchpad.net/nova/+spec/hyper-v-host-maintenance 21:09:49 <mikal> This one has code proposed 21:09:51 <dansmith> so 21:09:57 <dansmith> I don't think they should do this 21:09:57 <mriedem> i feel that needs a spec 21:10:05 <dansmith> host maintenance mode is currently xen-only, 21:10:16 <dansmith> and the way we do this now is with service disable, IMHO 21:10:28 <dansmith> so I don't want to see this spread to other drivers, personally 21:10:34 <mriedem> yeah, evacuate is not trivial 21:10:35 <mikal> If you want a spec I think that's a reasonable request 21:10:42 <mriedem> i put that in the etherpad 21:10:47 <jroll> iirc rackspace also uses service disable for maintenance, on xen 21:10:57 <jroll> presumably for a reason 21:11:03 <mikal> Ok, I will note in that BP that we'd like a spec please 21:11:04 <dansmith> right 21:11:09 <dansmith> we should kill this with fire 21:11:16 <dansmith> but since we can't really, we should not spread it 21:11:35 <mikal> Ok, move on? 21:11:37 <dansmith> mriedem: this is unrelated to evacuate, right? 21:12:03 <mikal> #link https://blueprints.launchpad.net/nova/+spec/hyperv-assisted-volume-snapshot 21:12:10 <mriedem> i thought host maintenance mode in xenapi triggered evacuate 21:12:14 <mriedem> but not through the actual rebuild api 21:12:28 <dansmith> mriedem: it does something weird and xen-specific at the lower layers 21:12:30 <mriedem> purely orchestrated in the virt driver i thought 21:12:32 <mriedem> yeah 21:12:33 <dansmith> mriedem: if you have host clusters or something 21:12:36 <dansmith> it's not our evacuate 21:12:40 <mriedem> right 21:12:55 <mriedem> i could see vmware wanting this too eventually..... 21:13:05 <mriedem> although i think they already do it 21:13:10 <dansmith> I think we should kill it 21:13:12 <mriedem> and try to sync up later and it breaks 21:13:17 <mriedem> i agree that it's not fun 21:14:01 <mikal> So, moving on? 21:14:03 <mriedem> anyway, definitely needs a spec 21:14:03 <mriedem> yes 21:14:04 <dansmith> vmware just sets an attribute on the host I think, 21:14:07 <mikal> We've asked for a spec and can talk there 21:14:11 <dansmith> whatever, okay 21:14:19 <mikal> #link https://blueprints.launchpad.net/nova/+spec/hyperv-assisted-volume-snapshot 21:14:49 <mriedem> ^ was approved in liberty 21:14:53 <mikal> Yep 21:14:56 <mikal> I think we should approve again 21:14:59 <mriedem> agree 21:14:59 <mikal> Thoughts? 21:15:11 <mriedem> code would be helpful 21:15:23 <mikal> Next one 21:15:26 <mikal> #link https://blueprints.launchpad.net/nova/+spec/filter-mem-bw 21:15:52 <mriedem> also approved in liberty 21:15:55 <mriedem> no code 21:16:00 <dansmith> half of it is done though 21:16:00 <mikal> Yep 21:16:06 <dansmith> the metric is already reported 21:16:17 <mikal> Its relatively cheap to approve and wait for code 21:16:19 <mriedem> https://review.openstack.org/#/c/180983/ 21:16:20 <mriedem> yeah 21:16:22 <bauzas> +1 21:16:23 <mriedem> yeah 21:16:26 <dansmith> do we even need more code for this? not sure 21:16:27 <mriedem> approve 21:16:28 <mikal> So approve? 21:16:34 <dansmith> I thought there was a generic metrics filter? 21:16:46 <mikal> I'd have to look 21:16:49 <dansmith> bauzas: ? 21:16:50 <bauzas> this is more for weighers 21:16:51 <mriedem> jaypipes: might know 21:16:59 <bauzas> but we indeed have a filter 21:17:12 <dansmith> do we need more code? 21:17:13 <mikal> Sounds like we should just approve though and let that discussion happen in the code review? 21:17:14 <bauzas> that just checks whether the metrics are okay 21:17:27 <dansmith> mikal: my point is, I'm not sure we have anything else to do 21:17:32 <dansmith> mikal: approving it when nothing needs to be done in mitaka seems silly :) 21:17:41 <mriedem> so let's post the questoin in the whiteboard 21:17:46 <dansmith> yeah, that 21:17:47 <mriedem> and bug sudipto in nova later 21:17:48 <bauzas> yup 21:17:56 <mriedem> *sudipta 21:17:59 <mikal> Sure, works for me 21:18:03 <mikal> Who is doing that whiteboard thing? 21:18:08 <bauzas> I can 21:18:11 <mikal> Ta 21:18:20 <mikal> #link https://blueprints.launchpad.net/nova/+spec/live-migration-statuses 21:18:21 <mriedem> i did 21:18:23 <bauzas> mmm, maybe a nova-drivers tho 21:18:37 <bauzas> mriedem: thanks 21:18:46 <mriedem> holy balls https://review.openstack.org/#/q/topic:bp/live-migration-statuses,n,z 21:18:47 <dansmith> I asked in the etherpad 21:19:00 <dansmith> ugh 21:19:03 <mikal> Yeah, that's a lot of reviews 21:19:05 <dansmith> -2 21:19:13 <dansmith> ndipanov is working on a state machine for migrations 21:19:15 <mriedem> they are 2 line changes 21:19:19 <mriedem> but still 21:19:26 <dansmith> these status strings should not be codified, IMHO 21:19:52 <bauzas> agreed 21:19:52 <mikal> Shall we ask ndipanov to take a look at this and comment? 21:20:20 <mriedem> probably 21:20:28 <dansmith> yes, and I -2d 21:20:34 <dansmith> the bottom patch in the series 21:20:47 <dansmith> MIGRATION_STATUS_DUMMY 21:20:51 <dansmith> I mean, really 21:21:22 <mikal> Ok, so who is going to ping ndipanov? 21:21:28 <dansmith> I'll add him 21:21:34 <mriedem> i commented in the etherpad also 21:21:41 <mikal> Ok cool 21:21:48 <mikal> #link https://blueprints.launchpad.net/nova/+spec/vmware-use-datastore-copy 21:21:53 <mriedem> i think ^ is fine 21:21:58 <mriedem> it's a procedural bp 21:22:05 <mikal> Yeah, I think we approve this one 21:22:26 <mikal> No objections? 21:22:37 <dansmith> no relevant ones 21:22:40 <mikal> Heh 21:22:48 <mikal> Last one 21:22:52 <mikal> #link https://blueprints.launchpad.net/nova/+spec/add-swap-volume-notifications 21:23:08 <mriedem> trivial, approve 21:23:10 <dansmith> I wish we didn't even have blueprints for this 21:23:11 <dansmith> but whatever 21:23:19 <mikal> Ok, I'll approve that one too then 21:23:24 <mikal> Wasn't that fun people? 21:23:27 <dansmith> no 21:23:29 <mriedem> yes! 21:23:32 <mikal> Heh 21:23:37 <mikal> #topic Regular reminders 21:23:43 <jroll> if it made dansmith grumpy it seems like fun 21:23:52 <dansmith> jroll: I was already grumpy 21:23:55 <mikal> There is a new priority review etherpad at https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking 21:24:00 <mikal> I'm not 100% sure that that means at this point 21:24:02 <mikal> BUT IT IS THERE 21:24:03 <jroll> hah 21:24:18 <mikal> Any other things you'd like to be nagged about? 21:24:31 <mikal> Seems not 21:24:32 <mriedem> trivial bugs are supposed to be in there also, and virt driver reviews etc 21:24:40 <mriedem> *subteam 21:24:41 <mikal> mriedem: fine, be that way 21:24:56 <mikal> #topic Gate status 21:25:01 <mikal> mriedem: do that thing 21:25:09 <mriedem> idk, it's touch and go 21:25:14 <mriedem> things are not fun 21:25:21 <dansmith> shit has been failing a lot for me today 21:25:23 <mikal> Sounds like rc2 was painful to get merged 21:25:25 <mriedem> http://status.openstack.org/elastic-recheck/index.html 21:25:30 <bauzas> yup 21:25:30 <dansmith> I started insulting jenkins in my recheck comments 21:25:33 <mriedem> yes, i've been rechecking a lot 21:25:37 <mikal> LOL 21:25:44 <bauzas> mostly the firewall thing AFAICT 21:25:47 <mikal> "recheck, you useless pigdog" 21:25:54 <mriedem> the libvirt firewall ebtables stuff is relatively new and annoying 21:25:59 <dansmith> https://review.openstack.org/#/c/230227/ 21:26:01 <mriedem> showed up on 9/29 21:26:22 * dims warns that oslo libraries will start rolling out early next week for Mitaka 21:26:28 <mriedem> oye 21:26:30 <mikal> Oh, we're doomed 21:26:33 <dims> :) 21:26:35 <mriedem> the ceph job is also spazzing now too 21:26:53 <dansmith> I say we give up on this grand experiment 21:26:57 <mikal> Anyways, is there anything concrete people need help with here? 21:26:59 <tonyb> dansmith: +1 21:27:07 <mriedem> we need help with the libvirt firewall stuff 21:27:14 <mriedem> i did some investigation in one of the bugs 21:27:16 <mriedem> there are 2 of them 21:27:21 <mikal> Links? 21:27:23 <mriedem> there was an ubuntu kernel update on 9/29 or thereabouts 21:27:35 <mriedem> https://bugs.launchpad.net/nova/+bug/1501558 21:27:35 <openstack> Launchpad bug 1501558 in OpenStack Compute (nova) "nova-net: libvirtError: Error while building firewall: Some rules could not be created for interface: Unable to update the kernel" [High,Confirmed] 21:27:46 <mriedem> https://bugs.launchpad.net/nova/+bug/1501366 21:27:47 <openstack> Launchpad bug 1501366 in OpenStack Compute (nova) "libvirtError: Error while building firewall: Some rules could not be created for interface" [High,Confirmed] 21:28:01 <mriedem> there were no nova changes around 9/29 that look related 21:28:05 <mriedem> or upstream deps 21:28:16 <mriedem> so i kind of blame the kernel update in ubuntu 14.04 on 9/29 21:28:18 <mriedem> but idk 21:28:44 <mikal> I wonder if we can involve Canonical? 21:28:51 <mikal> Start a -dev thread asking them for help perhaps? 21:28:52 <mriedem> so i found the kernel bug in LP 21:29:06 <mriedem> and posted that we were having issues and they said it looked unrelated and to open a new bug 21:29:21 <mriedem> at which point i gave up 21:29:36 <mriedem> the links are in the nova bug report 21:29:50 <mikal> My tame kernel dev has chosen to ride his bike all weekend, otherwise I'd throw him under this bus 21:29:50 <mriedem> ccarmack found a change in kilo where we did some retry stuff on ebtables updates, 21:30:02 <mriedem> maybe we just need some other retry somewhere else, but it seems odd to have spiked on 9/29 21:30:12 <ccarmack> mriedem: is there a way to try libvirt 2.11 as an experment to see if the concurrency issue goes away? 21:30:15 * tonyb wonders who mikal is talking about? 21:30:15 <mriedem> break his legs 21:30:28 <mriedem> ccarmack: 1.2.11? 21:30:28 <mikal> ccarmack: that would be non-trivial 21:30:31 <mriedem> right 21:30:33 <ccarmack> yes 21:30:41 <mriedem> unless it's in fedora 21 21:30:55 <mriedem> b/c there is a fedora 21 job in the experimental queue 21:30:59 <tonyb> ccarmack: that's soemthign I've been workign towards for a while but it still isn't ready. 21:31:11 <mikal> So, we aren't going to solve this here 21:31:13 <mriedem> however, it doesn't help the normal gate jobs that use trust 14.04 21:31:17 <mriedem> yeah, move on 21:31:21 <mikal> But hopefully people will help mriedem out here 21:31:30 <mikal> Or at least give him a hug 21:31:43 <rlrossit> ctrath: get on it 21:31:45 <mriedem> i don't do well with hugs 21:31:49 <mikal> #topic Third party CI status 21:31:53 <clarkb> mriedem: I know ianw and pabelanger are working to move to f22 if it helps 21:31:59 <dansmith> "in the toilet" 21:31:59 <mikal> Intel PCI CI was sad, yeah? 21:32:02 <tonyb> mriedem: let me know eher you get up to over the w/e and I'll look at whatever you say is most urgent on my Monday 21:32:19 <mriedem> mikal: t-h is off the rails 21:32:24 <mriedem> or is at least sporadic 21:32:27 <mikal> mriedem: oh, interesting 21:32:30 <mriedem> and yes intel pci ci is in the toilet 21:32:36 <mikal> mriedem: I'll poke jhesketh about that 21:32:42 <mriedem> they replied in the ML and said their log server went down or something and were fixing it 21:32:44 <tonyb> mriedem: jhesketh is on leave 21:32:58 <mikal> tonyb: oh yeah, we shouldn't have let that happen 21:33:03 <bauzas> mriedem: seems t-h was a bit better tonihgt 21:33:07 <mriedem> http://ci-watch.tintri.com/project?project=nova 21:33:11 <mikal> I'll try to find the time to look at t-h today then 21:33:25 <mriedem> ^ shows t-h as okish, but i was seeing failures in gerrit 21:33:37 <mikal> Anything else on CI? 21:34:02 <mriedem> no 21:34:04 <mikal> #topic Stable branches 21:34:32 <mikal> Nothing? 21:34:39 <mriedem> kilo is still frozen 21:34:44 <mriedem> 2015.1.2 should be out soonish 21:34:47 <mriedem> there is a thread in the ML 21:34:48 <tonyb> juno is a mess ;P 21:34:55 <mriedem> juno is eol in november 21:35:02 <tonyb> (but nothing specific to nova) 21:35:03 <dansmith> lol -> juno 21:35:13 <mriedem> yeah, i'm biding my time for juno to die 21:35:32 <Vek> ("long live kilo!") 21:35:35 <mikal> Moving on 21:35:48 <mikal> #topic Open Discussion 21:35:51 * jroll glares at Vek :P 21:36:01 * Vek smiles back 21:36:12 <melwitt> I put a thing in the open discussion 21:36:21 <mikal> Its not there any more? 21:36:22 <dansmith> we should discuss it openly 21:36:30 <mikal> Oh, refresh 21:36:49 <melwitt> we've been unsure what to do with this review in novaclient, wants to add more output to some CLI commands https://review.openstack.org/#/c/190111/ 21:36:59 <melwitt> someone told him to make a blueprint and he did https://blueprints.launchpad.net/python-novaclient/+spec/enhance-commands-for-usability 21:37:32 <melwitt> we already have this type of output for nova delete, reboot, stop, and start 21:37:34 <mriedem> so -2 the change first 21:37:39 <mriedem> if there is a bp 21:38:03 <bauzas> so there was also an interest from lxsli about providing json output 21:38:14 <melwitt> so I wanted to find out if there's any objection to adding these outputs to more commands, and if not, if we can approve the bp and let the person's patch get reviewed 21:38:27 <tonyb> bauzas: isn't that all part of openstack-client? 21:38:28 <bauzas> but osc sounds good for that 21:38:34 <bauzas> tonyb: yeah that 21:39:02 <tonyb> melwitt: my $0.02 is add the output but also provide a way to turn it off (if that isn't already a thing) 21:39:16 <bauzas> is there a consensus on improving the CLI output given that there is osc ? 21:39:58 <melwitt> tonyb: that makes sense, but we're already doing it for delete, reboot, stop, and start and it's not optional 21:40:03 <mriedem> it seems trivial enough 21:40:08 <Vek> unless we're ready to deprecate the novaclient CLI and point people to osc... 21:40:15 <melwitt> so it feels weird to tell him no when there's already commands doing it 21:40:30 <mriedem> novaclient cli is not deprecated 21:40:35 <tonyb> melwitt: then make it optional ;P consistency is worth it IMO 21:40:37 <mikal> Vek: I can't see that happening any time soon 21:40:40 <mriedem> so until that happens, and other commands do this, it seems trivial to add it in 21:40:48 <bauzas> fair enough 21:40:50 <mriedem> i can see the ux side of it 21:41:02 <mriedem> - do thing; no response; wut? 21:41:05 <Vek> me neither. For context, that was in response to the question about improving output, which I took to be regarding the addition of json output. 21:41:30 <mikal> Seems like we're ok with adding this output? 21:41:37 <mikal> No one has strenuously objected? 21:41:42 <bauzas> that sounds only additive, right? 21:41:47 * Vek is +2 21:41:52 <mriedem> i'm fine with it 21:41:57 <edleafe> sounds fine to me 21:42:09 <dansmith> I am unable to care less about this topic 21:42:12 <mikal> melwitt: make it so! 21:42:13 <bauzas> :) 21:42:26 <tonyb> dansmith: lol 21:42:28 <melwitt> mikal: can you approve the bp? or does johnthetubaguy have to do it? 21:42:35 <mikal> melwitt: I can 21:42:36 <mriedem> now i'd like to talk about the max lenght of commit message titles and periods at the end of a title for awhile 21:42:45 * dansmith punches mriedem in the face 21:42:56 * edleafe piles on 21:42:57 <mikal> I think it should be no more than 4 characters 21:42:57 <ccarmack> we are in the same room as mriedem 21:43:02 <mikal> And always have a "!" in it 21:43:13 <dansmith> #endmeeting 21:43:16 <mriedem> there was seriously that guy in channel that ! everything last week 21:43:24 <dansmith> mriedem: that was awesome 21:43:25 <mikal> Anything else non-trolly here? 21:43:28 <dansmith> mriedem: he was very excited 21:43:32 <mriedem> i have a question! 21:43:35 * Vek is glad to have missed that... 21:43:37 <mriedem> what should i work on! 21:43:41 <dansmith> mriedem: go away! 21:43:45 <annegentle> wow I love the snark in this meeting! 21:43:51 <Vek> mriedem: add json output to novaclient? :) 21:43:52 <mriedem> ok, i'm done 21:43:54 <annegentle> heh 21:43:55 <mriedem> Vek: no 21:43:55 <dansmith> heh 21:44:00 <mikal> Ok, game over 21:44:07 <mikal> #endmeeting