12:01:15 <david-lyle> #startmeeting Horizon
12:01:16 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:20 <openstack> The meeting name has been set to 'horizon'
12:01:24 <david-lyle> who's around?
12:01:36 <robcresswell> o/
12:01:38 * doug-fish raises hand
12:01:41 <mrunge> o/
12:01:47 <neillc> o/
12:01:58 <tsufiev> \o
12:02:02 <absubram> o/
12:02:39 <david-lyle> ok, let's get started
12:02:47 <akrivoka> \o
12:03:02 <david-lyle> First some follow up
12:03:24 <david-lyle> I'm still working on pinning down a time and date for the midcycle
12:03:42 <david-lyle> we had a bit of misdirection late last week that set back the process a bit
12:04:31 <david-lyle> that's cleared up and now we're still trying to coordinate with glance and searchlight to co-locate
12:04:40 <mrunge> david-lyle, is there an option to move it to September?
12:04:46 <david-lyle> https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=0
12:05:14 <david-lyle> mrunge: I suppose that's an option, but that feels a little late
12:05:24 <mrunge> at least some folks will need a visa for US
12:05:32 <david-lyle> unless we intend it as a cleanup item
12:05:55 <mrunge> and July/August is main vacation time, that will hit one or the other
12:06:09 <robcresswell> We'll only need an ESTA, I thought, and the turnaround for those is very fast
12:06:09 <david-lyle> mrunge: honestly hadn't considered visas, TBH
12:06:57 <david-lyle> if we do july, we're leaning toward the later date due to the delays in planning
12:06:58 <mrunge> 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 <mrunge> later July is in parallel with Europython conference
12:07:43 <david-lyle> the other option is we don't co-located with glance
12:07:52 <david-lyle> that increases flexibility
12:08:25 <robcresswell> 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 <david-lyle> BTW, searchlight was voted into OpenStack yesterday \o/
12:08:37 <robcresswell> oh awesome
12:08:39 <doug-fish> cool
12:08:43 <neillc> yay
12:08:47 <robcresswell> congrats to Trav then
12:08:52 <mrunge> robcresswell, for Germany, it shouldn't be such an issue with Esta
12:09:10 <david-lyle> and the overlap of people between glance and horizon was the reason for the co-location
12:09:30 <david-lyle> but if searchlight midcycle is done online, it may not be an issue
12:09:50 <neillc> searchlight is the one I'm interested in :)
12:09:51 <bethelwell> 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 <robcresswell> bethelwell: You are more than welcome :)
12:10:15 <david-lyle> welcome bethelwell
12:10:20 <bethelwell> thank you!!
12:11:01 <david-lyle> ok, summary midcycle still a WIP
12:11:10 <david-lyle> but work is happening :)
12:11:25 <mrunge> +2 great :D
12:11:36 <robcresswell> Awesome. Thanks!
12:12:41 <absubram> I like that Cambridge, MA is an option for location :)
12:12:49 <mrunge> yes!
12:13:35 <david-lyle> now looking at our top priority items for Liberty
12:14:04 <david-lyle> #link https://etherpad.openstack.org/p/YVR-horizon-liberty-priorities
12:14:33 <david-lyle> there is progress on all front on the technical debt section which is good
12:15:11 <david-lyle> Thai has a patch up for moving horizon translation to be babel based
12:15:31 <david-lyle> I don't have the link handy, but more feedback on that would be great
12:15:45 <david-lyle> for plugins
12:15:51 <david-lyle> I'm working on that
12:15:58 <neillc> babel patch is https://review.openstack.org/#/c/188665/
12:16:24 <david-lyle> I'm attempting to move sahara to /contrib and define a structure and testing strategy, it needs more work
12:16:29 <david-lyle> thanks neillc
12:16:50 <david-lyle> I want to base the documentation off a working model
12:16:53 <neillc> There is a query from the trandlation team that could use an answer from someone more expert than me
12:17:20 <neillc> do we want openstack_dashboard and horizon i18n kept separate or can they be combined?
12:18:24 <david-lyle> 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 <robcresswell> 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 <neillc> translation team want them combined
12:19:01 <david-lyle> so if we give up the idea of having any separability of the two sides, we could combine
12:19:05 <robcresswell> Interesting. What was their reasoning?
12:19:13 <david-lyle> robcresswell: we are different
12:19:16 <david-lyle> different is hard
12:19:19 <neillc> "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 <doug-fish> we're going to need at least to files anyway - one for js and one for python
12:20:12 <mrunge> doug-fish, I think it should work with a single file
12:20:21 <mrunge> at least it worked in the past
12:20:30 <david-lyle> doug-fish: don't those get squashed currently
12:20:32 <mrunge> not claiming, it will work with angular
12:20:33 <neillc> I don't know enough to have a firm opinion, but I thought we would probably prefer to keep them separate
12:20:35 <doug-fish> that will make our js file much bigger than it needs to be
12:21:00 <robcresswell> 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 <robcresswell> It seems counter productive to merge translations... but I am by no means an expert on this.
12:22:01 <mrunge> robcresswell, for translation team, it seems to be counter productive to have 2 (or 4), when counting js, too
12:22:29 <neillc> are there implications for third party customisations?
12:22:49 <bethelwell> true but from what i can see is it not counter productive also to have fewer but bloated js files?
12:22:52 <robcresswell> mrunge: This is true, but I'm unsure how much it alters their workload to combine
12:23:24 <mrunge> I'd say: no. third party modules still should work
12:24:18 <david-lyle> please leave feedback on the review and we can continue the discussion there
12:24:59 <robcresswell> Will do
12:25:31 <david-lyle> session clean up is stalled I think
12:25:37 <david-lyle> will reboot
12:26:05 <david-lyle> jscs enforcement is in progress as well (how is that a top priority)?
12:26:27 <david-lyle> auto-collecting JS files has a patch up
12:27:00 <david-lyle> there is also work on the webroot bug
12:27:12 <david-lyle> so we are making progress
12:27:19 <david-lyle> lots to land though
12:27:34 <david-lyle> I did make a change on the priority list
12:27:41 <david-lyle> that I should discuss
12:28:14 <david-lyle> I have moved the details views down in priority and wider coverage of angularized tables up
12:28:34 <david-lyle> we're doing a tremendous amount of work to improve UX and scalability
12:28:49 <robcresswell> Seems sensible
12:28:55 <david-lyle> I would like us to realize those benefits in the most needed places first
12:29:13 <david-lyle> details views could be better, but much less overall improvement
12:29:26 <david-lyle> plus too many different things in flight is just chaos
12:29:40 <david-lyle> and I'm going nuts trying to track all of it
12:30:35 <robcresswell> david-lyle: Anything we can do to help out?
12:31:10 <david-lyle> robcresswell: I'm just trying to make sure we can land things
12:31:20 <bethelwell> 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 <david-lyle> if we split reviewers across too broad a spectrum we won't land much
12:32:06 <SergeyLukjanov> david-lyle, re moving sahara to contrib/ how it'll help with reviews? dir-based core teams?
12:32:21 <bethelwell> david-lyle: that makes sense. is there a priority order in place?
12:32:28 <robcresswell> 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 <robcresswell> 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 <mrunge> robcresswell, not everyone can target bugs and prioritize them
12:33:28 <robcresswell> mrunge: I thought all cores could? And they will be the ones merging code?
12:33:28 <mrunge> robcresswell++ thanks for doing that!
12:33:42 <david-lyle> SergeyLukjanov: the idea is to allow for more impactful review from the sahara team itself
12:33:48 <mrunge> robcresswell, yes, that's correct
12:34:08 <david-lyle> if we isolate the sahara related changes, we can take service team voting to be one of the +2s
12:34:28 <david-lyle> and then just have one horizon core +2 and +A
12:34:46 <david-lyle> the idea is actually to speed up development
12:34:50 <SergeyLukjanov> 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 <david-lyle> knowing that those reviews get starved
12:35:03 <david-lyle> yes
12:35:03 <absubram> david-lyle: would this be the goal for all the ‘plugins’?
12:35:28 <david-lyle> Sahara, Trove and Heat would all fall in the same model
12:35:48 <david-lyle> but I picked Sahara to start because your team is very active with patches
12:35:56 <SergeyLukjanov> david-lyle, so, you prefer the way to keep em in contrib/ ?
12:35:58 <david-lyle> and I want that progress in tree
12:36:13 <SergeyLukjanov> david-lyle, I mean comparing to external plugins for example
12:36:25 <david-lyle> it's a way to isolate them for now
12:36:45 <david-lyle> 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 <SergeyLukjanov> 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 <david-lyle> there are integration tests and other things that need to be worked out
12:37:25 <SergeyLukjanov> david-lyle, yeah, integration tests are painful
12:37:29 <david-lyle> in tree for now makes the testing strategy much simpler
12:37:41 <SergeyLukjanov> david-lyle, got the idea about contrib/ and looking forward for it, thank you!
12:37:59 <david-lyle> SergeyLukjanov: thanks
12:38:28 <david-lyle> absubram: for things not in tree already, they are staying out of tree
12:38:36 <absubram> 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 <david-lyle> designate and manila are a couple of examples
12:38:53 <david-lyle> magnum will be another
12:40:04 <david-lyle> 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 <absubram> ok..
12:40:27 <robcresswell> 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 <absubram> so no seperate plugins for launch instance or create networks :p
12:40:44 <david-lyle> things like launch instance and topology views become terribly complex if you have separated code for networking and compyte
12:40:45 <tsufiev> 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 <absubram> david-lyle: makes sense..
12:41:18 <absubram> robcreswell: +1.. it’s what I’d like to know too!
12:41:18 <tsufiev> I mean, placing it into contrib/ to run the tests against it
12:41:47 <david-lyle> tsufiev: well part of what I need to work to define is a testing strategy for plugins out of tree
12:42:10 <david-lyle> even if they are non-voting jobs on horizon tests
12:42:43 <david-lyle> robcresswell: yes it should include that, but that's a bit off in the distance for now
12:43:01 <tsufiev> david-lyle, sure! I'll forward this concern to Murano team, perhaps could use their help
12:43:14 <david-lyle> my first priority is remove horizon as the bottleneck for all ui code
12:43:44 <david-lyle> next broaden what a plugin can do
12:43:58 <amotoki> david-lyle: I like your approach. We are taking the similar model as tempest tries to do.
12:44:05 <amotoki> as you may know,  tempest will have tests only for projects of core projects in "defcore" + neutron in Liberty.
12:44:24 <david-lyle> amotoki: yes and devstack is making a similar move
12:44:27 <robcresswell> 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 <robcresswell> 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 <amotoki> robcresswell: I think we need to explore how we can define hooks or similar framework to support verndor specific logics.
12:45:13 <david-lyle> 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 <amotoki> we can explore it during Liberty cycle :-)
12:45:42 <robcresswell> 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 <absubram> amotoki: robcresswell: +1
12:45:56 <david-lyle> robcresswell: thanks
12:46:27 <david-lyle> I think we just covered the only agenda item :P
12:46:33 <david-lyle> absubram: was there more ?
12:47:05 <robcresswell> If anyone has suggestions, or had written similar functionality before, advice is welcome :)
12:47:07 <absubram> david-lyle: haha yeah the hooks to the workflows was what I had wanted to bring up
12:47:33 <absubram> 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 <absubram> 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 <absubram> 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 <robcresswell> absubram: Is this the stevedore idea? Discovering plugins that are installed...
12:49:19 <absubram> rob: not exactly.. stevedore in neutron directs the plugin packages
12:49:30 <robcresswell> Ah, sorry
12:49:32 <absubram> I don’t think we should have a pip install <vendor-package>
12:49:46 <absubram> in horizon for the small amount of vendor code :)
12:49:53 <absubram> it’s like the firewalls panel
12:49:55 <tsufiev> robcresswell, to me that is similar to the hooks idea
12:50:08 <amotoki> 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 <absubram> amotoki: sounds good
12:50:33 <amotoki> for the first part, you can use vendor python package too, but the second point is more important.
12:50:35 <absubram> I’ll bring up the discussions in the mailer?
12:51:03 <amotoki> i have no idea on a specific plan though.
12:51:09 <robcresswell> amotoki: Agreed, they are seperate points.
12:51:13 <absubram> amotoki: big +1.. that’s the part I don’t have any proper ideas on currently
12:51:37 <amotoki> so that's the reason I said we can explore it in Liberty cycle :-)
12:51:45 <absubram> lol yes
12:51:55 <robcresswell> 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 <absubram> thanks Rob!
12:52:19 <david-lyle> robcresswell: sure, take all the easy stuff ;)
12:52:24 <absubram> lol!
12:52:33 <amotoki> robcresswell: +1
12:52:35 <david-lyle> thanks Rob!
12:52:56 <robcresswell> haha
12:53:01 <robcresswell> :)
12:53:02 <david-lyle> even though I think we've been there for a while
12:53:15 <david-lyle> #topic Open Discussion
12:53:28 <amotoki> does anyone have an interest to serve as oslo liaison in Liberty?
12:53:45 <amotoki> 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 <amotoki> I try to do my best but it is better if someone who has more time takes it.
12:54:43 <david-lyle> amotoki: feel free to take you name off the wiki (if you haven't) and I'll work on finding someone
12:55:03 <robcresswell> May be worth asking Quality, I hear he loves liaison roles
12:55:05 <david-lyle> thanks for handling it in Kilo
12:55:07 <amotoki> david-lyle: thanks. will do.
12:55:14 <absubram> what does it involve akihiro? afraid not suffcient knowledge of oslo on my part :(
12:55:14 <mrunge> amotoki, thank you for your work on that liaison.
12:56:09 <amotoki> absubram: the main missions are to sync oslo libraries with our code base and to join oslo reviews.
12:56:39 <amotoki> and to raise alarms if we have a problem.
12:56:53 <david-lyle> absubram: we only use a small percentage of the oslo libraries in Horizon, so the exposure is less
12:56:59 <david-lyle> in theory
12:57:40 <david-lyle> but still work to stay on top of
12:58:19 <absubram> haha ok.. thanks.. will sync up with you outside of the meeting, if I think it’s doable..
12:58:26 <david-lyle> sure
12:58:34 <amotoki> we have many cross project liaisons. if you are interested, see https://wiki.openstack.org/wiki/CrossProjectLiaisons
13:00:59 <david-lyle> seems QA is available as well :)
13:01:04 <david-lyle> times up
13:01:18 <david-lyle> have a great week everyone!
13:01:21 <absubram> thanks all!
13:01:21 <david-lyle> #endmeeting