20:00:25 #startmeeting Horizon 20:00:26 Meeting started Wed Mar 11 20:00:25 2015 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:29 The meeting name has been set to 'horizon' 20:00:36 o/ 20:00:40 o/ 20:00:40 hey 20:00:41 hi 20:00:47 hi all 20:00:48 Hello/ 20:00:49 o/ 20:01:01 hello 20:01:04 o/ 20:01:16 Evening all 20:01:20 hello 20:01:29 hello 20:01:53 o/ 20:01:55 Hello everyone 20:01:56 hi 20:02:03 hi 20:02:51 Ok, FPF is upon us, code should be up for patches for K-3 items 20:02:52 HI 20:03:28 o/ 20:03:59 is this the part of the meeting where we make confessions regarding code that isn't going to make k3? 20:04:23 :) 20:04:25 lol 20:04:32 doug-fish: yes, good segue 20:04:47 #link https://launchpad.net/horizon/+milestone/kilo-3 20:05:03 10 Good progress, 1 Beta Available, 12 Needs Code Review, 10 Implemented 20:05:18 haha 20:05:36 what's the difference here? 20:05:50 I mean, between good progress, beta and code review? 20:06:31 beta, unsure, radomir set that 20:06:42 (I'm just curious how to set that right) 20:07:00 good progress means most pieces are ready for review, but not all, or WIP 20:07:23 Needs Code Review should mean just that, ready to review and merge as far as the author is concerned 20:07:42 ah, ok. thanks! 20:08:15 ideally we should only have Needs Code Review on that list 20:08:33 yepp, agreed 20:08:38 but there are a few high priority items that we can be flexible for 20:09:53 david-lyle: I had a bugfix merged a couple of nights ago that isnt on this list. Should I pursue getting it on this list? How? 20:10:11 bug fixes are separate 20:10:16 ok 20:10:24 we can land those up to RC 20:10:29 cool 20:10:30 and then even critical ones 20:10:39 this is new features 20:11:46 status on the blueprint is a mess 20:11:53 was just looking through them 20:12:24 if you have multiple patches on your bp and some have landed, put "-- merged" next to the patch in the whiteboard 20:13:05 oh yes please! 20:13:05 david-lyle, what steps do I need to execute next to get the https://blueprints.launchpad.net/horizon/+spec/fwaas-router-insertion approved for K-3, I have already uploaded a WIP patch set 20:14:25 vishwanathj: I'm willing to consider it, but the dependencies haven't merged. also get amotoki on board to review it 20:14:47 The neutron side of the blueprint will merge either late this week or early next week, all our pending pieces for horizon will be complete in the next couple days 20:14:56 trouble is we're very overloaded and this is coming very late 20:15:14 david-lyle, completely understand 20:15:29 next week will be the end of k-3 20:15:35 got some great help from absubram to get started in a short time 20:16:05 once it lands ping me and we can talk about it 20:16:17 david_lyle, thanks a bunch 20:17:41 I'll start walking through the patches, at this point WIP is not enough, and reviewers need to focus on items that don't have a bunch of work left to complete 20:18:30 unless the priority is high, but the WIP needs to move to Ready for Review quickly 20:19:53 There were no items added to the agenda, so I'll open it up 20:20:01 #topic Open Discussion 20:20:47 I'd like to thank folks, especially cores for the quick turnaround of late on reviewing/approving stuff. 20:20:48 there was dicussion about better error messages/exception handling today in IRC 20:21:10 I know we've had a blueprint open for that for a while, but it's still an issue 20:21:13 https://blueprints.launchpad.net/horizon/+spec/improve-error-message-details-for-usability 20:21:19 ^^ relevant 20:21:21 maybe worth a summit session? 20:21:26 yeah, that's it robcresswell 20:21:37 yes, we need to talk about that 20:21:49 or even a smaller work item for the summit 20:21:52 sure, add it 20:21:59 Would definitely like to follow up on this as we move into Liberty. At the very least, I think a good start would be to start properly handling different exceptions and throw specific errors per exception 20:22:14 With generic fallbacks 20:22:15 we won't solve for K anyway 20:22:16 mrunge: you have a suggestion to divide it off smaller? 20:22:25 * mrunge adding that now 20:22:36 I guess I partly wanted revisit just to make sure we are all still onboard with no exception showing 20:22:51 the main reason for limited progress on that is lack of options 20:23:02 doug-fish, I would assume, it doesn't need all attendees, but should come up with a rule or a conclusion 20:23:11 to put it down somewhere in the wiki 20:23:21 sure - we could do that in short order I think 20:23:28 yes 20:23:38 coming up with a direction for improvement - there's the challenge 20:24:15 mrunge: can you share the wiki you started again for the summit? 20:24:15 at least, we have a few ideas there :D 20:24:36 david-lyle, YOU started: https://etherpad.openstack.org/p/horizon-liberty-summit 20:24:44 and I added stuff ;-) 20:24:45 oh sure, blame me 20:24:48 :) 20:24:59 will do 20:25:06 thanks! 20:25:50 david-lyle, for the summit, we should come up with some kind of plan, what to discuss and whom to pull in 20:26:11 at least some companies might want to know, who to send there 20:26:22 mrunge: yes, I don't have final word on the allotment of slots we ended up with 20:26:31 ah, I see 20:26:35 maybe all that I requested 20:26:40 not sure 20:26:45 would be very cool 20:26:52 when do you find out? 20:26:56 either way, we can make time 20:27:03 TravT: not sure that either 20:27:07 on the other side, not every topic needs all people involved 20:27:18 schedule actually has been earlier than years past 20:28:02 but with the changing format of sessions created need earlier for room configurations 20:28:16 usually the newly elected PTL makes all those calls 20:28:26 david-lyle: btw, any news on getting our own requirements? just wondering where we are 20:28:49 tqtran_: no, although I had a hair-brained idea about that today 20:29:23 hair brained ideas can lead to good things... 20:29:33 lets hear it lol 20:29:50 what if instead of 20 xstatic packages, we created 1 vendor package with versioned requirements in it, that contained all our js dependency packages 20:30:10 then we have one openstack/requirements package to include 20:30:32 it's messier, but from a packaging standpoint potentially less so, or the same 20:30:35 interesting, we'd still have to ask infra for approval each time, right 20:30:43 that wouldn't be able to get packaged 20:30:58 mrunge: horizon was 20:31:01 because of bundling stuff 20:31:09 as an exception 20:31:26 yeah, there are a lot of issues with it 20:31:27 but now that we solved that, distros wouldn't allow that back 20:31:55 well at least one distro just dropped us do to the package proliferation 20:31:58 any updates on bower that anybody knows about? 20:31:59 *due 20:32:22 there is no pleasing everyone 20:32:32 but everyone miserable, isn't ideal 20:32:47 but i've heard that misery loves company 20:32:58 ;-) 20:32:58 TravT: well we aren't lonely 20:33:36 there are some ideas on bower and there's https://review.openstack.org/#/c/154297/ 20:33:38 tqtran_: the problem with our own requirements is that it still requires all the same license and vendor checks 20:33:49 that's openstack_infra speck for bower 20:34:16 mattfarina: can you add to that etherpad? I just added a bullet for this topic 20:34:32 k 20:35:09 infra seems to be open to bower if we can get the mirroring solved. going out to the net for bower and GitHub (to download the packages) regularly fails and they won't try it for Horizon 20:35:34 yup, there needs to be a mirror 20:36:21 since we have time, I'd also like to talk about Horizon as we move to the big tent 20:36:31 there needs to be 2 mirrors. One mirror of bower (the registry) and another mirror for the code (which lives separately from bower) 20:36:55 nothing 4 mirrors can't fix 20:36:58 :) 20:37:08 in each AZ of each host 20:37:15 glad cloud is about scale 20:37:53 Every problem can be solved by another level of indirection... 20:38:13 I think the breadth of horizon is getting beyond our ability to deliver on 20:38:36 yes! 20:38:43 there are too many projects we support 20:39:01 and i think vendors want to have their own projects be easily worked into horizon 20:39:25 in the future, and this will be discussed extensively at the summit, there will be even more projects 20:40:12 so, can we go to a module approach? where there's a base platform that can be easily extended? 20:40:14 and "private" projects within a given org 20:40:19 I propose moving some project plugins out into the openstack namespace/ecosystem 20:40:41 mattfarina, already noted for summit 20:41:01 so, like there are clients for different projects there are horizon add-ins to support different services? 20:41:29 that might be a way 20:41:39 which projects? 20:41:41 I was thinking in the same direction 20:41:44 yes and they are full members of the eco-system, just not coexistent in the Horizon code 20:41:49 probably something like tuskar-ui? 20:42:01 lhcheng: exactly 20:42:18 but maybe with a slightly different core group 20:42:35 the three projects that immediately come to mind are Trove, Sahara, and Hear 20:42:39 *Heat 20:42:47 yes! 20:42:56 david-lyle: don't they have their own core group? or does Ana and Radomir need to +1 them? 20:43:05 *+A 20:43:05 they are actually very isolated from an API standpoint 20:43:29 lhcheng: trying to remember 20:43:41 for tripleo? 20:43:55 i think all horizon cores are core in triple-o 20:44:08 tuskar-ui has a blended core 20:44:14 but they need currently just a single +2 and a+ 20:44:32 if I'm not completely wrong here 20:44:39 yes, because, the horizon core could not take on that load either 20:45:08 and the attention there has waned 20:45:47 I think we need to provide style guides and tools for these projects to move forward 20:46:12 but absorbing a full releases worth of features on rapidly growing/changing projects is very difficult 20:46:28 it's also very tedious and slow for those projects waiting on us 20:47:25 projects are mostly python projects. we're moving away from that quite fast 20:47:31 we don't have any support for ironic going into Kilo in Horizon even though it is in the integrated release 20:47:36 are you envision a plugin model like cinder/nova/neutron? 20:47:47 doug-fish: we have a plugin model 20:47:53 we just have to use it 20:48:00 Agreed 20:48:02 we do internally 20:48:13 panels/dashboards right? 20:48:18 we are using it 20:48:20 projects, admin and identity are plugins 20:48:25 is the plugin model documented somewhere? 20:48:30 they are just all in the same code base 20:48:32 i think it can be expanded on as well 20:48:36 sure, it's all in the wiki 20:48:47 it's also in the developer docs 20:48:50 mattfarina: in the horizon docs 20:48:54 what wchrisj said 20:49:11 but you can not replace single panels or override single tables 20:49:15 there's even a tutorial now 20:49:31 mrunge: single panels yes, single tables, no 20:49:35 at least not that easy. 20:50:16 we should continue to expand the pluggability to finer grained elements 20:50:21 david-lyle: i think it would be great to spend more time in strengthening to plugin model, especially for angular usage 20:50:31 What TravT said 20:50:32 david-lyle: yeah that's what I was hoping for 20:50:37 david-lyle: would it help to take the tutorial that's there and expand it to use the plugin model? 20:50:38 yes, 20:50:47 david-lyle: and that will be easier to do if we are able to focus on less projects overall like you suggest 20:50:49 wchrisj, sure! 20:50:54 yes, and I believe we've started some of that work with Launch instance 20:50:56 I can do that 20:51:06 as a first effort 20:51:27 wchrisj, just go ahead, that's awesome 20:51:33 Done. 20:51:34 sure 20:51:38 david-lyle: yep. 20:51:39 if there are more projects not part of the core it would force the plugin model to work for them and provide multiple public cases testing it 20:51:50 does the current plugin model support dashboard/panels that live in a separate package? 20:51:58 esp yes 20:52:05 david-lyle: nice 20:52:09 I have a demo package somewher 20:52:10 e 20:52:19 I’d prefer moving toward something like that 20:52:19 plus monasca-ui and tuskar-ui 20:52:37 but then I guess we have the problem of versioning 20:52:42 https://github.com/dklyle/mon-ext 20:52:45 Along these lines, this is the kind of thing I wanted to be dealing with pre-summit as well. I'm thinking probably a big meetup will be hard to do pre-liberty, but maybe we can run some virtual sprints on these topic areas. 20:53:46 esp: that's what I'm suggesting :) 20:53:56 good stuff 20:54:18 openstack/requirements should help with dependency consistency 20:54:28 and we can focus on the core of Horizon 20:54:35 k 20:54:37 fwiw, here's the doc on the plugin settings: https://github.com/openstack/horizon/blob/master/doc/source/topics/settings.rst#pluggable-settings 20:54:46 the workflows that require cross-stack coordination 20:54:58 and docs and examples 20:55:10 thx wchrisj 20:55:23 murano will be here soon and manila and those should be plugins 20:55:25 as well 20:55:54 consistent UX will be the biggest issue and we'll need to work with them on that 20:56:01 more to the pain points: are we removing stuff? 20:56:09 like trove or sahara? 20:56:16 move to plugins? 20:56:22 and heat, that's what I'm suggesting 20:56:36 router dashboard? 20:56:41 ceilometer will be valuable cross-stack when ready 20:56:45 mrunge: +1000 20:56:56 haha 20:57:00 even neutron? 20:57:06 thats a whole lot of approval. 20:57:27 given, that it's only covered by a very few people? 20:57:28 additionally, there could be extensions that just focus on nova if desired 20:57:48 mrunge: I think neutron is central to what we need to support 20:57:58 agreed david-lyle 20:58:16 but in reality, only amotoki really understands, what's going on there 20:58:19 with less context switching, maybe more can focus there 20:58:36 david-lyle: i really like the spirit of what you are saying 20:58:37 we need to work more proactively with the neutron team 20:58:42 but.. 20:58:49 :D 20:59:19 agreed. removing that would be too painful 20:59:59 I thought that was the set up punch TravT, I waiting for the haymaker 21:00:11 david-lyle: no, that's pretty much it... 21:00:28 maybe just, the devil is in deciding what is in and out. 21:00:40 first round is easy I think 21:00:47 let's toss a coin 21:00:53 not to blame a devil 21:00:55 the PaaS layer essentially 21:01:09 we've also run into some things on launch instance within projects 21:01:44 for example, network profile support which appears to come all the way back too if something = 'cisco' 21:02:14 That shouldn't be there, it needs to be a general solution 21:02:22 yes. I could assume other features added by vendors to inflict with launch instance 21:02:26 and an appropriate extension point for our cisco friends 21:02:43 like more scheduling 21:02:55 different scheduling, 21:02:56 yes, launch should probably allow extensions for more steps 21:03:00 yep 21:03:01 nova extensions 21:03:06 well it definitely should 21:03:33 we're over time, and I'm not sure if someones waiting for the room 21:03:34 that was the idea from the begining... but with the idea that we solve the concrete of what is there now and work on better extensibility 21:03:35 can we move that discussion to #horizon? 21:03:38 Someone ? 21:03:55 probably the better choice mrunge 21:04:07 moving to horizon room 21:04:12 thanks! 21:04:13 Thanks everyone! 21:04:17 #endmeeting