12:01:15 #startmeeting Horizon 12:01:16 Meeting started Wed Jun 10 12:01:15 2015 UTC and is due to finish in 60 minutes. The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:01:20 The meeting name has been set to 'horizon' 12:01:24 who's around? 12:01:36 o/ 12:01:38 * doug-fish raises hand 12:01:41 o/ 12:01:47 o/ 12:01:58 \o 12:02:02 o/ 12:02:39 ok, let's get started 12:02:47 \o 12:03:02 First some follow up 12:03:24 I'm still working on pinning down a time and date for the midcycle 12:03:42 we had a bit of misdirection late last week that set back the process a bit 12:04:31 that's cleared up and now we're still trying to coordinate with glance and searchlight to co-locate 12:04:40 david-lyle, is there an option to move it to September? 12:04:46 https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=0 12:05:14 mrunge: I suppose that's an option, but that feels a little late 12:05:24 at least some folks will need a visa for US 12:05:32 unless we intend it as a cleanup item 12:05:55 and July/August is main vacation time, that will hit one or the other 12:06:09 We'll only need an ESTA, I thought, and the turnaround for those is very fast 12:06:09 mrunge: honestly hadn't considered visas, TBH 12:06:57 if we do july, we're leaning toward the later date due to the delays in planning 12:06:58 robcresswell, at least I heared about folks having an issue to get to Canada, which is more liberal with visa than US is 12:07:17 later July is in parallel with Europython conference 12:07:43 the other option is we don't co-located with glance 12:07:52 that increases flexibility 12:08:25 mrunge: I'm unsure, but I thought Germany was also able to get an esta under the visa waiver program,and that has a turnaround of.. hours, basically. 12:08:29 BTW, searchlight was voted into OpenStack yesterday \o/ 12:08:37 oh awesome 12:08:39 cool 12:08:43 yay 12:08:47 congrats to Trav then 12:08:52 robcresswell, for Germany, it shouldn't be such an issue with Esta 12:09:10 and the overlap of people between glance and horizon was the reason for the co-location 12:09:30 but if searchlight midcycle is done online, it may not be an issue 12:09:50 searchlight is the one I'm interested in :) 12:09:51 o/ hope you dont mind me coming along to the meeting! New to contributing and code reviews but up for doing more for sure! 12:10:06 bethelwell: You are more than welcome :) 12:10:15 welcome bethelwell 12:10:20 thank you!! 12:11:01 ok, summary midcycle still a WIP 12:11:10 but work is happening :) 12:11:25 +2 great :D 12:11:36 Awesome. Thanks! 12:12:41 I like that Cambridge, MA is an option for location :) 12:12:49 yes! 12:13:35 now looking at our top priority items for Liberty 12:14:04 #link https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities 12:14:33 there is progress on all front on the technical debt section which is good 12:15:11 Thai has a patch up for moving horizon translation to be babel based 12:15:31 I don't have the link handy, but more feedback on that would be great 12:15:45 for plugins 12:15:51 I'm working on that 12:15:58 babel patch is https://review.openstack.org/#/c/188665/ 12:16:24 I'm attempting to move sahara to /contrib and define a structure and testing strategy, it needs more work 12:16:29 thanks neillc 12:16:50 I want to base the documentation off a working model 12:16:53 There is a query from the trandlation team that could use an answer from someone more expert than me 12:17:20 do we want openstack_dashboard and horizon i18n kept separate or can they be combined? 12:18:24 in theory they should stay separate, but I think we're drifting in an in separable horizon/openstack_dashboard with proposed reOrg changes 12:18:33 Do we gain anything from combining them? IMO we should just keep them apart, if we decide to seperate properly later on. 12:18:46 translation team want them combined 12:19:01 so if we give up the idea of having any separability of the two sides, we could combine 12:19:05 Interesting. What was their reasoning? 12:19:13 robcresswell: we are different 12:19:16 different is hard 12:19:19 "Neill, there's no reason for the translators to translate separately. Merging it would be nice from a CI infra point of view. Let's bring this to Steve's attention who's currently working on these scripts for our move to Zanata." 12:19:43 we're going to need at least to files anyway - one for js and one for python 12:20:12 doug-fish, I think it should work with a single file 12:20:21 at least it worked in the past 12:20:30 doug-fish: don't those get squashed currently 12:20:32 not claiming, it will work with angular 12:20:33 I don't know enough to have a firm opinion, but I thought we would probably prefer to keep them separate 12:20:35 that will make our js file much bigger than it needs to be 12:21:00 I'm inclined to say keep them apart, since at the moment there is a lot of work specifically targetted at splitting horizon and the dashboard JS 12:21:16 It seems counter productive to merge translations... but I am by no means an expert on this. 12:22:01 robcresswell, for translation team, it seems to be counter productive to have 2 (or 4), when counting js, too 12:22:29 are there implications for third party customisations? 12:22:49 true but from what i can see is it not counter productive also to have fewer but bloated js files? 12:22:52 mrunge: This is true, but I'm unsure how much it alters their workload to combine 12:23:24 I'd say: no. third party modules still should work 12:24:18 please leave feedback on the review and we can continue the discussion there 12:24:59 Will do 12:25:31 session clean up is stalled I think 12:25:37 will reboot 12:26:05 jscs enforcement is in progress as well (how is that a top priority)? 12:26:27 auto-collecting JS files has a patch up 12:27:00 there is also work on the webroot bug 12:27:12 so we are making progress 12:27:19 lots to land though 12:27:34 I did make a change on the priority list 12:27:41 that I should discuss 12:28:14 I have moved the details views down in priority and wider coverage of angularized tables up 12:28:34 we're doing a tremendous amount of work to improve UX and scalability 12:28:49 Seems sensible 12:28:55 I would like us to realize those benefits in the most needed places first 12:29:13 details views could be better, but much less overall improvement 12:29:26 plus too many different things in flight is just chaos 12:29:40 and I'm going nuts trying to track all of it 12:30:35 david-lyle: Anything we can do to help out? 12:31:10 robcresswell: I'm just trying to make sure we can land things 12:31:20 that was what i was about to say. I am currently having a lot of downtime and some evenings free so if there are specific code reviews or FE things you need doing urgently feel free to ping me 12:31:35 if we split reviewers across too broad a spectrum we won't land much 12:32:06 david-lyle, re moving sahara to contrib/ how it'll help with reviews? dir-based core teams? 12:32:21 david-lyle: that makes sense. is there a priority order in place? 12:32:28 Oh that reminds me. I have a small nag. Can people merging code please make sure to prioritise and target bugs? I think that makes it easier to see what is going on. 12:33:04 I've been going through anything commited and filling it in, but its not ideal to have just my opinion on its priority :/ 12:33:04 robcresswell, not everyone can target bugs and prioritize them 12:33:28 mrunge: I thought all cores could? And they will be the ones merging code? 12:33:28 robcresswell++ thanks for doing that! 12:33:42 SergeyLukjanov: the idea is to allow for more impactful review from the sahara team itself 12:33:48 robcresswell, yes, that's correct 12:34:08 if we isolate the sahara related changes, we can take service team voting to be one of the +2s 12:34:28 and then just have one horizon core +2 and +A 12:34:46 the idea is actually to speed up development 12:34:50 david-lyle, it'll be really great! because mostly all of our patches are now need to be on review for a few month to be merged :( 12:34:57 knowing that those reviews get starved 12:35:03 yes 12:35:03 david-lyle: would this be the goal for all the ‘plugins’? 12:35:28 Sahara, Trove and Heat would all fall in the same model 12:35:48 but I picked Sahara to start because your team is very active with patches 12:35:56 david-lyle, so, you prefer the way to keep em in contrib/ ? 12:35:58 and I want that progress in tree 12:36:13 david-lyle, I mean comparing to external plugins for example 12:36:25 it's a way to isolate them for now 12:36:45 SergeyLukjanov: eventually we might want to move them out of tree, but that was more than I wanted to take on for Liberty 12:36:54 david-lyle, yeah, I think it could helps both of our teams a lot - to make sahara changes landing faster and to decrease number of reviews for horizon team 12:37:10 there are integration tests and other things that need to be worked out 12:37:25 david-lyle, yeah, integration tests are painful 12:37:29 in tree for now makes the testing strategy much simpler 12:37:41 david-lyle, got the idea about contrib/ and looking forward for it, thank you! 12:37:59 SergeyLukjanov: thanks 12:38:28 absubram: for things not in tree already, they are staying out of tree 12:38:36 david-lyle: can we granularize a little on what we are trying to accompolish via the plugins.. Rob and I were talking about this yesterday.. What would be the items that constitue a plugin firstly? You just mentioned Sahara, Trove and Heat.. would all of the networking components be their own plugin as well? 12:38:45 designate and manila are a couple of examples 12:38:53 magnum will be another 12:40:04 absubram: there's no reason we couldn't organize them as plugins, but I'm not looking to shift the networking part yet 12:40:14 ok.. 12:40:27 One thing I wanted to clear up is whether the plugin work will include extending the levels at which plugins can insert code, so workflows etc 12:40:31 so no seperate plugins for launch instance or create networks :p 12:40:44 things like launch instance and topology views become terribly complex if you have separated code for networking and compyte 12:40:45 david-lyle, what about murano-dashboard? From the view of ensuring things don't break with new horizon release it seems reasonable... 12:41:07 david-lyle: makes sense.. 12:41:18 robcreswell: +1.. it’s what I’d like to know too! 12:41:18 I mean, placing it into contrib/ to run the tests against it 12:41:47 tsufiev: well part of what I need to work to define is a testing strategy for plugins out of tree 12:42:10 even if they are non-voting jobs on horizon tests 12:42:43 robcresswell: yes it should include that, but that's a bit off in the distance for now 12:43:01 david-lyle, sure! I'll forward this concern to Murano team, perhaps could use their help 12:43:14 my first priority is remove horizon as the bottleneck for all ui code 12:43:44 next broaden what a plugin can do 12:43:58 david-lyle: I like your approach. We are taking the similar model as tempest tries to do. 12:44:05 as you may know, tempest will have tests only for projects of core projects in "defcore" + neutron in Liberty. 12:44:24 amotoki: yes and devstack is making a similar move 12:44:27 Yeah, biggest blocker to me ripping out all the cisco bits is that we can't make it pluggable yet. The router dashboard will be removed soon. 12:44:51 But we have no mechanism for getting in the workflows without editing code, which will leave me in rebase-hell on an outside repo. 12:45:07 robcresswell: I think we need to explore how we can define hooks or similar framework to support verndor specific logics. 12:45:13 robcresswell: if you would like to take a pass at that functionality of plugins, I don't think it would collide with what I'm doing 12:45:16 we can explore it during Liberty cycle :-) 12:45:42 david-lyle, amotoki: I'm more than happy to have a go at that. Will do once the router bit is in its own repo. 12:45:49 amotoki: robcresswell: +1 12:45:56 robcresswell: thanks 12:46:27 I think we just covered the only agenda item :P 12:46:33 absubram: was there more ? 12:47:05 If anyone has suggestions, or had written similar functionality before, advice is welcome :) 12:47:07 david-lyle: haha yeah the hooks to the workflows was what I had wanted to bring up 12:47:33 Regarding the vendor split - based on some of the feedback from the summit, we can do a neutron extension detection (very similar to what we already do for the firewall and vpn panels).. and if the extension is detected, which means the neutron vendor plugin is being used, the dashboard can be configured to have the specific vendor support… 12:48:26 The complication is in the workflow code that is being used in the existing launch instance and create networks and create firewalls.. the vendor stuff needs that code.. so the idea is to have a separate workflow that could perhaps be inherited by the common workflow when the extension is supported? 12:48:40 Then the vendor code could theoretically reside in it’s own separate bubble.. outside of the common workflow file.. there might still be some lines we need included to detect settings/configs etc for the vendors.. would that be ok? 12:48:47 absubram: Is this the stevedore idea? Discovering plugins that are installed... 12:49:19 rob: not exactly.. stevedore in neutron directs the plugin packages 12:49:30 Ah, sorry 12:49:32 I don’t think we should have a pip install 12:49:46 in horizon for the small amount of vendor code :) 12:49:53 it’s like the firewalls panel 12:49:55 robcresswell, to me that is similar to the hooks idea 12:50:08 absubram: I think the discussion can be split into several parts: how to detect available features, how to customize horizon UI (insert something or change something). 12:50:27 amotoki: sounds good 12:50:33 for the first part, you can use vendor python package too, but the second point is more important. 12:50:35 I’ll bring up the discussions in the mailer? 12:51:03 i have no idea on a specific plan though. 12:51:09 amotoki: Agreed, they are seperate points. 12:51:13 amotoki: big +1.. that’s the part I don’t have any proper ideas on currently 12:51:37 so that's the reason I said we can explore it in Liberty cycle :-) 12:51:45 lol yes 12:51:55 So I have a few items first, like remove the existing dashboard, and sort out the angular docs. Then I will start looking into pluggable workflows, or something along those lines. 12:52:17 thanks Rob! 12:52:19 robcresswell: sure, take all the easy stuff ;) 12:52:24 lol! 12:52:33 robcresswell: +1 12:52:35 thanks Rob! 12:52:56 haha 12:53:01 :) 12:53:02 even though I think we've been there for a while 12:53:15 #topic Open Discussion 12:53:28 does anyone have an interest to serve as oslo liaison in Liberty? 12:53:45 I am afraid I cannot spend enough time for the liaison in Liberty cycle and there is a meeting time conflict between oslo and neutron-ironic integration. 12:54:21 I try to do my best but it is better if someone who has more time takes it. 12:54:43 amotoki: feel free to take you name off the wiki (if you haven't) and I'll work on finding someone 12:55:03 May be worth asking Quality, I hear he loves liaison roles 12:55:05 thanks for handling it in Kilo 12:55:07 david-lyle: thanks. will do. 12:55:14 what does it involve akihiro? afraid not suffcient knowledge of oslo on my part :( 12:55:14 amotoki, thank you for your work on that liaison. 12:56:09 absubram: the main missions are to sync oslo libraries with our code base and to join oslo reviews. 12:56:39 and to raise alarms if we have a problem. 12:56:53 absubram: we only use a small percentage of the oslo libraries in Horizon, so the exposure is less 12:56:59 in theory 12:57:40 but still work to stay on top of 12:58:19 haha ok.. thanks.. will sync up with you outside of the meeting, if I think it’s doable.. 12:58:26 sure 12:58:34 we have many cross project liaisons. if you are interested, see https://wiki.openstack.org/wiki/CrossProjectLiaisons 13:00:59 seems QA is available as well :) 13:01:04 times up 13:01:18 have a great week everyone! 13:01:21 thanks all! 13:01:21 #endmeeting