16:00:15 <david-lyle> #startmeeting Horizon
16:00:15 <apmelton> take care everyone!
16:00:16 <openstack> Meeting started Tue Aug 19 16:00:15 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:20 <openstack> The meeting name has been set to 'horizon'
16:00:21 <thomasem> thanks everyone! Take it easy!
16:00:29 <david-lyle> Hello
16:00:31 <akrivoka> hello!
16:00:35 <akrivoka> \o
16:00:38 <jpich> Hello
16:00:45 <tzumainn> hiya!
16:00:48 <gary-smith> hi
16:00:53 <TravT> 0/
16:01:13 <pawels> hi
16:01:16 <bradjones> hi
16:02:01 <jrist> o/
16:02:04 <david-lyle> let's start with https://launchpad.net/horizon/+milestone/juno-3
16:02:12 <lcheng> hello
16:02:18 <david-lyle> Blueprints:
16:02:18 <david-lyle> 1 Unknown, 7 Started, 4 Slow progress, 6 Good progress, 1 Beta Available, 35 Needs Code Review, 8 Implemented
16:02:37 <david-lyle> we're making progress, but lots up for review
16:03:11 <david-lyle> I think https://blueprints.launchpad.net/horizon/+spec/remove-javascript-bundling is almost ready with a couple caveats
16:03:14 <gugl2> hi
16:03:31 <jpich> That's my understanding as well
16:03:43 <david-lyle> I don't see radomir online
16:03:52 <amotoki> hi
16:03:55 <jpich> There'll be follow-up patches but the biggest part is ready to merge
16:04:26 <david-lyle> that's great, I'd even be ok tracking the remaining pieces as high priority bugs
16:04:49 <jpich> Sounds like a good idea
16:05:16 <david-lyle> the other high bp open is https://blueprints.launchpad.net/horizon/+spec/launch-instance-ux-enhancement
16:05:42 <david-lyle> MaxV: do you have a better feel for if that is a Juno or Kilo target?
16:06:40 <david-lyle> my feel is that won't make it, but I want to give MaxV a chance to give an update
16:06:48 <david-lyle> so I'll ping him separately
16:07:27 <MaxV> david-lyle: I do the max but it seems that it will be for Kilo, I have made some refactoring and patches, I will have the best look on friday
16:08:27 <david-lyle> MaxV: ok thanks for the update, I'm going to move it to Kilo, if you can get it ready, I'll move it back into Juno, just want to set expectations at this point
16:09:01 <rbertram> MaxV: I'm still available to help, if I can
16:09:18 <MaxV> rbertram: https://review.openstack.org/#/c/115321/1
16:09:50 <rbertram> MaxV: ok, cool
16:10:09 <rdopieralski> I'm sorry for being late
16:10:13 <david-lyle> MaxV, rbertram, keep me updated
16:10:52 <david-lyle> rdopieralski: we discussed the js separation bp a bit
16:11:04 <MaxV> rbertram: If you have a good understanding of angular, there is the flavor to implement following this
16:11:13 <rdopieralski> david-lyle: I will read the log
16:11:30 <david-lyle> seems like the majority is ready to go and there will be a couple of patches for straggling patches in requirements
16:11:38 <david-lyle> we can track those with bugs
16:11:58 <rdopieralski> david-lyle: yes, I actually removed the struggling ones from the one mega-patch
16:12:07 <rdopieralski> david-lyle: so that it will finally merge
16:12:19 <david-lyle> rdopieralski: sounds great, thank you
16:12:30 <david-lyle> I'll try out the updated patch after this
16:12:35 <rdopieralski> I should have made a separate patch for each of them from the beginning
16:12:50 <david-lyle> shouldn't be this hard
16:12:59 * david-lyle should know that it is
16:13:35 <david-lyle> there are a few medium bps that are in slow progress
16:14:07 <david-lyle> these will likely be bumped
16:14:42 <david-lyle> On the plus side, lots of things to review
16:14:51 <rdopieralski> yay
16:15:00 <david-lyle> many opportunities to exercise your code review skills
16:15:15 <david-lyle> all help is appreciated
16:15:54 <david-lyle> I think that covers Juno-3
16:16:00 <david-lyle> keep up the great work everyone
16:16:30 <david-lyle> Only one topic on the agenda for today
16:16:44 <david-lyle> #topic modified js library and packaging issue (pawels)
16:16:52 <TravT> hey david-lyle
16:16:58 <david-lyle> #link https://review.openstack.org/#/c/104956
16:16:59 <TravT> let me introduce it
16:17:02 <TravT> we have a high priority Glance feature called the Metadata Definitions Catalog that will land in Juno #link: https://blueprints.launchpad.net/glance/+spec/metadata-schema-catalog
16:17:09 <TravT> it is going through final Glance code review now.
16:17:17 <TravT> we have several related horizon patches that we've had some code review on
16:17:24 <TravT> we'd love more eyes on them soon, but today we have a specific question on how to handle a js library
16:17:37 <TravT> as david-lyle mentioned the question relates to #link: https://review.openstack.org/104956
16:17:45 <TravT> we used a 3rd party angular tree widget as the basis for the code and then customized it quite a bit to fit in with horizon and for our use case
16:17:54 <TravT> it has an MIT license and is hosted on git hub
16:18:02 <TravT> so basically, our question is if we can just directly include the code (as we've done) or if we need to fork this on git hub and package?
16:18:42 <pawels> we have already "removed" AngularJS update from the patch
16:18:47 <pawels> and this is understood
16:19:13 <pawels> but now we have library https://github.com/nickperkinslondon/angular-bootstrap-nav-tree modified as a part of patch
16:19:30 <david-lyle> Generally, it's best to fix issues with upstream projects, upstream, but this sounds like a significant fork
16:19:43 <pawels> yeap, this is a fork
16:19:57 <pawels> it's not a fix of original library
16:20:12 <david-lyle> and this is behavior the original library would not want to include?
16:20:43 <rdopieralski> in the perfect world, you would make a patch for the original library and they would include what you need as options
16:20:44 <pawels> I believe it is more  Horizon Metadata feature changes
16:21:13 <pawels> but I would guess they may not be willing to include "a feature specyfic changes"
16:21:15 <TravT> yes, the changes are mostly horizon / glance metadata definition specific
16:21:16 <pawels> in mainstream
16:21:34 <rdopieralski> pawels: you might try asking, you never know
16:21:58 <rdopieralski> I mean, they could be generalized to be useful for the general population
16:22:12 <rdopieralski> pawels: do you have an example of such change?
16:22:20 <pawels> there is a change: https://review.openstack.org/#/c/104956/1..52/horizon/static/horizon/js/angular/directives/abn_tree_directive.js
16:22:35 <pawels> e.g.:
16:22:36 <pawels> module.directive('abnTree', [67    '$timeout', function($timeout) {    '$timeout', 'capabilitiesService', function($timeout, capabilitiesService) {
16:22:58 <pawels> where a "capabilitiesService" is like Horizon Metadata code
16:23:20 <pawels> angular.forEach(capabilitiesService.metadata, function(item){
16:23:25 <pawels> that kind of change
16:23:37 <rdopieralski> looks like you are mixing library with the model
16:24:13 <rdopieralski> there is no cleaner way of doing that?
16:25:30 <TravT> i'm not sure about that, but the widget on github is a simple tree, like a folder structure.
16:25:48 <pawels> so it doesn;t fit our need
16:25:58 <TravT> it provides a good bases
16:26:10 <TravT> but as it stands, it definitely does not fit our needs
16:26:58 <TravT> rdopieralski: we'd be happy to demonstrate it to you
16:28:05 <TravT> our changes are very specific to the new Glance service and managing metadata on openstack.
16:28:39 <rdopieralski> TravT: what I'm wondering about is whether the special additional features that you need could be added to the original library in a way that is not horizon-specific
16:29:18 <gary-smith> and also preferably not glance-specific, so they could be re-used within horizon
16:29:48 <rdopieralski> I know it's easier to just modify it like this
16:29:55 <rdopieralski> but not very useful in the long term
16:30:15 <TravT> hmm... not sure why it isn't very useful in the long term.
16:30:29 <TravT> it isn't glance specific.
16:30:36 <TravT> the data it gets comes from Glance
16:30:54 <TravT> but there are four dependent uses of it that make it work with flavors, aggregates, and volumes
16:31:15 <david-lyle> so why wouldn't the upstream library be in favor of the changes if they are not glance specific?
16:31:34 <TravT> well, we can always ask.
16:31:57 <david-lyle> that's the preferred path
16:32:22 <david-lyle> try to work with the library maintainer to get the generalized feature supported in that library
16:33:34 <david-lyle> if/when it becomes clear that the maintainer doesn't want to support your use case, then we talk about bringing in a fork and taking on the maintenance burden for that
16:33:42 <TravT> okay, so we can take a look at that and reach out.
16:33:44 <TravT> TBH
16:33:59 <TravT> I feel it may become a bigger maintenance burden to not bring it in.
16:34:38 <david-lyle> multiply bringing it in times 100+
16:34:54 <david-lyle> that's our number of dependencies, roughly estimated
16:35:04 <TravT> Ahh, what's one more! ;-)
16:35:22 <TravT> So, we'll look at it and see if we can get it in the external library
16:35:33 <TravT> if they accept, what's the path from there?
16:35:34 <david-lyle> excellent
16:35:43 <TravT> If the don't accept, what's the path from there?
16:36:10 <david-lyle> build an xstatic copy of the library - add it to the global requirements - add to horizon
16:36:30 * david-lyle remembers he owes the mailing list an email regarding this subject
16:37:07 <TravT> And if they don't accept?
16:37:12 <TravT> it hasn't been touched since April.
16:37:25 <david-lyle> #action david-lyle send dev mailing list new approval process for JavaScript libraries in Horizon
16:37:37 <clu_> david-lyle: +1 would like to learn about the process
16:37:58 <david-lyle> hasn't been touched because it hasn't had your input :)
16:38:34 <david-lyle> if no progress on the upstream, we can look to fork, then follow the rest of the same steps
16:38:42 <TravT> ok
16:38:48 <pawels> thanks
16:38:58 <rdopieralski> but even if forked, it should be a general-purpose library, not horizon-specific
16:39:05 <rdopieralski> I think
16:39:07 <david-lyle> +1
16:39:32 <pawels> rdopieralski: sure
16:40:18 <david-lyle> another approach, try to just get an extensibility point into the upstream library and then create a horizon specific js file to leverage that extensibility point
16:40:29 <david-lyle> not sure how to accomplish that in angular
16:40:38 <david-lyle> but something to consider
16:40:40 <pawels> will try and go back to you ;()
16:40:45 <david-lyle> thanks
16:40:53 <jpich> +1
16:41:10 <david-lyle> #topic Open Discussion
16:41:43 <bradjones> I have a question regarding https://bugs.launchpad.net/horizon/+bug/1288484
16:42:03 <bradjones> it talks about moving rickshaw graphs to d3 to support axis titles
16:42:38 <bradjones> It seems to me that there should be a standard graphing library for horizon (maybe d3)
16:42:47 <bradjones> is there a reason this is not the case?
16:43:34 <david-lyle> d3 was chosen as the standard, rickshaw builds on top of that and was included to avoid reinventing
16:44:18 <bradjones> ok so for the bug in question it is not asking to rewrite the graphs in d3?
16:44:22 <lsmola> bradjones: rickshaw is using D3
16:44:41 <lsmola> bradjones: it's framework around d3 for timeseries data
16:44:57 <david-lyle> the bug is essentially, we can't label axis
16:45:04 <lsmola> bradjones: what are exactly axis titles?
16:45:11 <david-lyle> beyond that, the rest is conjecture
16:45:22 <david-lyle> labels I assume
16:45:30 <bradjones> yeah labels sorry
16:45:37 <lsmola> david-lyle: like with values? or with name?
16:45:52 <david-lyle> y and x for example
16:45:57 <david-lyle> height and width
16:46:02 <david-lyle> names
16:46:08 <bradjones> i took it to mean names
16:46:19 <david-lyle> clu_: insight?
16:46:23 <david-lyle> or clarification
16:46:30 <lsmola> david-lyle: right
16:46:38 <clu_> david-lyle: yes, the x-y labels
16:46:50 <lsmola> bradjones: well we can always add something like that to rickshaw :-)
16:47:14 <bradjones> lsmola: I think that sounds like a good approach, will look into this
16:47:15 <lsmola> bradjones: but there was no need for us, as you can display that detail on chart hover
16:47:35 <lsmola> bradjones: so it says 10%CPU at date xy
16:47:39 <lsmola> bradjones: e.g.
16:48:47 <bradjones> yup I will continue to look into this thanks all for the clarification
16:48:49 <tqtran> while we're on this subject, anyone know how why we decided on d3 as oppose to other graphing libs like flot?
16:49:20 <lsmola> bradjones: we are actually using it for timeseries data only, so one axis is always time, the other is title of the chart
16:49:33 <tqtran> the zuul gate check jobs are using flot graphs, just curious why we decided to go with d3
16:50:10 <lsmola> tqtran: no idea, that came before me, we used rickshaw, because there was already d3 :-)
16:50:22 <david-lyle> that choice was made back at the Havana summit by the past PTL, but d3 provides more than just graphs
16:50:45 <lsmola> tqtran: but on the other hand, d3 is very good library for data related charting
16:50:49 <david-lyle> well maybe the largest sense of graphs
16:51:16 <tqtran> lsmola: yes agree, but flot is easier to use and has a built in grammar (without requiring richshaw)
16:51:17 <lsmola> david-lyle: yeah there is liek the neutron topology, heat topology, etc.
16:51:57 <lsmola> tqtran: Attractive JavaScript plotting for jQuery
16:52:21 <lsmola> tqtran: since we are slowly dropping Jquery, it might not be the best :-)
16:52:34 <tqtran> lsmola: oh we are?
16:52:43 <david-lyle> but it does add "Attractive"
16:52:52 <lsmola> tqtran: yeah there is very slow transformation to angular :-)
16:52:53 <david-lyle> so there's that reason
16:53:05 <tqtran> lsmola: but angular uses jquery =P
16:53:12 <david-lyle> tqtran: a subset
16:53:13 <lsmola> tqtran: it's very slow because there is not enough people :-)
16:53:39 <lsmola> tqtran: I don't think it does, it has it's own querying
16:54:14 <lsmola> tqtran: but I am no angular wizard yet :-D so I just think
16:54:43 <tqtran> lsmola: =P
16:55:46 <david-lyle> tqtran: at some point a decision has to be made to make progress, there's no guarantee any decision will stand the test of time or make everyone happy.  If there is a compelling reason to reevaluate, we can. Otherwise, we just thrash.
16:56:23 <david-lyle> But that doesn't mean we shouldn't question the decisions
16:56:35 <lsmola> tqtran: for now we are stuck in d3, cause there is a lot of things implemented in it :-)
16:56:59 <tqtran> david: yep, that sounds good. last summit, i didnt get a chance to show you some of my slides. i have a couple of ideas that could potentially make life easier if we switch to flot
16:57:17 <david-lyle> slides!
16:57:18 <david-lyle> :)
16:57:21 <tqtran> david: hhahahaha
16:57:33 <tqtran> david: and demos too
16:57:52 <lsmola> tqtran: hehe, I would like to see that :-)
16:58:07 <tqtran> lsmola: =) ok, i'll put it in the mailing list
16:58:39 <lsmola> tqtran: I see it is using html 5 canvas vs SVG with d3
16:59:09 <lsmola> tqtran: ok, thanks
16:59:10 <tqtran> lsmola: its canvas-based, but can also render in svg and even html elements
16:59:25 <lsmola> tqtran: ah, ok
16:59:56 <david-lyle> Time's up. Thanks everyone.  Have a great week and do some reviews for your fellow developer.
17:00:00 <david-lyle> #endmeeting