20:02:44 <david-lyle> #startmeeting Horizon
20:02:45 <openstack> Meeting started Wed Mar 25 20:02:44 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:02:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:48 <openstack> The meeting name has been set to 'horizon'
20:02:52 <rhagarty> hello
20:02:53 <david-lyle> Hello everyone
20:02:54 <gary-smith_> hi
20:02:56 <vishwana_> hi
20:02:56 <mattfarina> hello
20:02:58 <jgravel> hi
20:02:59 <cbader> hi
20:03:02 <crobertsrh> hello/
20:03:03 <robcresswell> Evening
20:03:05 <doug-fish> hi
20:03:06 <mwhagedorn> hello
20:03:10 <r1chardj0n3s> hihi
20:03:11 <mrunge> hello o/
20:03:15 <r1chardj0n3s> zzz
20:03:17 <r1chardj0n3s> ;)
20:03:18 <wchrisj> Hi
20:03:25 <esp> o/
20:03:33 <asahlin> hola
20:04:18 <lhcheng_> o/
20:04:21 <TravT> o/
20:04:27 <absubram> o/
20:05:19 <david-lyle> We crossed the k-3 milestone and are slogging through rc-1
20:05:42 * TravT slog slog slog
20:06:01 <david-lyle> Nice work on K-3, 15 blueprints implemented, with some clean up on a couple in RC-1
20:06:17 <david-lyle> #link https://launchpad.net/horizon/kilo/kilo-3
20:06:20 <david-lyle> for reference
20:06:38 <robcresswell> On mobile data, but just wanted to add I've been tagging a fair few bugs for rc1, some potentials too
20:06:57 <david-lyle> robcresswell: I've actually been cleaning those up
20:07:07 <david-lyle> had a change of instructions
20:07:23 <robcresswell> Ah, sorry for the extra work
20:07:23 <david-lyle> I'm clearing out anything not blocking rc-1
20:07:28 <david-lyle> no worries
20:07:35 <david-lyle> I told you wrong
20:07:37 <robcresswell> Understood
20:07:38 <TravT> what should we do for process?
20:07:42 <david-lyle> so I eat the mistake
20:07:53 <TravT> should we be tagging anything?
20:08:41 <david-lyle> other items that could be considered for rc-1 can be tagged kilo-rc-potential
20:09:13 <david-lyle> that's not to say other bug fixes can't merge, but I want to limit the list to what we really need
20:09:38 <robcresswell> Gotcha. Will stick to tagging.
20:09:57 <david-lyle> so come rc branch time, I have a better grasp on where we are
20:10:07 <david-lyle> and can make a decision if we're ready
20:10:40 <david-lyle> so for rc-1 we have #link https://launchpad.net/horizon/+milestone/kilo-rc1
20:10:56 <david-lyle> There were a couple of FFEs accepted
20:11:23 <david-lyle> https://blueprints.launchpad.net/horizon/+spec/fwaas-router-insertion
20:11:48 <david-lyle> and https://blueprints.launchpad.net/horizon/+spec/federated-identity
20:12:03 <david-lyle> for the first, amotoki and myself agreed to review the patch
20:12:17 <mrunge> I thought, we agreed on cleaning up doa first (for the second)
20:12:23 <david-lyle> and for the second Lin, Thai and I have agreed to review the patch
20:12:36 <david-lyle> mrunge: a plugin mechanism has merged
20:12:37 <absubram> david-lyle: Lin helped out on the first one too :)
20:12:47 <david-lyle> we're building on that mechanism
20:13:15 <david-lyle> the issue is there is a lot of demand for SSO and many forks out there to accomplish it
20:13:28 <david-lyle> Another thing to note
20:13:41 <mrunge> ah, that's would explain error messages about auth plugin not configured
20:13:43 <david-lyle> just because an FFE is granted does not mean the code will land
20:14:54 <lhcheng> mrunge: DOA haven't been release, you should not be getting errors with the new code.
20:15:02 <lhcheng> mrunge: were you using DOA master?
20:15:09 <mrunge> lhcheng, yes
20:15:30 <mrunge> lhcheng, let's move that to #openstack-horizon
20:15:38 <david-lyle> hmm, should have a default password plugin
20:15:40 <lhcheng> mrunge: ah. It still should not throw an error.  Let's chat on that later
20:15:47 <lhcheng> mrunge: agreed
20:15:49 <david-lyle> yeah later
20:16:02 <tqtran_afk> david-lyle: but if the patches are in reasonable shape, is there a chance we will try and land it for k3?
20:16:16 <tqtran> *correction kilo
20:16:20 <david-lyle> yes
20:16:36 <david-lyle> I'm just reinforcing that an FFE is not a guarantee
20:17:12 <robcresswell> What's the status on launch instance? marked a number of fixes for rc1
20:17:13 <david-lyle> a lot of the bugs in RC-1 are launch instance rework related
20:17:47 <david-lyle> the base functionality is there, but there are several improvements that are highly desirable
20:17:56 <david-lyle> especially for feature parity with existing
20:18:11 <TravT> it is coming along very nicely.
20:18:17 <david-lyle> without a number of those landing we won't switch
20:18:39 <TravT> we are coordinating on the etherpad  https://etherpad.openstack.org/p/horizon-kilo-virtual-sprint
20:18:56 <david-lyle> but there are magic code monkeys somewhere working on the effort
20:19:07 <r1chardj0n3s> ook
20:19:15 <david-lyle> or wonderful people, sorry poor reference
20:19:17 * TravT resembles that remark
20:19:59 <david-lyle> I had a manager who always referred to it that way when you expected too much work in too little time
20:20:18 <david-lyle> anyway
20:20:24 <TravT> :-)
20:20:36 <TravT> i don't think anybody is offended, david-lyle.
20:21:10 <david-lyle> as for general items, OpenStack had added Murano and Magnum into the mix
20:21:16 <david-lyle> as of yesterday
20:21:46 <david-lyle> so we need to iron out our plans for where extensions live in the next few weeks
20:22:03 <david-lyle> I would prefer out of tree, but need to run that by the TC
20:22:26 <david-lyle> otherwise, in tree with different core groups, not sure how that works with gerrit
20:23:03 <mrunge> at least, we should make sure they get integrated in our gating
20:23:12 <mrunge> and vice versa
20:23:17 <ericpeterson> problem I have seen is that hosting extensions in other repos - those reviewers don't know much horizon
20:23:51 <david-lyle> ericpeterson: yes, I understand that issue
20:24:07 <ericpeterson> not in favor of keeping them in horizon btw
20:24:32 <david-lyle> something we need to work out for sure
20:24:55 <david-lyle> I don't expect everything to go flawlessly
20:25:12 <tqtran> is it possible to have separate repos and assgn two different group of drivers to them?
20:25:13 <david-lyle> expecting an opportunity rich environment
20:25:22 <david-lyle> tqtran: yes
20:25:24 <TravT> i know murano has a UI already, but does magnum?
20:25:43 <david-lyle> TravT: I don't think so
20:25:48 <tqtran> so murano can have its own repo and have both its own core and horizon core. that way things say relatively in sync
20:25:59 <david-lyle> container service, not sure they've gotten that far
20:26:01 <TravT> tqtran: this would be kind like xstastic projects, right?
20:26:13 <tqtran> TravT: yeah something like that
20:26:34 <david-lyle> tqtran: yes, but that doesn't solve the scaling issue
20:26:56 <david-lyle> I've thought about that too
20:27:10 <mattfarina> we'd need to work out the dependency/version/documented/communicated issues as well.
20:27:13 <ericpeterson> there are two approaches, both have their pros / cons.   (I am currently working on two extensions)
20:27:42 <mattfarina> i like having extensions because what we need to support those will be useful for anyone making their own
20:27:57 <mrunge> magnum should integrate in launch instance. no need for an additional UI
20:28:05 <smc7> as someone who worked on murano a lot, for the most part it was fine from the perspective of the extension team; big changes like the bootstrap change last year threw us for a few days
20:28:05 <david-lyle> mrunge: not sure about that
20:28:24 <david-lyle> smc7: us too :)
20:29:02 <david-lyle> container service is not a nova driver, IIUC
20:29:03 <robcresswell> Unrelated, have we resolved the xstatic irdragndrop issue yet? Seemed to be an issue for packaging
20:29:14 <jwy> tqtran: can you explain "have both its own core and horizon core"? sorry, not familiar with how the xstatic projects are set up
20:29:15 <david-lyle> oh yeah, tqtran how's that coming?
20:29:16 <TravT> looks like magnum sits on top of heat
20:29:29 <tqtran> not yet, i havent had the time, someone is welcome to pick it up
20:29:55 <tqtran> i'll get on it by end of today if there are no volunteers
20:29:57 <mrunge> we have two teams under horizon umbrella with tuskar-ui
20:30:11 <mrunge> ^ jwy
20:30:47 <jwy> mrunge: what is the difference between the two teams?
20:30:48 <tqtran> jwy: basically you can assign different group of drivers to the project. one group would be horizon and the other murano.
20:31:19 <tqtran> this would give cores from horizon the power to regular patches in murano
20:31:19 <jwy> got it, thx
20:31:26 <tqtran> *regulate
20:31:34 <smc7> also there will be e.g. murano developers who are heavily involved in horizon
20:31:52 <mrunge> smc7, they are greatly welcome
20:32:05 <mrunge> the same is true for tuskar-ui folks
20:32:22 <mrunge> they're contributing to horizon on a regular basis
20:33:02 <david-lyle> we need to continue to work on the details, but for now let's move on to the agenda
20:33:21 <david-lyle> agenda can be found at #link https://wiki.openstack.org/wiki/Meetings/Horizon
20:33:41 <david-lyle> #topic removing name-duplication for working around non-existent name-mangling minification in Horizon angularjs code (r1chardj0n3s)
20:33:46 <r1chardj0n3s> ohai
20:34:17 <r1chardj0n3s> so for those who don't know what this refers to, here's a ref https://docs.angularjs.org/tutorial/step_05#a-note-on-minification
20:34:44 <r1chardj0n3s> basically all of our angularjs code includes the function name annotation guff to work around minifiers which mangle names
20:34:51 <r1chardj0n3s> it's messy, error-prone and annoying
20:35:11 <r1chardj0n3s> and also, as it turns out, completely unnecessary, since the minifier we use doesn't *do* name mangling
20:35:33 <r1chardj0n3s> so I propose we remove name annotation from our angular code
20:35:49 <mattfarina> but, that's the default minifier. what we have is configurable so that someone could change the minifer
20:35:51 <r1chardj0n3s> the issue raised by TravT was whether any deployers might use a *different* minifier
20:36:08 <r1chardj0n3s> sure, django's compressor has configurable minifiers
20:36:22 <mattfarina> for performance, other developers should be looking to use other minifiers
20:36:23 <r1chardj0n3s> the funny part is that the second minifier in the config options list *breaks* trying to compress our code :)
20:36:31 <r1chardj0n3s> performance?
20:36:38 <mattfarina> yup
20:36:39 <r1chardj0n3s> what performance issues are you aware of?
20:37:00 <mattfarina> we have the weakest minifier. it's basically a python port of jsmin
20:37:11 <r1chardj0n3s> what performance issues are you aware of?
20:37:12 <mattfarina> the more modern minifiers all create a significantly smaller file
20:37:32 <mattfarina> it's larger files to transfer between a browser and server. more round trips and more time
20:37:38 <r1chardj0n3s> have you compared the size difference of name mangling vs. just turning on gzip compression?
20:38:03 <ericpeterson> I'd think the minifier stuff will get picked up by distros and operators, right?
20:38:09 <mattfarina> i've not done that to horizon specifically but to other systems i have
20:38:48 <ericpeterson> its great to have insight if one is better than the other / what ones work best
20:38:49 <david-lyle> ericpeterson: I doubt many stray to far from the defaults
20:39:14 <mrunge> I haven't heard of anybody not using defaults here
20:39:21 <mattfarina> i was going to look at how we make it easy for people to stray from the defaults to something better this year
20:39:42 <david-lyle> guessing that horizon javascript minification optimization is fairly low on their priority list
20:39:42 <mattfarina> because web performance is important and it can remove round trips where time is lost in the network
20:39:43 <lhcheng> I don't think we should be making any assumptions what deployers use, if its configurable a deployer can use a different minifier.
20:39:47 <ericpeterson> let's take that as a separate issue to look at alternatives then?
20:40:08 <mattfarina> i would just think our code could be minified
20:40:31 <ericpeterson> it can be, and is - right?
20:40:38 <doug-fish> though once we decide we are open to alternatives we have to take the time to make sure our code can be minified this way - the issue r1chardj0n3s hoped to avoid
20:41:01 <mattfarina> if we just follow best practices here we should be good
20:41:03 <r1chardj0n3s> our code is currently minified, but not name mangled. most of the win we get at the moment comes from concatenation
20:41:20 <r1chardj0n3s> the minifcation removes whitespace and comments
20:41:38 <mattfarina> the minifier we use removes whitespace and comments. the modern ones go far beyond that
20:41:48 <mrunge> sigh
20:41:55 <david-lyle> I think we need to wait for Liberty to look into this, I'm not excited about changing all the angular js files at this time, especially when we have so many more patches to land
20:42:00 <r1chardj0n3s> I haven't tested this out yet, but I'm pretty sure that gzip compression would beat anything a name-mangling minifier would do
20:42:11 <mattfarina> you should minify + gzip
20:42:14 <r1chardj0n3s> david-lyle ok, I guess this just starts the conversation then
20:42:18 <mattfarina> that gets you the smallest
20:42:48 <r1chardj0n3s> mattfarina I really think we need numbers, because that comes at a cost of code legibility and potential errors
20:42:57 <r1chardj0n3s> because of the annotation in angular code
20:43:08 <mrunge> 1+ r1chardj0n3s
20:43:09 <david-lyle> mattfarina: our biggest complaints are X doesn't work or Y is crappy, but Y has yet to be js load performance
20:43:15 <mattfarina> r1chardj0n3s this has been on my mind for some time. i wanted to start with numbers because when it comes to web performance it's all about the numbers
20:43:33 <ericpeterson> lets table it as "we could have smaller / tighter js files than what we have now  - fix: TODO"
20:43:44 <mrunge> mattfarina, I'm not worried about 10% larger or smaller js code
20:43:46 <david-lyle> more like Y can't I launch an instance
20:43:55 <r1chardj0n3s> as I mentioned before, I started looking into it, but the second tool I tried to use broke trying to minify our JS ;)
20:43:58 <david-lyle> Y can't I assign a floating IP reliably
20:44:08 <TravT> yeah, so on the name mangling front, my specific question was if we could make a decision that name mangling isn't supported and must be disabled as an option.
20:44:24 <TravT> or if that would negatively impact deployers too much
20:44:36 <david-lyle> the summit would be the best place to ask
20:44:43 <TravT> so, choose your compressor, but don't enable mangling
20:44:43 <mrunge> yes!
20:44:48 <r1chardj0n3s> TravT you suggested we could insert some JS code to detect name mangling
20:44:54 <r1chardj0n3s> yep
20:45:03 <ericpeterson> TravT - JS compression is somewhere beyond issue #1000 for operators
20:45:08 <mattfarina> mangling is a common practice. if things are written well it's not an issue
20:45:24 <david-lyle> I'm going to table this and move on
20:45:29 <tqtran> honestly, i dont think name mangling is going to introduce too much of a performance gain for us
20:45:33 <r1chardj0n3s> mattfarina "written well" in this case includes "adding extra potential errors to your angularjs code"
20:45:36 <tqtran> i would rather see more readable code
20:45:45 <mattfarina> r1chardj0n3s let's connect offline about this
20:45:46 <david-lyle> #topic OMG we need LiveReload so badly, especially with Launch Instance (r1chardj0n3s)
20:45:53 <david-lyle> OMG!
20:46:04 <tqtran> what is livereload?
20:46:06 <r1chardj0n3s> haha, so who's sick of trying to get Launch Instance wizard to load the bloody changes off disk?
20:47:01 <r1chardj0n3s> LiveReload is a browser extension that keeps a connection to the HTTP server which notifies the browser when an on-disk static file changes; the browser will then automatically update its version of the file when you save it to disk
20:47:17 <david-lyle> looking into it, are suggesting gulp and other packages?
20:47:39 <r1chardj0n3s> means that changes to CSS, JS, HTML are reflected automatically, without need to cmd-shift-reload or (as with launch instance) clear the browser cache just to see your changes
20:47:49 <r1chardj0n3s> david-lyle: no, there are non-gulp-etc. options
20:47:59 <r1chardj0n3s> there's a plugin for Django which doesn't use nodejs
20:48:20 <ericpeterson> r1chardj0n3s - seems like a developer tool mainly, not critical in live deployments - right?
20:48:31 <r1chardj0n3s> ericpeterson it's definitely a developer tool
20:48:40 <mattfarina> r1chardj0n3s if you have compression on does it keep generating new compressed files (js/css)?
20:48:42 <ericpeterson> something to turn on for development / disable later?  not sure on perf overhead
20:49:00 * ericpeterson oh no, here we go again
20:49:03 <r1chardj0n3s> mattfarina: I haven't investigated how it plays with django-compressor
20:49:16 <TravT> here's something I've been meaning to try: https://developer.chrome.com/devtools/docs/workspaces
20:49:20 * mattfarina is interested in live reload
20:49:22 <r1chardj0n3s> it's *not* for deployment, and would be optional for developers
20:49:27 <TravT> built into chrome
20:49:43 <david-lyle> but you need something server side
20:50:11 <david-lyle> I think this could be as simple as documentation for dev setup
20:50:16 <r1chardj0n3s> TravT: I'm not sure how that plays with django as the server and its static files path mangling
20:50:24 <TravT> me neither.
20:50:49 <david-lyle> rather than requiring new tools in tree, unless there are things we do that actively break such integration
20:51:29 <ericpeterson> if you want to add some magic local_settings.py to check if DEBUG==True then turn on this thing, go for it  I'd say
20:51:44 <r1chardj0n3s> david-lyle: I think there would be some code changes in Horizon to support it tho
20:51:49 <r1chardj0n3s> like what ericpeterson mentions
20:52:17 <david-lyle> r1chardj0n3s: that's fine, but I'm curious about new requirements
20:52:27 <r1chardj0n3s> david-lyle: yep
20:52:44 <r1chardj0n3s> I'm not likely to be able to look into this for a few weeks anyway, so it's likely an L thing
20:52:53 <r1chardj0n3s> just wanted to float the idea
20:53:03 <ericpeterson> maybe we can help a developer-requirements.txt to use for our own setups ;)
20:53:23 <r1chardj0n3s> if that's needed, maybe
20:53:23 <david-lyle> developer-requirements.txt
20:53:25 <ericpeterson> s/help/have
20:53:28 <david-lyle> npm
20:53:36 <r1chardj0n3s> woah
20:53:40 <david-lyle> prosper
20:54:12 <david-lyle> I think that breaks the fedora model though
20:54:42 <r1chardj0n3s> anyway, I think there's a general "hmm, that kinda sounds interesting" so maybe I'll try to get it mocked up for the summit
20:54:46 <r1chardj0n3s> do a demo
20:54:53 <r1chardj0n3s> blow socks
20:54:53 <david-lyle> but if they are not required dev tools, it roughly amounts to documentation
20:54:56 <r1chardj0n3s> that kinda thing
20:55:02 <david-lyle> r1chardj0n3s: perfect
20:55:04 <mrunge> currently unsure about that (breaking fedora model)
20:55:11 <r1chardj0n3s> david-lyle as I mentioned there will most likely need to be code changes too
20:55:24 <david-lyle> r1chardj0n3s: understood
20:56:13 <david-lyle> #topic Django-1.7.x support, Django-1.6 will be unsupported, once Kilo is released
20:56:21 <mrunge> ah, yes!
20:56:28 <r1chardj0n3s> +1
20:56:30 <r1chardj0n3s> :)
20:56:30 <david-lyle> did that patch merge yet?
20:56:35 <mrunge> nope
20:56:47 <mrunge> well, we're not gating on django-1.7
20:57:03 <mrunge> and it's still not allowed in global requirements
20:57:07 <david-lyle> I meant the horizon patch to not use test settings
20:57:28 <mrunge> last time I saw, it had one +2 from you david-lyle
20:57:36 <david-lyle> awww
20:57:37 <mrunge> that was about 60 mins ago
20:58:04 <mrunge> and, if someone has free cycles, I feel we can even make django-1.8 support
20:58:14 <mrunge> which would be AWESOME
20:58:42 <TravT> i can dig into my bag of +1's for you mrunge... i have a few to spare.
20:58:43 <david-lyle> https://review.openstack.org/#/c/167562/
20:58:58 <david-lyle> is the review
20:58:59 <mrunge> hahaha, thank you TravT !
20:59:17 <david-lyle> when we moved compilemessages to be required at runtime, we didn't update the settings
20:59:23 <david-lyle> used
20:59:32 <david-lyle> this causes gate problems
20:59:45 <david-lyle> yay, gate problems
20:59:53 <mrunge> interesting fact is, that didn't cause gate issues with django-1.6
21:00:00 <david-lyle> if that merges, hopefully 1.7 will work in the gate
21:00:15 <david-lyle> mrunge: there's still magic in the gate
21:00:32 <mrunge> yes. secret sauce-
21:00:52 <TravT> just ran it
21:00:54 <TravT> no errors
21:00:58 <david-lyle> essentially 1.6 is dying and we don't support anything beyond it
21:01:09 <david-lyle> well no longer supported
21:01:18 <mrunge> it will become unsupported in around one-2 weeks
21:01:18 <david-lyle> so we need at least 1.7
21:01:35 <mrunge> uhm, during the next few weeks
21:01:49 <david-lyle> that's likely the best we can hope for in requirements.txt
21:01:59 <david-lyle> but 1.8 ready code should be the goal
21:02:17 <mrunge> david-lyle, would you be opposed in backporting django-1.8 support for kilo?
21:02:27 <mrunge> if we don't make it for kilo release?
21:02:42 <david-lyle> I would not be opposed
21:02:53 <mrunge> even if that'd be a feature?
21:03:01 <mrunge> strictly that'd be forbidden
21:03:15 <david-lyle> not sure that's a feature or not
21:03:26 <mrunge> and it will require changes in doa, too
21:03:58 <david-lyle> the two together gets more compilcated
21:04:10 <david-lyle> let's move to #horizon
21:04:16 <mrunge> thanks!
21:04:21 <david-lyle> time's up. Thanks everyone!
21:04:24 <david-lyle> #endmeeting