12:00:32 <david-lyle> #startmeeting Horizon
12:00:34 <openstack> Meeting started Wed Jan  7 12:00:32 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:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:37 <openstack> The meeting name has been set to 'horizon'
12:01:09 <david-lyle> anyone around to chat about Horizon?
12:01:14 <r1chardj0n3s> yep
12:01:15 <neillc> yep
12:01:18 <markus_z> yep
12:01:18 <doug-fish> indeed
12:01:19 <mrunge> o/
12:01:23 <akrivoka> hi \o
12:01:37 <tqtran> <---
12:01:55 <r1chardj0n3s> (mumbling)
12:01:59 <david-lyle> is that a flatline tqtran?
12:02:03 <jpich> Happy new year♪
12:02:19 <tqtran> close to it
12:02:28 <r1chardj0n3s> Indeed, happy new year :)
12:02:32 <mattfarina> yes
12:02:46 <ygbo> yep
12:03:33 <robcresswell> o/
12:04:01 <david-lyle> great
12:04:14 <david-lyle> General items first
12:04:41 <david-lyle> There a couple of cross-project specs that are up for review
12:04:53 <david-lyle> one around logging standards
12:05:12 <david-lyle> #link https://review.openstack.org/#/c/132552/
12:05:54 <david-lyle> and one around profiling #link https://review.openstack.org/#/c/134839/
12:06:39 <david-lyle> these are the first two true cross-project specs, in an attempt to create some uniformity across the projects
12:07:14 <david-lyle> the individual projects are encouraged to review these and the TC has final approval
12:07:58 <david-lyle> From my perspective, I think this is a very positive step, so I would encourage our participation
12:08:32 <david-lyle> more information can be found at #link http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-01-06-21.02.log.html
12:09:26 <david-lyle> and an obligatory status check
12:09:36 <david-lyle> #link https://launchpad.net/horizon/+milestone/kilo-2
12:11:02 <david-lyle> between k-1 carry-over from k-1 and lots of items from varied contributors, this is a large list
12:11:34 <david-lyle> k-3 has been kept intentionally small to catch some of the overflow
12:11:55 <david-lyle> but it's still a lot
12:12:09 <doug-fish> david-lyle: are the 2 cross project efforts you linked intended for kilo?
12:13:17 <david-lyle> doug-fish: I believe that's the intent, but I could imagine work still taking place in Lemming to address them
12:13:45 <doug-fish> yeah
12:14:02 <david-lyle> to be honest, I'm not entirely sure the carrot/stick to implement them
12:14:17 <david-lyle> we'll learn more once they're adopted
12:14:47 <david-lyle> I think the profiler work would be coming from that team
12:14:53 <doug-fish> sure - they just seem late to still be under discussion to get done in kilo unless there is somebody waiting to implement
12:14:53 <david-lyle> logging, not sure
12:16:00 <david-lyle> additionally, I want to remind people of #link https://wiki.openstack.org/wiki/Horizon/Blueprint_Reviews
12:16:14 <david-lyle> some items scheduled are not fully approved yet
12:16:56 <david-lyle> That's all I have for general items
12:17:27 <david-lyle> agenda for today can be found at #link https://wiki.openstack.org/wiki/Meetings/Horizon
12:17:42 <david-lyle> #topic Review blueprint https://blueprints.launchpad.net/horizon/+spec/serial-console
12:17:56 <david-lyle> mzoeller or rbertram?
12:18:09 <rbertram> markus_z added that - are you on?
12:18:10 <markus_z> I'm mzoeller, hi
12:18:58 <markus_z> Should I introduce the bp in a few words?
12:19:16 <david-lyle> yes please
12:20:15 <markus_z> Nova provides a new API to connect to the launched instances via a "serial console". This is an alternative to VNC, RDP, SPICE.
12:20:54 <markus_z> This blueprint covers the usage of this new API to connect to instances via serial console via horizon.
12:21:33 <rbertram> btw, Nova API was available in Juno; just waiting to be used
12:22:39 <david-lyle> so is this in addition to the SPICE, VNC and RDP available now, or are you intending to replace all those as well?
12:23:01 <markus_z> This is an addition, not a replacement.
12:23:24 <rbertram> My current code fails over to SERIAL when the other 3 are not there
12:23:25 <markus_z> Some platforms do not support VNC, RDP, SPICE and depend on a "serial console".
12:24:43 <rbertram> I've got a working implementation, with bugs to fix & testing to add.
12:24:58 <david-lyle> but if I've followed the conversations in #openstack-horizon, the implementation is client side
12:25:18 <david-lyle> which would be different than the other 3?
12:25:30 <rbertram> Yes, it uses term.js
12:25:57 <rbertram> One big to-do is xstatic for term.js, depending on how our next meeting topic goes
12:27:19 <david-lyle> ok, I see you've added it to the Kilo review list already
12:28:04 <rbertram> I don't want to sink more time into it without validation from others that it is on right path
12:28:06 <david-lyle> I think this is pretty straightforward support of nova api
12:28:07 <markus_z> Yes, I wasn't quite sure how the process looks like.
12:28:57 <david-lyle> I think you're on the right track
12:29:20 <rbertram> Should it be marked k-3?
12:29:24 <david-lyle> I'd keep working on it, and encourage people to review the bp with any concerns
12:29:43 <david-lyle> rbertram: sure
12:29:57 <rbertram> cool
12:30:10 <david-lyle> anyone else have any questions on this topic?
12:31:03 <david-lyle> #topic Angular work blockers: Xstatic now or wait on Bower? need reviews! (tqtran)
12:31:37 <tqtran> so the angular work that we have started is currently block by two things
12:32:19 <tqtran> it depends on API which provides the data, and 3rd party libs (currently through xstatic)
12:32:43 <tqtran> the first is not too hard, we just need more eyes and reviews on it.
12:33:41 <tqtran> the 2nd, we are currently trying to get it through xstatic, but with discussion on maybe using bower in the future, not sure what the right course is.
12:34:11 <david-lyle> agree on the first, I think people are coming back to life now, myself included, to start reviewing again, we'll try to get that part moving
12:34:26 <tqtran> right now, this patch https://review.openstack.org/#/c/133767/ has about 5 dependencies
12:34:48 <tqtran> would be good to start seeing some of those dependencies get merge, its a real pain to rebase each time
12:35:20 <r1chardj0n3s> (and that doesn't include the requirements.txt changes needed for the xstatic packages)
12:35:48 <r1chardj0n3s> sorry, the *visible* dependencies don't include the requirements/global-requirements changes
12:35:55 <mrunge> r1chardj0n3s, tqtran so, there are no tests on that code?
12:36:03 <tqtran> yep, im currently using cdn until the requirements is merged
12:36:18 <mrunge> I know, testing is lame, but still we want that
12:36:47 <david-lyle> tqtran: isn't this https://review.openstack.org/#/c/136676/ the blocking patch?
12:36:49 <tqtran> tests will be added, right now, we just want to clear up the dependency chain first
12:37:12 <tqtran> david-lyle: yes, thats one of them
12:37:39 <mrunge> to get bower in fedora, I'd need around 30 new packages
12:37:40 <david-lyle> that one does have tests
12:37:45 <tqtran> the other big blocker is: https://review.openstack.org/#/c/139284/
12:38:05 <mrunge> not counting the 20 already there in bowers build dep chain
12:38:52 <r1chardj0n3s> mrunge: if you want bower for development, I've posted a solution using nodeenv to give that to you
12:39:05 <r1chardj0n3s> mrunge: if you are re-packaging, then you don't need bower
12:39:35 <mrunge> r1chardj0n3s, and how do I provide dependent javascript libs?
12:39:58 <r1chardj0n3s> mrunge: sorry, what dependent javascript libs?
12:40:00 <mrunge> we can take that somewhere else
12:40:18 <mrunge> r1chardj0n3s, dependent to the new implementation
12:40:32 <r1chardj0n3s> mrunge: what new implementation? sorry, I'm not following
12:40:39 <david-lyle> r1chardj0n3s: all the libraries brought in by bower
12:40:50 <mrunge> r1chardj0n3s, to your horizon re.implementation
12:41:07 <david-lyle> fedora or ubuntu have to deliver those libraries somehow
12:41:13 <r1chardj0n3s> david-lyle: bower and its implemenation is handled by nodeenv, which hides it all away so you don't have to worry about it - it just gives you a bower command to run
12:41:51 <mrunge> r1chardj0n3s, our build system has no internet connection, by purpose
12:41:59 <r1chardj0n3s> david-lyle: I understood that fedora et al would repackage the client-side js libs we're getting through bower
12:42:18 <r1chardj0n3s> just like they repackage the xstatic stuff now
12:42:26 <mrunge> and you're not telling me, you'd go to every production server, running bower install or whatever...?
12:42:40 <david-lyle> r1chardj0n3s: that's what we're trying to figure out
12:43:39 <r1chardj0n3s> ok, these are the problems that need to be raised in the mailing list, so thought can be put into them :)
12:44:01 <mrunge> if we just leave the packaging stuff aside, one would need to ssh into your web server environment, execute bower install (or whatever) to set up horizon?
12:44:04 <r1chardj0n3s> mrunge: do you install using fedora packaging?
12:44:25 <mrunge> r1chardj0n3s, I would want to install via rpm packages
12:44:34 <mrunge> debian folks via debian packages
12:44:37 <mrunge> etc.
12:44:48 <r1chardj0n3s> mrunge: right, so the stuff that we as devs get via bower, you get through fedora (And others get through deb)
12:44:55 <tqtran> basically, the point is to raise awareness so we can move these patches along because they are blocking the angular effort. sounds to me like we'll continue using xstatic until the bower stuff gets resolve
12:45:14 <mrunge> r1chardj0n3s, exactly. and *how* does that stuff get there?
12:45:25 <r1chardj0n3s> someone builds an rpm or a dev
12:45:30 <mrunge> yes
12:45:34 <r1chardj0n3s> yes
12:45:48 <r1chardj0n3s> er
12:45:49 <r1chardj0n3s> dev
12:45:51 <r1chardj0n3s> deb
12:45:51 <mrunge> since I'd be the person to do, how do I pull in that stuff *from source*?
12:45:57 <mrunge> without bower?
12:46:06 <r1chardj0n3s> bower just installs from a github repos
12:46:09 <r1chardj0n3s> so you get it from that repos
12:46:15 <r1chardj0n3s> using a tag
12:46:28 <mrunge> well, I make a copy of a github repo
12:46:34 <mrunge> and execute all build steps
12:46:47 <r1chardj0n3s> there's no build steps
12:46:54 <mrunge> which is slightly more than just copying a javascript file
12:46:57 <r1chardj0n3s> bower provides static files only
12:49:06 <mrunge> e.g to *build* angularjs, I need bower and a HUGE pile of other stuff
12:49:20 <mrunge> I mean, to do it properly
12:49:23 <r1chardj0n3s> no, you clone the angular repos and copy the files from it
12:50:03 <mrunge> debian folks will disagree here
12:50:20 <mrunge> I could go on with xstatic approach
12:50:29 <mrunge> not completely killing this meeting
12:51:15 <r1chardj0n3s> I feel I'm fighting a lot of FUD over bower, which is a shame, because xstatic is such an energy sap :(
12:51:19 <mrunge> but you didn't answer my other question:
12:51:44 <mrunge> how would I set up horizon on a production environment?
12:51:58 <mrunge> r1chardj0n3s, I agree, xstatic is not a good solution
12:51:59 <r1chardj0n3s> using your fedora or debian packages
12:52:17 <mrunge> I mean, using your proposed way, I mean
12:52:30 <r1chardj0n3s> mrunge: on angular specifically, you clone the https://github.com/angular/bower-angular repository and copy files to make your fedora / debian package
12:52:59 <mrunge> git clone horizon and then?
12:53:28 <r1chardj0n3s> mrunge: you told me before that you install from rpms
12:54:05 <mrunge> uhm, I was asking you, how you propose to set up horizon
12:54:23 <mrunge> which is probably different from my approach
12:54:34 <r1chardj0n3s> hang on, you asked me "how would I set up horizon on a production environment?"
12:54:42 <mrunge> yes
12:54:44 <r1chardj0n3s> not how I set it up (as a developer)
12:54:49 <mrunge> yes#
12:55:03 <r1chardj0n3s> and the answer to your question about setting up your production environment is using rpms
12:55:08 <r1chardj0n3s> no cloning of gits
12:55:36 <mrunge> ok, we're on the same side here :D
12:55:40 <r1chardj0n3s> yes! :)
12:56:04 <r1chardj0n3s> the *only* thing that needs to be done in a bower world is that you create your rpms from the bower githubs instead of some xstatic git
12:56:23 <mrunge> yes!
12:56:28 <r1chardj0n3s> \o/
12:56:47 <mrunge> xstatic works, but it's not a clean solution
12:56:56 <mrunge> still on the same side
12:57:11 <r1chardj0n3s> xstatic works, but it's a significant barrier that keeps coming up
12:57:20 <david-lyle> mrunge, this has to be similar to how the jquery packaging is done
12:57:24 <r1chardj0n3s> the angular upgrade that TravT is trying to do... ugh
12:57:27 <david-lyle> for fedora
12:57:40 <david-lyle> so this isn't a new methodology, I wouldn't think
12:57:52 <david-lyle> repackaging a tag in a git repo
12:57:59 <r1chardj0n3s> yup
12:58:04 <mrunge> david-lyle, jquery packaging has the same issue like bower or angular
12:58:18 <david-lyle> but an rpm exists
12:58:21 <david-lyle> correct?
12:58:30 <mrunge> yes
12:58:30 <r1chardj0n3s> for reference, https://github.com/jquery/jquery is the bower github for jquery :)
12:59:34 <david-lyle> My point is, this is different from the typical packaging around python libraries, but we're not breaking new ground
12:59:45 <david-lyle> in any of the distros
12:59:50 <r1chardj0n3s> yep
12:59:52 <david-lyle> just adding a lot of new packages
13:00:09 <david-lyle> which is painful, but would be using xstatic too
13:00:24 <mrunge> david-lyle, the thing is, that you need a huge bunch of new packages to build that single one
13:00:35 <r1chardj0n3s> there's a fair chance that they won't need to create new packages for most of the stuff that doesn't get upgraded yet
13:00:54 <david-lyle> r1chardj0n3s: mrunge indicated 30 just for bower
13:01:05 <r1chardj0n3s> existing packaging based on xstatic has the same files in it
13:01:14 <david-lyle> because they need both sides of the toolchain
13:01:16 <r1chardj0n3s> so can continue to be used until there's a new release desired
13:01:18 <david-lyle> dev and production
13:01:19 <mattfarina> something to consider, the distro packaged versions of js (and other web things) is usually far behind the current version. ubuntu packages jquery 1.7 for example
13:01:55 <david-lyle> mattfarina: whatever we depend on horizon gets replaced with the distro package
13:02:05 <david-lyle> so we take that into account now
13:02:15 <mrunge> mattfarina, no, bundling is just wrong
13:02:45 <david-lyle> but yes, we'd have to continue to support older versions
13:02:54 <david-lyle> even if using bower
13:03:08 <david-lyle> ok, we're over time
13:03:10 <mrunge> for reference, js-jquery build description is slightly more than just copying javascript code: https://patches.fedorapeople.org/jquery/js-jquery1.spec
13:03:47 <david-lyle> mrunge: I wasn't indicating it was simple, just that it happens :)
13:04:08 <mrunge> david-lyle, yes, and I agree, we'll figure it out
13:04:22 <mrunge> still it's a tonne of work to do for a simple file
13:04:29 <david-lyle> mrunge: agreed
13:05:11 <david-lyle> We really do need to come to an agreed path forward, otherwise we're going to be blocked, or further down the xstatic hole
13:05:41 <david-lyle> I may try to schedule a separate meeting with the stackholders
13:05:44 <r1chardj0n3s> my most revent email on the subject was my attempt to add some concrete, but I think it's still lacking on the detail that mrungeneeded
13:06:00 <r1chardj0n3s> well s/detail/info
13:06:43 <david-lyle> Thanks everyone, I'm going to close the meeting, feel free to continue discussion.
13:06:47 <david-lyle> #endmeeting