22:02:02 #startmeeting Horizon 22:02:02 Meeting started Tue Dec 17 22:02:02 2013 UTC and is due to finish in 60 minutes. The chair is david-lyle_. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:02:06 The meeting name has been set to 'horizon' 22:02:16 o/ hi 22:02:19 hello 22:02:21 Hello everyone 22:02:21 hi 22:02:23 hey 22:02:24 howdy 22:02:24 o/ 22:02:26 hi all 22:02:29 hi 22:02:35 o/ 22:02:44 hiya 22:03:05 full house today, excellent 22:03:15 woot 22:03:21 https://launchpad.net/horizon/+milestone/icehouse-2 22:03:40 just wanted take a quick look at the i-2 milestone 22:04:02 things are progressing well and most things seem to be on track 22:04:17 lots of review opportunities :) 22:04:56 And things that have been merging have been slowed a bit by gate difficulties, so let's remain patient and work these items through 22:05:14 Does any one have any concerns or questions re: i-2 22:05:16 ? 22:06:00 I'll take that as a no 22:06:05 I see still a huge bunch of unreviewed patches 22:06:17 gah, too late ;-) 22:06:26 no worries 22:06:35 got through some reviews last week, will try to do more this week prior to holiday break 22:06:50 me too 22:07:02 we have to tame the review beast 22:07:12 I'd like to encourage all of you to do more reviews! 22:07:30 I think we have ~10 bps close to landing, just a few more iterations on reviews 22:08:01 so let's keep on them 22:09:01 Speaking of review load, I officially added tmazur to the horizon core list and retained ohnoimdead, as he expressed a strong interest and started reviewing again. 22:09:20 So welcome tmazur and thanks ohnoimdead 22:09:41 welcome both! 22:09:43 Cool, thanks tmazur and ohnoimdead 22:09:50 welcome :-) 22:09:51 *greatly appreciated* 22:09:57 welcome ;) 22:10:23 It's nice to also have people around with more historical knowledge of the code :) 22:10:25 hella! 22:10:44 absolutely 22:10:55 i'm old TT 22:11:08 Wise and experienced ;) 22:11:12 :-) 22:11:28 ok, on to the planned agenda https://wiki.openstack.org/wiki/Meetings/Horizon 22:11:45 #topic Meeting Time 22:12:11 So the was a thread on the dev mailing list about more diverse timezone friendly meeting times 22:12:26 I know I have talked with some of you before about this 22:12:39 yes... 22:12:58 Was that a horizon-meeting-specific thread? 22:13:02 I think our core team now covers enough timezones that finding one ideal time is going to be impossible 22:13:27 if we could move the meeting one or two hours earlier, I suspect tmazur could make it easier 22:13:27 jpich: no openstack-dev in general 22:13:40 would be great if we can move times 22:13:42 david-lyle_: ok, thanks, thought I missed it 22:13:47 Then amotoki and kspear have no chance 22:13:49 mrunge: but then we lose APAC 22:13:56 it's 9am at the moment 22:14:09 here it's 11pm 22:14:09 for me, but daylight saving will make it earlier... 22:14:12 david-lyle: true, e.g. Ceilometer uses two times 22:14:21 I think it's at 6 or 7am for amotoki at the moment 22:14:26 daylight will make it 00:00 for us :( 22:14:28 jpich, imho that discussion was arount summit time... 22:14:41 Ok 22:14:50 kspear, currently, it's 23:14 for me 22:14:55 same 22:15:00 same 22:15:01 and summer time, it will move later 22:15:02 so, I would be open to having a moving time or other suggestions 22:15:03 Personally, at the moment the meeting time is ok for me but when DST is on again it's really harder 22:15:41 I'm open to suggestions, because I have it the easiest right now 22:15:54 :-) 22:15:58 moving 1 hour earlier will make this meeting collide with the general meeting.... 22:16:20 2h earlier will be really hard for kspear 22:16:28 Sounds like a discussion/vote to have on list :) So people who can't attend right now because the timing sucks can chime in 22:16:29 1 hour earlier, I can't do 22:16:32 do we have any US West coasters? 22:16:33 could we all add our tz to some online tool to get a better idea of things? 22:16:33 what about two times, repeating every two weeks? 22:16:38 if we're up to move it earlier, then we need to pick another day 22:16:45 lcheng is typically on the west coast 22:16:53 kspear, good idea 22:17:04 what if we targeted morning time for EST like 9am…it would be 9pm-ish in APAC areas 22:17:07 ah okay 22:17:11 * kspear can't remember the name of any though 22:17:18 that would be tough for west coasters :) 22:17:28 then west coast is out 22:17:56 lblanchard: that's what glance does, it jsut means I have to get up at 6AM on standard time and 7AM on daylight savings 22:17:57 lsmola's and the ceilometer folks way to do it is probably the best, or would certainly be interesting to try (alternating meeting times) 22:18:13 let's collect times, to get a better idea, and then take this to another meeting? 22:18:32 markwash: thanks! 6am is pretty darn early for me…but maybe it would work for some? 22:18:37 david-lyle: yep https://wiki.openstack.org/wiki/Meetings/MeteringAgenda 22:18:46 mrunge: what is that tool that alvaro has used? 22:18:51 jpich: ^ 22:19:00 Agreed with mrunge, let's move it to the list, that won't be resolved here. Most people seem happy to consider a change 22:19:01 mrunge, good idea, let's leave the meeting time topic on the agenda page and just have people add their tz there 22:19:02 doodle? 22:19:06 david-lyle: this way all people can be here at least once in two weeks 22:19:26 lblanchard, on fedora, we took whenisgood, but doodle does the jobs as well 22:19:46 yeah, I was thinking of this: http://www.doodle.com/ 22:19:50 or that works if someone will take the item to set it up 22:20:35 jpich: alternating seems like a good idea 22:20:38 let's start the thread in ML to gather timezones and then we can set up doodle with concrete proposals 22:20:51 david-lyle: I can set up a doodle and share it with the ML 22:20:55 would it be sufficient to check for 2 hour slots? 22:21:06 lblanchard, thank you! 22:21:08 thanks lblanchard 22:21:29 lblanchard: thank you :-) 22:21:33 np! 22:21:57 #topic Tuskar-ui Code Merge Plan 22:22:32 so, I have sent 2 email with 2 plans 22:22:36 lsmola sent a proposal that the tuskar-ui group created and then we readily stomped on it, discuss 22:22:42 :) 22:22:45 :-) 22:23:01 seems we are leaning to codebase merge 22:23:10 though we have some worries 22:23:23 do you want to sum it up jcoufal or should I? 22:23:28 lsmola, is the main concern re: core and reviews? 22:23:36 david-lyle_: yeah 22:23:48 in few words 22:23:58 david-lyle: yeah, basically we need enough attention :-) 22:24:01 that's how many I can understand 22:24:21 tuskar-ui needs to be developed quickly, we have only 2 motnhs and the goal is to deliver functional installer 22:24:23 which is lot of work 22:24:34 which we are willing to do 22:24:43 ok, my thoughts are you are currently gated by horizon for the ui toolkit 22:24:45 david-lyle: lets say we have like 5 high priority tasks, that needs to be done by I3, so we have the deployment and manah=gement story upstream wants 22:25:10 I think that part remains with either proposal for now 22:25:34 david-lyle: will it be possible to remain high priority also when we are in Horizon? 22:25:53 I would be open to merging the core teams and letting the existing tuskar-ui core team +2 changes in that area of the code 22:25:56 to begin with 22:26:26 david-lyle: ok that would be great 22:26:42 I understand the need for agility in what is an incubating project, I don't see a need to block that 22:26:43 david-lyle, so the two-company policy of approvals would be suspended for the tuskar-ui code? 22:26:52 yes 22:27:00 david-lyle: how about the "multiple companies rule"? 22:27:01 I think it has to be 22:27:05 david-lyle_: we would like to keep cross-company reviews, so the only concern is if we can get enough attention 22:27:05 ok 22:27:11 Personally I would have concerns about just merging the core teams. The first proposal suggested having a separate team to work on the tuskar-ui code, to begin with (if i understood correctly) 22:27:33 I'm honestly not sure how to accomplish that jpich 22:27:47 jpich that would imply to have a separate code base 22:28:15 jpich: yes 22:28:25 it would be only a small step forward 22:28:35 I would like to get to the point of doing cross-company reviews for tuskar-ui, but I honestly don't feel comfortable enough at this point to place that requirement on me or other un-familiar cores 22:28:42 My understanding of the first proposal was that tuskar-ui would be in its own repository like now, except under the Horizon program - I was told that there could be a core team just for this, to begin with 22:28:52 david-lyle, yes, I'd love to do that 22:28:58 jpich: yes 22:29:02 or to see that 22:29:10 lsmola_: Thanks for confirming :-) 22:29:23 david-lyle_: it sounds reasonable if everybody agrees, we can move to cross-company reviews in time 22:29:34 we could also do that, jpich. I think the open question then for tuskarui is why move? 22:30:10 david-lyle, I have discussed this with the tuskar guys earlier 22:30:12 Tuskar is based on Horizon 22:30:19 david-lyle, one reason might be - right now lifeless feels responsible for our code, but it's difficult for the tripleo cores to evaluate horizon-based code 22:30:46 And when the project is integrated and has less of a requirement for turbo-velocity, we can work together on merging it into the main horizon codebase 22:30:46 and I don't see a benefit for horizon nor for tuskar just to move to another separate repository 22:31:24 mrunge, regarding that, I should ask - our development is currently somewhat horizontal - starting at the api layer, and working its way up 22:31:28 jpich, that would mean just to keep it like it is right now 22:31:28 david-lyle: well It could be a blocker if cores won't approve our patch because, they can't setup dev env 22:31:36 the code would probably run off mock data for the immediate future 22:31:41 is that sort of code acceptable within horizon? 22:32:13 mrunge: well that is the third and easiest plan to do :-D 22:32:36 * david-lyle_ torn 22:32:38 mrunge: the benefit would be that it gives us time to get used to the code, and the tuskar team to get more used to what the horizon core folks look for in reviews (we've seen pretty strong disagreements on the general horizon direction before...) 22:32:44 :-) 22:32:57 jpich, honestly? 22:33:02 who would do that? 22:33:13 if we aren't forced to do so? 22:33:16 well 22:33:17 mrunge: It would be different because tuskar ui would be the responsibility of tuskar-ui core + horizon core, instead of tuskar-ui core + tripleo core, which seems to be a better match 22:33:48 FWIW if david-lyle_ and the existing horizon cores are happy with a single code base and merging -core I think thats fantastic 22:33:48 so jpich, why don't merge? 22:34:31 I'd love to see tuskar as tight as possible integrated into horizon codebase 22:34:32 mrunge, I think the concern would be we'd be managing it a bit like two code bases at the beginning 22:34:37 Personally I think it makes more sense to be part of one codebase 22:34:44 david-lyle: well the good thing about merge now is, it will be easy, we don't have almost any code after the cleanup 22:34:45 using artificial means 22:35:15 I think we're all capable of doing that 22:35:20 lsmola_: +1 22:35:39 david-lyle, I'd rather treat tuskar as normal code, without any other *special handling* at all 22:35:57 david-lyle: true, it's undercloud vs. overcloud right now 22:35:57 david-lyle: so for the main functionality, the priorities wont be the same 22:36:07 mrunge, which brings me back to a question - is code that doesn't fully work okay to be accepted into horizon? 22:36:13 I think it makes sense to be part of one codebase once the project is integrated and we have similar requirements across the whole codebase (e.g. no more need for single company approval) 22:36:25 one issue is we're expanding horizon's scope to include incubated projects 22:36:25 tzumainn, I'd say: yes 22:36:36 mrunge: well you can see the infrastructure tab as a place where you manage a very special application you have deployed by heat 22:36:36 kspear, we did with trove 22:36:45 which means core has less time to spend on core projects 22:36:56 mrunge: and that didn't go well at all imo 22:37:09 mrunge: Trove was an exception because the code was all there and ready afaiui 22:37:27 kspear, trove didn't built on horizon 22:37:34 nor is it tightly integrated 22:37:42 I kinda agree with jpich - tuskar-ui is in a teardown and re-build state, and I feel like it'll be hard to evaluate for non-tuskar-ui people 22:37:48 but agreed. it could have worked better 22:38:04 tzumainn: jpich: +1 22:38:14 I think the key question isn't about the code state; its about what works better for everyone 22:38:31 lifeless, +1 22:38:46 lifeless: though seems like that is hard to find :-) 22:38:57 ok, when we don't merge more or less now, when do we have the next chance? 22:38:59 yeah, the only concern here is if we can get the code in quickly for tuskar-ui 22:39:06 and what will we get then? 22:39:14 which david-lyle_ seemed ok to facilitate:) 22:39:16 So the tuskarui folks think it's better to remain split, horizon-core seems split 22:39:28 a finished product? 22:39:51 david-lyle_: I don't think that tuskarui folks think it's better to remain split 22:40:05 I thought that was the proposal 22:40:06 david-lyle: well we would like to merge, though we need attention :-) 22:40:08 mrunge: The first proposal also said horizon core would be core for that project, it's up to us to get/keep up to date with it 22:40:12 per dev ml 22:40:22 There was a 2nd proposal sent about 12h ago as well 22:40:34 david-lyle: it would been healthier to build it under horizon cores eyes :-) 22:40:50 * david-lyle_ throws hands up 22:40:55 hehe 22:41:05 * jomara is late to the conversation 22:41:05 lsmola_, but if we aren't enforcing the multi-company reviewer rule, then what's the point? 22:41:30 tzumainn: well we are, that is why we need the attention 22:41:43 lsmola_, oh, are you saying you'd prefer a full merge, with the same reviewer rule that horizon uses, but we'd need a guarantee from horizon-cores that we'd get the appropriate attention? 22:42:02 lsmola_: tzumainn: I don't see what is the problem with what david-lyle offers 22:42:08 how did I miss that email 22:42:10 tzumainn: yeah something like that I guess 22:42:12 I don't think anyone can reasonably guarantee that 22:42:22 jpich, yeah, I agree - which is why I don't think that plan will work 22:42:24 david-lyle: there is a lot of emails 22:42:42 david-lyle_: can we say that we merge, and we want to try to keep cross-company reviews? would it be possible? ask horizon-cores to keep eye on the code that it makes sense from horizon point of view (they don't have to check how it works in sense of tripleo from the beginning, but they will get there) 22:43:13 jcoufal, so are you okay if it turns out they don't have the bandwidth for those reviews? 22:43:17 yes, I don't think there is a guarantee. on the other side, I don't see, how it could be so time-critical to get a patch in in e.g 4 hours 22:43:46 mrunge: well more like review 22:44:01 it would be easier for core reviewers, if we get enough reviews on code at all 22:44:12 mrunge: exactly 22:44:14 mrunge: that means you will have several reviews in one day, and you can address a feedback quickly 22:44:20 IMO this needs more discussion on list to surface a consensus (if there is one to be found :-)), 12h isn't a lot of time... 22:44:28 mrunge, it's because we're building from scratch somewhat, so future patches are likely to depend on recent ones 22:44:48 mrunge, also, I think some of our dependent libraries and apis may be in flux 22:44:53 jpich: sorry about that :-) 22:44:53 lsmola_: In an ideal world we want this for all the openstack patches 22:45:00 tzumainn, if you have dependent code, you could fetch it from gerrit 22:45:04 If the patch has 5 +1's on it I don't see a lot of work for core to approve it 22:45:07 lsmola_: No worries! 22:45:10 jpich: yaaay lets build an ideal world :-) 22:45:24 jtomasek, exactly 22:45:26 how many non-redhat core members horizon has? 22:45:33 jpich: can openstack buy some island? 22:45:57 lsmola_: I'll prepare a proposal for the foundation :) 22:46:00 jcoufal, 13 or so, if I'm not totally wrong 22:46:01 hehe 22:46:05 ~6 with varying levels of engagement 22:46:20 don't we have more core reviewers? 22:46:22 so about 6-7 active cores? 22:46:24 mrunge, cleaned up a little per ml outcome 22:46:31 ah, yes 22:46:44 you're right david-lyle_ 22:46:59 mrunge, not enough reviewers in general, that's picked up lately 22:47:26 but I think a track record needs to be established before moving people to core 22:47:28 well we have here 5(?) new contributors.... 22:47:58 6 22:48:01 and they should be able to do reviews as well, to help reducing the backlog 22:48:18 my proposal would be to try to keep cross-company reviews, we (tuskar-ui) can help as much as possible to ease reviews and then ask outside company cross members to have a look on almost ready code to get in... 22:48:25 I think it can work 22:48:32 what is review latency like? 22:48:34 jcoufal: I agree 22:48:41 currently, we're getting about 5-6 new patches per day 22:49:15 jcoufal: +1 22:49:19 I think david's numbers were 18/day last week? 22:49:36 the part I have trouble with is that a) tuskar-ui will require additional setup for reviewers, and b) tuskar doesn't have the documentation to ease reviewers' understanding of what's going on 22:49:39 can we have fallback plan? if we find out that we can't move as quickly forward as we need to ask for exception for temporary 'one company' reviews? 22:49:45 jpich: that may have been patchsets 22:50:10 but those all require reviews 22:50:18 david-lyle: Most of them need reviews though :) 22:50:19 yeah 22:50:31 jpich, http://russellbryant.net/openstack-stats/horizon-reviewers-30.txt look at the bottom 22:50:32 it's 19.9 now, btw 22:51:02 tzumainn: I don't think that horizon-core needs to ensure it works correctly from tripleo point of view - they can keep eye on if the code fits horizon way 22:51:30 at least from the beginning until they get more familiar with the code 22:51:35 hm, is that true? 22:51:48 I think there is enough concern expressed here to put this on the mailing list for a little more fine tuning. 22:51:54 * jcoufal thinks - so that's not assured :) 22:52:10 I don't want to drag this out, but I don't think there's a concensus here 22:52:11 mrunge: Thank you for the link 22:52:19 Agreed 22:52:22 david-lyle_: agree on ML 22:52:26 yupp, agreed 22:52:34 david-lyle: seems like it, though it looks like another very long thread :-D 22:52:40 we can follow the new thread lsmola sent 12h ago 22:52:59 sounds like a plan to me : ) 22:53:07 ok then 22:53:09 Is that email the new plan, or does a new-new plan needs to come out of this discussion first? 22:53:10 I'll write down some sort of summary or at least my point of view to kick this off 22:53:20 jcoufal: yes, reply to lsmola with it 22:53:20 jcoufal: thanks 22:53:24 I just want to ask for one thing 22:53:43 can we get attention to the ML to speed up the process of getting to consensus? 22:53:49 i think we can build a new plan based on the feedback :-) 22:53:58 let's continue to work out the details. I think this is the right fit, we just need the mechanics 22:54:06 david-lyle: so, talk about it again the next meeting? 22:54:17 next meeting is christmas 22:54:25 Next meeting is... next year? 22:54:31 next meeting will be on the 24th? 22:54:33 I would like to get to consensus until the end of the week. if all possible 22:54:36 yes I believe so 22:54:48 Yes. We can work out a consensus on list 22:54:54 yes, the next two weeks should be off from this meeting 22:55:13 The meetings shouldn't be a requirement to making decision 22:55:19 we can resolve this on the ml 22:55:19 *decisions 22:55:29 #topic Open 22:55:33 so, next meeting will be on Jan 7th, david-lyle_ ? 22:55:43 ok, so let's make consensus on a list 22:55:43 jcoufal: not sure if we are able to do it til lthe end of the week, but it would be great 22:55:45 +1 to jan7 22:55:47 after short discussion of the agenda... 22:55:47 jpich, david-lyle_: thanks, tomorrow morning expect the starting e-mail 22:55:54 I just wanted to remind everyone that there is a Persona Working Group kickoff meeting tomorrow 22:56:01 jcoufal: Ok! Thanks 22:56:09 mrunge, yes that's inline with the project meeting 22:56:37 ml is always open for pressing issues in the interim 22:57:02 lblanchard: Thanks! Are there international numbers available? 22:57:12 jpich: great question! 22:57:19 julim is running the meeting 22:57:21 lblanchard: thanks for the reminder 22:57:29 I will follow up with her and cc you, jpich 22:57:39 what was the flow there IRC then phone? 22:57:57 david-lyle: no problem. Yes, IRC and there is a conference call # in the invite 22:58:01 lblanchard: Ok, no problems. I think it would be useful to have it in the wiki and/or wherever else the meeting is announced :) 22:58:26 yes, good point. I will suggest this to Ju…I think maybe she will set up an etherpad early in the day and send that out to all 22:58:34 jpich: ^ 22:58:39 I see, that's an HP conference line, I'll see if I can dig up the international number for that 22:58:43 lblanchard: +1 that would be great 22:59:03 david-lyle: sounds great 22:59:05 lblanchard: Makes sense, cool 22:59:16 cool, catch those of you there who are interested :) 23:00:30 Ok, thanks everyone. Have a good couple of weeks and provider you tuskar-ui feedback on the ml. 23:00:42 oh, and review :) 23:00:48 #endmeeting