14:01:25 #startmeeting nova 14:01:25 Meeting started Thu Oct 16 14:01:25 2014 UTC and is due to finish in 60 minutes. The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:29 The meeting name has been set to 'nova' 14:01:31 https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting 14:01:34 \o 14:01:36 hi 14:01:37 o/ 14:01:37 #topic juno 14:01:38 o/ 14:01:38 lurking 14:01:40 o/ 14:01:41 o/ 14:01:43 so juno is shipped 14:01:51 \o/ 14:01:54 stable backports for stuff you spot now I think 14:02:02 o/ 14:02:08 usual backport tags for all that fun 14:02:16 #topic kilo 14:02:17 * beagles lurks 14:02:32 so specs are open, we are fast approving some, and slow approving some 14:02:41 any questions or things to raise? 14:03:01 stable/juno doesn't seem to exist yet 14:03:08 #info if your code reviews are being blocked on a "procedural -2", please ping the reviewer (in email) and remind them to reconsider 14:03:09 nope 14:03:28 mriedem: hmm, doh, I guess we only just tagged, so thats next 14:03:41 i'll let it go this time 14:03:48 :) 14:03:54 anyways, anything on specs? 14:04:05 everyone as happy as they can be about the new rules? 14:04:16 any tweaks needed at the moment? 14:04:24 johnthetubaguy: about priorites 14:04:32 johnthetubaguy, too early to tell, we'll comment when we have issues 14:04:34 johnthetubaguy: it's asked to fill them in 14:04:39 bauzas: to be agreed at the summit I think 14:04:51 johnthetubaguy: k, so leaving a perhaps in this 14:05:06 bauzas: i just put None if my thing wasn't an obvious priority 14:05:16 mriedem: +1 14:05:24 mriedem: k, I'm taking the etherpad as a reference 14:05:26 it's a priority for me, but not the project 14:05:35 we can go back and edit the specs, if we come up with a priority that you fit, after its approved 14:05:45 https://etherpad.openstack.org/p/kilo-nova-priorities 14:06:04 I'm taking these chapters as the ones I'm looking to, if so 14:06:09 johnthetubaguy: k, sounds good 14:06:13 does it make sense to approve a spec that has no priority, I would think that would be required 14:06:27 so what do the priorities mean now - there was so much back and forth that I am not sure what is agreed on 14:06:39 n0ano: thats another summit discussion, for now, yes, they are low priority 14:06:57 I was understanding that priorities would be set for juno-3 ? 14:07:02 oops 14:07:03 ndipanov: right now, they have no power, the idea is to agree at the summit 14:07:04 kilo-4 14:07:09 which means they'll probably get ignored so yes, this needs to be discussed at the summit 14:07:09 kilo-3 14:07:34 * bauzas has to watch the new openstack episodes 14:07:42 so yeah, my current plan is, kilo-3 nothing except high priority stuff merges, so we kinda have a soft blueprint freeze at the end of kilo-2 14:07:49 k 14:08:00 but lets see how it goes, is the detailed version of the plan 14:08:16 johnthetubaguy, and we are not doing runways, right? 14:08:36 the policy patch for runways was abandoned 14:08:42 #info remember, all features need a blueprint, not all blueprints need a spec 14:08:44 which is what i thought we were going to use to get low priority stuff in 14:09:00 yeah, runways just got shot down too much on the ML 14:09:03 https://review.openstack.org/#/c/115410/ 14:09:21 my hope is to discuss that at the summit, and come up with a comprimise 14:09:37 johnthetubaguy, ack - that will be a fun discussion :) 14:09:54 the current one is, kilo-1 and kilo-2 is free, kilo-3 is basically runways 14:09:57 * alaski wanders in late 14:10:19 cools 14:10:32 #topic Kilo Summit 14:10:59 so, I was hoping we would have a session plan, that we could discuss, but we don't really 14:11:13 I have lobbed a few ideas at the end of the etherpad 14:11:16 #link https://etherpad.openstack.org/p/kilo-nova-summit-topics 14:11:38 #info we have 2 days of scheduled slots and 1 day of meetup style 14:11:52 we need to decide what gets a slot, and what needs meetup style 14:11:53 I like those ideas - I am not sure we want to do session per BP like we did in the future, meetup can be for that I guess? 14:12:02 lol future 14:12:03 past 14:12:05 in the past 14:12:17 time traveling is fun 14:12:21 johnthetubaguy: slots are 40 mins right? 14:12:27 bauzas: think so 14:12:42 ndipanov: agreed though 14:12:53 so for stuff that is "here is my feature X" 14:12:57 i like meetup style more than slots for everything, but i'd think the process talks would be better for a meetup? 14:13:01 lets have a spec first 14:13:05 mriedem: +1 14:13:11 johnthetubaguy, you have some big topics on that list, 40 min. is going to be interesting 14:13:24 johnthetubaguy: what if the spec got accepted before the Summit, then violent agreement for 40 mins ? :) 14:13:36 n0ano: some might get two slots, but yes 14:13:44 johnthetubaguy, very much agreed 14:13:53 bauzas: thats the hope, avoid that slot, and re-schedule something else into that 14:13:54 in atlanta a lot of the QA sessions were presentations and those were nicely wrapped up in time for questions within 40 minutes, 14:14:01 johnthetubaguy: awesome 14:14:01 i'd like to see that with blueprint design sessions 14:14:08 and do meetups for big groups of process argument 14:14:20 mriedem: really? 14:14:36 i hate the 40 minute thing 14:14:36 I though that;s exactly why we don't want that in sessions 14:14:38 is my point 14:14:38 mriedem: I don't really want presentations in design summit slots 14:14:39 go read a bp 14:14:47 dansmith: +1 14:14:52 or spec 14:14:54 small slots for small discussions 14:14:55 mriedem: I seriously doubt that some topics can cover both a presentation and a discussion in 40 mins 14:14:57 dansmith: +1 14:15:00 ndipanov: yeah, if you can read the spec or bp, thats fine, whatever 14:15:03 if it's a longer discussion, then meetup style 14:15:04 mriedem: but hell yeah, planning will be fun 14:15:14 bauzas: we probably give them two slots then, thats fine 14:15:15 i'm not talking about a demo 14:15:27 basically going through whatever the blueprint is, or sticking points, idk 14:15:33 -1 14:15:40 i just didn't think most of the design sessions seemed to be useful in ATL 14:15:48 the 40 min ones 14:15:50 mriedem: agreed 14:15:56 so here is the thing 14:16:01 we don't have much time together 14:16:03 the ATL sessions weren't really well planned 14:16:09 if we can do something in the specs, then we can avoid it 14:16:35 dansmith: +1 hope we can avoid the ATL dumb sessions 14:16:40 yeah, 14:16:51 although we're getting pretty close with minimal planning so .. we'll see 14:16:55 ok, i guess i don't have any other summits to compare to so i started with the worst one... 14:16:56 so any BP session will be because we can't agree on the spec 14:17:15 mriedem: well the previous one was better, thats all 14:17:19 johnthetubaguy: or because it's wider than a single spec ? 14:17:44 bauzas: if we can agree half the specs for the scheduler stuff, then it helps us concentrate on the stuff we need to talk about right? 14:17:55 johnthetubaguy: good question 14:17:57 bauzas: if we agree all the specs, then cool, nothing to talk about 14:18:18 Some things are about carving up the work between a group of people 14:18:21 johnthetubaguy: well, we at least need to make sure all reviewers stick with the plan 14:18:37 johnthetubaguy: I mean, summits are good for that 14:18:58 johnthetubaguy: specs having 2x+2 don't necessarly mean that the consensus has been reached 14:19:27 I don;t think we are looking for consensus 14:19:42 bauzas: if there were no −1s then the system broke, need to get people to vote on there, anyways 14:19:42 ndipanov: then what ? :) 14:19:48 we are looking for good implementation 14:19:59 and features 14:20:09 screw consensus... :) 14:20:11 anyways, this is not rally going anywhere 14:20:15 yes agreed 14:20:18 move on :) 14:20:19 +1 14:20:25 ndipanov: lets just say, code means a lot 14:20:30 good code means more 14:20:31 anyways 14:20:34 so one more question 14:20:37 was rally a freudian slip there? 14:20:44 I feel like we're ratholing here 14:20:58 dansmith: +1 14:20:58 the only perf things on your list johnthetubaguy is the profiler stuff 14:21:14 oh and Rally 14:21:16 ndipanov: do we have perf stuff to talk about? 14:21:22 i thought there were db things 14:21:25 well yes 14:21:26 db 14:21:33 jogo had something that zzzeeek said wouldn't help 14:21:36 OK, not seen that proposed 14:21:38 so assuming zzzeeek has alternatives 14:21:57 jogo's was removing the ORM 14:21:59 SA ORM 14:22:04 bayer said that wouldn't really help 14:22:07 ah, OK, so thats a thing 14:22:08 so if I could add one thing to the list - it would be talk about perf - with a strong focus on db 14:22:20 yes that is an old discussion tho 14:22:25 mriedem: its helped us in some bits, but its probably more about us using it wrongly 14:22:27 if that's a thing for the "meetup" 14:22:42 ndipanov: its on the meet up list already actually, in a really bad way 14:22:44 then cool - but I feel we really should talk about it 14:23:09 since it is one of the reasons scheduler and other stuff we all want to violently discuss sucks so bad 14:23:21 :) 14:23:27 ndipanov: :) 14:23:28 #topic Gate 14:23:31 so hows the gate 14:23:37 johnthetubaguy, you updated the etherpad, is someone going to create a spec for DB improvements? 14:23:39 i put some links in the agenda 14:23:47 ndipanov: do try a single caching scheduler, thats actually quite fast 14:23:50 the gate is....kind of unknown 14:23:59 categorization of gate bugs is at like 58% which sucks 14:24:12 so we have something out there, i suspect the cinder volume delete lvm/vgs hangs, that aren't tracked 14:24:16 i'm working on tracking that today 14:24:21 lots of new bugs, or just lots of broken code up for review? 14:24:30 OK, cool, your digging 14:24:37 two bugs to mention 14:24:42 1. https://bugs.launchpad.net/nova/+bug/1353962 - that's the fixed ips quota one 14:24:44 Launchpad bug 1353962 in nova "Test job failes with FixedIpLimitExceeded with nova network" [Undecided,Confirmed] 14:24:48 still need eyes on that, we have better logging now 14:25:02 2. this is the cinder volume hang bug we're tracking https://bugs.launchpad.net/cinder/+bug/1373513 14:25:04 Launchpad bug 1373513 in cinder "Lvm hang during tempest tests" [Critical,Confirmed] 14:25:14 vgs/lvs calls are taking sometimes 2 minutes causing cinder volume deletes to timeout 14:25:18 n0ano: I should reach out on the ML for owners and spec drivers for some of this stuff 14:25:22 i need to get a better query up in e-r for that one today 14:25:27 mriedem: is this a review call to action, or a help thing? 14:25:36 johnthetubaguy: help 14:25:42 johnthetubaguy, OK, it's just that that's a rather nebulous topic 14:25:51 we have a patch up for cinder to get some strace on the vgs/lvs calls but it needs some help i think 14:25:54 n0ano: agreed 14:26:02 https://review.openstack.org/#/c/126735/ 14:26:13 someone with rootwrap knowledge to fix that would be nice 14:26:38 cool, so we are done here I guess, since no one is jumping up to discuss things? 14:26:43 i guess 14:27:01 moving on 14:27:03 #help the gate still needs more love 14:27:08 #topic Open Discussion 14:27:26 OK, anyone got things they want to talk about? 14:27:28 I have a general question I was not able to get a response to on nova channel 14:27:40 boden: OK, fire away 14:27:41 what is our stance on ec2 parity... e.g. https://bugs.launchpad.net/nova/+bug/1370384 14:27:43 Launchpad bug 1370384 in nova "Cannot expand root volume by EC2 API" [Medium,In progress] 14:27:56 boden: patches welcome, I think thats the stance 14:28:12 we had a sub group pushing on that, but not heard a lot recently 14:28:21 johnthetubaguy -- the point is we can do that workflow using existing nova resize 14:28:37 do we really need to support the ec2 "manual workflow"? 14:28:50 boden: duno, do people want to use it? 14:29:08 is anyone going to maintain it? 14:29:12 boden: the other thing is we rarely get new/good working ec2/boto tests in tempest 14:29:20 boden: I think the answer here is, it's important if someone thinks it's important and wants to work on it 14:29:25 boden: if not, then not 14:29:25 the last new boto test broke the gate and was reverted 14:29:33 johnthetubaguy, (stepped away for a bit...) so yeah - caching is definitely one of the solutions to the db suckage :) still we should mention it at least in the meetup 14:29:39 dansmith: +1 you said what I am failing to express 14:29:51 the lack of enthusiasm here indicates that it's not important, IMHO :) 14:30:05 dansmith -- I dont mind working on it, but hanve't seen many asks 14:30:19 anyway fair enough answer 14:30:21 thanks 14:30:23 boden: if you think it's important, then propose a spec to describe what you think needs changing and why it's important 14:30:28 dansmith, your're probably correct but that goes back to are we devloper focused or user focused, I think we've tilted too far to the developer side right nwo 14:30:31 until then, there's really not much to discuss :) 14:30:45 dansmith +1 14:30:59 n0ano: no developers being asked by their paying users to add that thing is a good indication to me :) 14:31:00 anyways, lets not go down that whole 14:31:06 any more questions? 14:31:20 dansmith: +1 I am afraid 14:31:32 seems like we are done early 14:31:35 dansmith, maybe, I won't argue that here 14:31:36 is cells meetup or slot? 14:31:44 mriedem: slot right now 14:31:51 not seeing it at the bottom of https://etherpad.openstack.org/p/kilo-nova-summit-topics 14:31:53 we can talk about cells for days, 14:31:54 mriedem: based on whats in my head 14:32:03 so I think that bounding it is fine 14:32:09 maybe a double slot, if we're considering such things 14:32:14 yeah i just want to see the work items/plan 14:32:14 johnthetubaguy, were you looking at improving tests for cells - i kinda saw something last week or so 14:32:22 mriedem: its at the top of the "must have slots" list 14:32:30 I was seeing a discussion about some kind of cells for the crossproject track 14:32:38 johnthetubaguy: ha, i wasn't scrolled up high enough apparently 14:32:54 mriedem: no worries 14:33:02 wouldn't it be interesting to discuss about cells at a general openstack level, if we consider rebooting them ? 14:33:25 bauzas: this conversation is not about that, 14:33:33 bauzas: it's about fixing what we have, not rebooting cells entirely 14:33:38 bauzas: the first priority is making them a first class citizen in Nova 14:34:01 dansmith: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics L114 14:34:13 alaski: dansmith: ack 14:34:21 bauzas: yeah, its because of an email thread 14:34:41 okay, I'm talking about the cells discussion on our list 14:34:42 johnthetubaguy: but I totally understand that cells can be discussed in both sessions 14:34:44 bauzas: but yeah, nova one is talking about different things really 14:34:52 johnthetubaguy: got it 14:34:52 I think the cross-project one is in response to the cascading stuff 14:35:00 yeah 14:35:05 indeed 14:35:22 anyways, seems like we are done, we can take other things to the usual channel 14:35:26 thanks all 14:35:35 #endmeeting