12:01:08 <david-lyle> #startmeeting Horizon
12:01:09 <openstack> Meeting started Wed Nov 25 12:01:08 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:10 <mrunge> hey amotoki o/
12:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:13 <openstack> The meeting name has been set to 'horizon'
12:01:33 <tsufiev> O/
12:01:43 <r1chardj0n3s> o/
12:02:06 <omer_etrog> o/
12:02:07 <jasondotstar> o/
12:02:14 <masco> o/
12:04:04 <david-lyle> Hello all
12:04:15 <david-lyle> we had a bug day yesterday
12:04:22 <masco> hello
12:05:07 <david-lyle> Looks like robcresswell just sent the results to the dev ML
12:05:27 <r1chardj0n3s> oh cool. I've been away from work(ish) today so I've not caught up
12:05:57 <david-lyle> 140 bugs categorized and 50 marked no longer valid
12:06:00 <mrunge> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080467.html
12:06:01 <tsufiev> I got a feeling that we need bug week instead :)
12:06:33 <r1chardj0n3s> definitely worth doing more
12:06:45 <mrunge> I had the impression, that must have been more bugs invalidated
12:06:47 <r1chardj0n3s> I gotta learn not to get bogged down on one or two bugs ;-)
12:07:18 <masco> we can have a bug day for every week
12:07:34 <masco> still we reach some decent number
12:08:11 <david-lyle> I think it's good progress
12:08:22 <david-lyle> agree that we have more coming
12:08:34 <david-lyle> s/coming/to do/
12:09:02 <david-lyle> thanks to robcresswell for organizing
12:09:14 <kzaitsev_mb> Maybe a bug week would be a better solution? =) Given the fact that people live in different time-zone a more broad time-spawn for such an event might be beneficial.
12:09:50 <mrunge> I don't think, that's a real issue
12:10:13 <robcresswell> I'm kind of half here. I think the occasional day is a good focus point. Nobody can spare a week, but a day every month or so?
12:10:15 <r1chardj0n3s> kzaitsev_mb: what about the timezones did you think didn't work?
12:10:18 <tsufiev> kzaitsev_ws, on the other hand, scrubbing bugs for the whole week would be boring
12:10:26 <robcresswell> tsufiev: +1
12:10:27 <david-lyle> kzaitsev_mb: I'd rather have days separated. I think people would lose interest and focus over a longer of period of time
12:10:35 <r1chardj0n3s> tsufiev: +1
12:10:49 <david-lyle> or what tsufiev said
12:10:58 <omer_etrog> tsufiev: +1
12:11:27 <masco> tsufiev, yes, even the whole day is kind of boring ;)
12:11:55 * tsufiev acting in role of Captain Obvious :)
12:12:29 <david-lyle> #topic priority review
12:12:44 <david-lyle> #link https://etherpad.openstack.org/p/mitaka-horizon-priorities
12:14:21 <david-lyle> For plugins, documentation is blocked on me
12:14:35 <david-lyle> still writing, hope to post today
12:14:56 <david-lyle> localization, not sure any work is being done
12:15:05 <david-lyle> localization for plugins that is
12:16:02 <david-lyle> adding angular content
12:16:48 <david-lyle> seems several patches have merged, but much of the meat has not
12:17:07 <robcresswell> I know on the images stuff Travis was helping them out on the APIs still
12:17:58 <david-lyle> theming docs have landed
12:18:27 <david-lyle> pbr spec is still WIP, correct r1chardj0n3s
12:18:29 <david-lyle> ?
12:18:39 <david-lyle> I need to review the latest revision
12:18:54 <r1chardj0n3s> yeah, I poked at Monty today to try to get it moving, he said to poke Robert :/
12:19:06 <david-lyle> ok
12:19:07 <r1chardj0n3s> I'm not sure what else I can do to get that thing moving
12:19:41 <r1chardj0n3s> (I don't feel right hassling Robert so much, but pbr has no other reviewers AFAICT)
12:20:37 <david-lyle> I think it's moving as fast as it will
12:20:49 <r1chardj0n3s> yeah
12:21:44 <david-lyle> I also started splitting out Sahara content
12:22:13 <tsufiev> david-lyle, right now I'm talking with our Sahara guys about moving integration tests to sahara-dashboard
12:22:17 <david-lyle> that needs some more work on the destination side by me
12:22:38 <david-lyle> tsufiev: great, I didn't get to a plan on that
12:22:54 <r1chardj0n3s> looks like phantomjs is about to merge, thanks reviewers!
12:22:54 <david-lyle> although with the use of run_tests.sh in the destination repo
12:23:09 <r1chardj0n3s> next up is merging the webdrivers, which tsufiev will love to review! :-)
12:23:14 <david-lyle> I think I may have an idea
12:23:24 <tsufiev> r1chardj0n3s, yes, it's in my queue
12:24:10 <david-lyle> any other priority items I missed?
12:24:55 <david-lyle> ok, moving on the the agenda
12:24:59 <david-lyle> #link https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_for_November_25
12:25:23 <david-lyle> #topic weekly bug report
12:25:27 <david-lyle> #link https://wiki.openstack.org/wiki/Horizon/WeeklyBugReport
12:27:01 <r1chardj0n3s> so Diana's patches are all gated on the HTML unit testing patch <https://review.openstack.org/#/c/246549/> that could probably use some thought from more folks
12:27:35 <r1chardj0n3s> switching over to DOM-based testing has altered the scope of the tests, and we just need to be cool with that, or add additional tests to cover the bits lost in the translation
12:28:20 * david-lyle needs to look at that patch
12:28:43 <david-lyle> #topic Horizon and django-debreach
12:29:06 <tsufiev> I added this topic
12:29:43 <tsufiev> so, there is a specific django app proposed for adding to requirements.txt and horizon config
12:30:20 <tsufiev> it's used for mitigating BREACH attack, which AFAIU could be used to steal some cookie data from HTTPS sessions
12:30:26 <david-lyle> background https://bugs.launchpad.net/ossn/+bug/1209250
12:30:26 <openstack> Launchpad bug 1209250 in OpenStack Security Notes "Configure Horizon to mitigate BREACH/CRIME attacks" [Undecided,Fix released] - Assigned to Robert Clark (robert-clark)
12:31:01 <david-lyle> so the problem is around using compression with Django
12:31:56 <david-lyle> I'm not sure django-debreach is the answer
12:32:00 <tsufiev> I wonder how much will be the performance impact if we disable gzip middleware
12:32:18 <david-lyle> tsufiev: that should be the default behavior now
12:32:33 <amotoki> agree
12:33:01 <tsufiev> david-lyle, so, the recommended fix is to disable gzip compression in Django and do not touch django-debreach in upstream?
12:33:17 <david-lyle> that's what the OSSN says, yes
12:33:48 <david-lyle> the django-debreach package has some fishy wording
12:34:20 <david-lyle> "Adds middleware and context processors to give some protection against the BREACH attack in Django"
12:34:27 <david-lyle> some protection
12:34:30 <tsufiev> :)
12:34:38 <tsufiev> "When combined with rate limiting in your web-server, or by using something like django-ratelimit, the techniques here should provide at least some protection against the BREACH attack."
12:34:52 <tsufiev> I got an impression that django-debreach app alone is not enough
12:34:55 <david-lyle> I think this should be a deployer choice rather than our default
12:35:27 <david-lyle> I think adding a note to the OSSN wiki page would be the best answer
12:35:41 <david-lyle> along the lines of here's an option that may work for you
12:36:09 <amotoki> don't we need to add some note to our document?
12:36:22 <amotoki> it would be helpful for new deployers.
12:36:42 <david-lyle> amotoki: we certainly can do that too
12:38:10 <david-lyle> any other thoughts on django-debreach?
12:38:21 <david-lyle> anyone for making it the default?
12:38:52 <tsufiev> well, perhaps we'll make it default in our downstream distro
12:39:20 <tsufiev> discussing right now with our security engineer
12:40:32 <david-lyle> #topic Dashboards for Neutron subprojects (amotoki)
12:40:43 <amotoki> I started a mailing thread about dashboard for neutron subproject.
12:40:54 <amotoki> I could not have time to discuss it during the summit :-(
12:41:12 <amotoki> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080441.html
12:41:31 <amotoki> I think there are various opinions on this.
12:41:46 <amotoki> I would like to have opinions from horizon reviewer side.
12:42:23 <david-lyle> amotoki: so these are new subprojects not already supported?
12:42:34 * david-lyle quickly parsed email
12:43:01 <amotoki> david-lyle: mostly yes.
12:43:11 <david-lyle> how related are they, other than neutron stuff?
12:43:14 <amotoki> for example, networking service chaining (sfc) is a good example.
12:43:27 <david-lyle> oh yeah, the 4500 line patch :)
12:43:39 <tsufiev> david-lyle, sorry for the late question, but we still don't have a patch for disable gzip middleware, do we?
12:43:53 <amotoki> they are neutron stuff but they are emerging projects.
12:43:57 <david-lyle> tsufiev: it's not enabled by default
12:44:31 <amotoki> one point is that they are optional.
12:44:40 <tsufiev> ah, got it, thanks!
12:44:42 <david-lyle> amotoki: I think the best way to make progress on those is to not have them in tree in Horizon
12:45:04 <david-lyle> now how to organize the repo(s), not sure
12:45:12 <amotoki> david-lyle: agree.
12:45:42 <david-lyle> it's possible to put many panels in one repo that would add to the existing networking panel group
12:46:37 <amotoki> I am afraid if we have dashboard directory in each tree it makes horizon developer difficult to be aware of dashboard changes.
12:46:55 <amotoki> because most of patches in such projects are unrelated to horizon.
12:47:23 <tsufiev> amotoki, shouldn't we use release notes mechanism for these notifications from now on?
12:47:24 <david-lyle> amotoki: dashboard directory?
12:48:10 <amotoki> david-lyle: we can use dashboard directory, but I am not sure gerrit query support it to find changes under dashboard/ directory.
12:48:34 <amotoki> tsufiev: could you elaborate more?
12:49:37 <tsufiev> amotoki, ah, now I realized that this won't help, because release notes for, say. neutron-specific-dashboard will be inside that repo and horizon devs wouldn't read it
12:49:56 <david-lyle> amotoki: I'm trying to understand the choices still
12:50:05 <david-lyle> 1) in horizon tree
12:50:20 <amotoki> what i I want to say by "dashboard directory"  is that each neutorn subproject has 'dashboard/' direcotry for horizon integration.
12:50:45 <david-lyle> 2) neutron-horizon-repo
12:51:17 <david-lyle> 3) neutron/dashboard like neutron/devstack
12:51:36 <amotoki> 3) neutron-foo/dashboard
12:51:42 <david-lyle> 4) feature-a-dash repo, feature-b-dash repo
12:51:54 <amotoki> 4) neutron-foo-dashbaord repor
12:52:06 <tsufiev> amotoki, on the other hand, why should horizon developers be aware of new dashboards built on horizon?
12:52:42 <amotoki> tsufiev: I think it is important to share horizon development conventions or similar things.
12:52:48 <david-lyle> amotoki: I'm not sure I like 3
12:53:25 <david-lyle> the reason is requiring cohabitation of the neutron foo package on the horizon server
12:53:43 <david-lyle> it works for devstack because devstack is intended to be single server
12:54:04 <david-lyle> I think sharing a horizon and neutron controller would be odd
12:54:15 <david-lyle> for deployment
12:54:22 <amotoki> in ubuntu packaging, xxx-common (like nova-common, neutorn-common) provides python modules
12:54:43 <amotoki> and xxx-api package provider entry points or configuration files.
12:54:46 <amotoki> in this case, it works.
12:55:14 <amotoki> I don't know about rpm packaging side.
12:55:29 <tsufiev> amotoki, IMO, the sharing works much better in horizon->dashboards direction than in the opposite one :/. Well, that's entirely opinionated
12:57:03 <david-lyle> amotoki: if they are packaged separately, that could be fine, but the testing apparatus between the two parts will be different
12:57:21 <amotoki> david-lyle: i see.
12:57:49 <david-lyle> so far all other projects have chosen a separate repo, but they aren't managing all the sub-projects that neutron is
12:58:13 <david-lyle> I can see the desire to not have so many repos
12:58:36 <david-lyle> I will respond to the thread, others feel free to respond too
12:59:00 <amotoki> so I think it is important to have some reasonable collaboration point between neutron(subprojects) and horizon.
12:59:07 <amotoki> david-lyle: thanks.
12:59:14 <david-lyle> amotoki: I agree completely
12:59:18 <amotoki> we need inputs from both neutron and horizon sides.
13:00:27 <david-lyle> time's up. Thanks everyone.
13:00:31 <david-lyle> #endmeeting