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