16:01:15 <david-lyle> #startmeeting Horizon
16:01:15 <openstack> Meeting started Tue Nov 18 16:01: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:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:19 <openstack> The meeting name has been set to 'horizon'
16:01:32 <david-lyle> Hello everyone!
16:01:35 <rhagarty> hello
16:01:38 <asahlin> hi
16:01:40 <akrivoka> hello! o/
16:01:41 <doug-fish> Hi all
16:02:11 <wuhg> Hello all
16:02:16 <crobertsrh> hello/
16:02:21 <Sanjay> hi
16:02:59 <rbertram> hi
16:03:02 <gary-smith> hi
16:03:15 <lhcheng> hello
16:03:36 <absubram__> hi
16:03:49 <david-lyle> All right, not much on the agenda for today.
16:03:50 <robcresswell> o/
16:04:11 <rdopiera> hi
16:04:11 <david-lyle> agenda can be found at: #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:04:58 <david-lyle> I've started planning out the Kilo blueprints
16:05:21 <david-lyle> #link https://launchpad.net/horizon/+milestone/kilo-1 reflects some of this
16:05:36 <david-lyle> There is a little cleanup to do on there
16:06:27 <david-lyle> until we move to a specs repo, there will still be un-prioritized bps at the bottom as that is author's way of asking for inclusion
16:07:03 <david-lyle> Additionally, we have some other blueprints that need to be reviewed, as we discussed at the summit
16:07:50 <david-lyle> Another observation from walking through the ~270 blueprints is people don't look for matching blueprints before crafting their own
16:08:05 <doug-fish> 270?!
16:08:09 <david-lyle> I think there are at least 4 bps around pagination in general
16:08:17 <david-lyle> doug-fish: yeah 270
16:08:28 <david-lyle> don't even look at the bug count
16:08:29 <doug-fish> It's not exactly clear to me which blueprints should still be reviewed.  Plus I'm a little bit lazy and might not study all 270.
16:08:36 <david-lyle> that's for another week
16:08:52 <david-lyle> doug-fish: well, I've created a list :)
16:09:09 <david-lyle> #topic Review Blueprints for Approval in Kilo
16:09:24 <doug-fish> hooray!  a list!
16:09:57 <david-lyle> on the meeting agenda I pasted roughly 12 bps that are written in the new format and should be considered for Kilo
16:10:25 <doug-fish> oh that list.  :-)
16:10:56 <david-lyle> I'm not sure walking through each in this meeting is the best use of time. But I would like to provide a little time for questions regarding any of those
16:11:32 <doug-fish> tough to ask questions before we've reviewed.
16:11:40 <david-lyle> let's give them a final yes/no next week
16:11:45 <david-lyle> understood
16:12:25 <david-lyle> There are also no blueprints I've found for the angular work that was agreed to at the summit
16:12:31 <rhagarty> and how does one suggest a blueprint for consideration?
16:13:22 <david-lyle> rhagarty: use the new template https://blueprints.launchpad.net/horizon/+spec/template and set the milestone
16:13:35 <david-lyle> to where in Kilo you think it would land
16:13:43 <rhagarty> thought I did that... will check
16:14:08 <doug-fish> I have a question kind of related to angular work.  I'm curious if we have any performance metrics for Horizon page load time.  I think one of our goals for using angular is to make Horizon load faster, but would be good if we had some way to measure that.
16:14:09 <david-lyle> rhagarty: I'll be honest, I haven't made it past k-1 yet
16:14:54 <doug-fish> (I have a fear in the back of my mind using angular is going to make our pages load slower)
16:15:08 <david-lyle> that would be ironic
16:15:30 <doug-fish> I've worked on single page apps before - that load time is tough and has to be managed.
16:15:44 <jpich> I think it's expected to make interactions faster, e.g. realising quicker you didn't fill that form correctly
16:15:45 <david-lyle> but worth categorizing
16:15:49 <jpich> or maybe i'm misunderstanding
16:16:14 <doug-fish> jpich - yeah that's true - the client side only interactions should be better
16:16:18 <david-lyle> doug-fish: we still have to load the data
16:16:18 <rdopiera> david-lyle: I added the oslo-config and stevedore entrypoints blueprints to kilo, not sure if in the right way...
16:16:45 <david-lyle> the idea is once the data is loaded, we won't keep reloading the data at every click
16:16:54 <david-lyle> so the overall performance should increase
16:16:57 <doug-fish> david-lyle: right, and if we aren't careful we are going to push out a data-less page, then go back and load data, so our load time would get slower by a full page load cycle.
16:17:09 <david-lyle> we can't really speed up the other service APIs
16:17:21 <doug-fish> understood.
16:17:22 <rdopiera> doug-fish: but that would be only on the login page :)
16:17:40 <rdopiera> on the other hand, we get async loading for free
16:17:55 <david-lyle> rdopiera: thanks
16:17:56 <rdopiera> which horizon currently doesn't have -- it does all the api calls serially
16:18:21 <doug-fish> sure - calling in parallel should be a nice benefit
16:18:40 <doug-fish> I'm just suggesting we think about how we measure it to make sure we are really getting the benefit we hope for.
16:19:25 <david-lyle> doug-fish: it is a realistic concern
16:19:38 <rdopiera> doug-fish: you want to have benchmarks for regressions on the gate?
16:19:46 <lhcheng_> if we are doing things in parallel using angular, there is a possibility to hit an issue on api rate limiting. something to validate later.
16:19:47 <rdopiera> doug-fish: that would be awesome :)
16:20:09 <wuhg> david-lyle:should the integration test use the net bp template?
16:20:17 <doug-fish> rdopiera:  ideally, I'd like to have those benchmarks.  I'm a bit concerned that we'll be measuring the peformance of the gate instead of the performance of Horiozn
16:20:31 <wuhg> s/net/new
16:20:39 <david-lyle> wuhg: for new blueprints yes, I've approved all the integration test bps I could find
16:20:50 <lhcheng_> we already saw this issue on usage page, call to ceilometer hits api rate limiting.
16:21:11 <david-lyle> those are fairly straight-forward and I just want them done :)
16:21:31 <lhcheng_> ++ on doug-fish's proposal to do some benchmarking
16:21:41 * david-lyle puts palm on face
16:21:43 <doug-fish> lhcheng_:  I'm not familiar with api rate limiting.  Do you know where I can find out more?
16:22:41 <doug-fish> nevermind.  google.
16:24:30 <lhcheng_> doug-fish: lol
16:24:37 <david-lyle> Around the blueprints for review and overlap in some cases, e.g., pagination, I'm going to pick the one that matches the agreed on path forward at the summit and point all other bp authors to that one
16:24:49 <david-lyle> and mark the other ones superseeded
16:26:27 <david-lyle> rhagarty: your bp in k-2 was trivial, just accepted it
16:26:32 <david-lyle> did you have another?
16:27:09 <rhagarty> david-lyle, the manage/unamange volume was the one I was thinking of
16:27:56 <david-lyle> rhagarty: not on my radar yet, but I haven't made it through all 270 yet
16:28:16 <david-lyle> wish there was a way to delete some
16:28:55 <david-lyle> I'll keep walking through them
16:29:04 <rhagarty> david-lyle, https://blueprints.launchpad.net/horizon/+spec/add-manage-unmanage-volume
16:29:18 <robcresswell> david-lyle: Sounds like a good plan to cut down on repetition
16:29:56 <david-lyle> any other concerns about blueprints for Kilo?
16:30:25 <asahlin> david-lyle:  Is there a cutoff date for submitting?
16:30:49 <david-lyle> asahlin: no, the list is fluid for the milestones until later in k-3
16:30:56 <doug-fish> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
16:31:01 <david-lyle> but it's nice to have them in plan before the last minute
16:31:11 <asahlin> david-lyle: understood, sooner the better
16:31:12 <doug-fish> and that's not for a while
16:31:24 <david-lyle> I'm going to try and minimize the core-reviewer overload as much as possible
16:31:39 <david-lyle> that may mean leaving some perfectly good ideas out
16:31:40 <amotoki_> do we obsolete old submitted blueprints? 270 is really too big number.
16:31:57 <david-lyle> amotoki_: I'm open to suggestions
16:32:11 <david-lyle> some are good ideas but need more details and an owner
16:32:48 <david-lyle> I can mark the dormant ones obsolete and ask for a resubmit if they are still desired
16:32:56 <david-lyle> there are bps from 2012 in there
16:33:03 <amotoki_> it is a good idea to leaving a comment to follow our new bp requirement before obsoleting them.
16:33:19 <david-lyle> I agree
16:33:41 <amotoki_> if authors still have interests on working, they should update details.
16:33:50 <david-lyle> amotoki_: ++
16:34:09 <david-lyle> I'll continue the clean upd
16:35:22 <david-lyle> #topic Open Discussion
16:35:56 <john-davidge> We'd like to talk about upstreaming Curvature if there's interest in the community?
16:36:15 <john-davidge> And if so, we need to agree a stregegy for doing so
16:36:38 <rdopiera> sorry, but what is curvature?
16:36:57 <gary-smith> spine anomaly
16:37:01 <john-davidge> https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe
16:37:20 <john-davidge> Shorter video demo: http://youtu.be/oFTmHHCn2-g
16:37:24 <david-lyle> john-davidge: at the summit we saw image launch, what is does curvature control?
16:37:45 <asahlin> would curvature be a replacement (more advanced) for the network topology that's in horizon
16:38:46 <john-davidge> We currently see it as a new/alternative dashboard view. It could replace the current network topology view but it also has more functionality than just that
16:40:49 <david-lyle> this seems like a heat template generator
16:40:51 <john-davidge> david-lyle: The video demo should explain everything quite well, but curvature can be used to deploy/modify/destroy instances, networks, routers, volumes
16:41:02 <david-lyle> your doing orchestration outside of heat
16:41:13 <david-lyle> s/your/you're/
16:41:22 <david-lyle> essentially
16:41:40 <john-davidge> david-lyle: You raise a good point
16:42:09 <david-lyle> I think that would be a great improvement for our heat UI
16:42:11 <amotoki_> agree. it seems a kind of visual editing  of heat template or more.
16:42:21 <asahlin> john-davidge:  I watched your demo, it does look pretty cool.   Everyone likes interactive UI's.
16:42:37 <rbertram> I watched the vid, & wondered how curvature works at scale.
16:42:44 <rbertram> I do agree it is cool.
16:42:53 <david-lyle> And I could see parts of this in the network topology as well
16:43:19 <john-davidge> rbertram: It handles up to arounf 2k instances quite well, after that browser performance becomes an issue
16:43:35 <rbertram> interesting.
16:44:15 <amotoki_> it is a big topic how we can manage ~1k instances thru GUI :-)
16:44:26 <rbertram> so it's for admin as well as individual projects
16:44:38 <david-lyle> what's the graphing algorithm for 2k nodes, cone tree?
16:45:00 <john-davidge> rbertram: We see it as being most useful to new users who aren't nessessarily familiar with SDN concepts, but can be used by anyone
16:45:27 <john-davidge> rbertram: Great for at-a-glance viewing of tenant activity
16:45:37 <sambetts> david-lyle: its of our own invention on top of D3 cross referencing the OpenStack data
16:46:03 <rbertram> john-davidge: the new user still has to learn what can connect to what, the meaning of colors, etc. Done user testing?
16:46:17 <sambetts> david-lyle: we've not done anything special just making sure D3 knows where to put links
16:46:25 <david-lyle> sambetts: when you hit 2k nodes a meaningful layout becomes difficult
16:46:30 <john-davidge> rbertram: limited user testing, yes. But community feedback is what we're currently seeking :)
16:46:40 <robcresswell> Yeah, people mentioned at the summit that it would be good to have different "personas" (sp?) I think the word was, for different levels of user.
16:46:58 <robcresswell> We wondered if Curvature would help with this goal
16:47:04 <sambetts> david-lyle: agreed
16:47:16 <john-davidge> david-lyle: absolutely, at scale it become less useful, but not as quickly as the current network topology
16:47:32 <doug-fish> when you say "we are constantly getting information back from openstack" how is it interacting with the other services?
16:47:32 <amotoki_> apart from 2k nodes :-) I agree it can be a good replacement of network topology and "network topology" is a kind of "overview" for users.
16:47:33 <david-lyle> john-davidge: very true
16:47:48 <david-lyle> amotoki_: ++
16:47:59 <asahlin> amotoki_: +1
16:48:16 <asahlin> IMO, that is where I picture it fitting in.
16:48:32 <rbertram> john-davidge: still wondering about knowing what can connect to what, couldn't tell from video if it helps know that
16:49:14 <david-lyle> I think that makes the most sense, but once we start building up the topology before pushing, I think that would best be in heat template generation
16:49:24 <john-davidge> rbertram: Curvature will only allow the user to draw valid connections. Trying to draw an invalid link just doesn't do anything currently.
16:50:12 <sambetts> david-lyle: thats fine for template generation, but can you live modify a deploied heat template?
16:50:42 <david-lyle> sambetts: you can modify a template and restack
16:50:50 <rbertram> john-davidge: OK. not a showstopper, but potential improvement for future to show which nodes are valid when user starts connecting.
16:50:55 <john-davidge> david-lyle: I guess perhaps we're filling a gap between single actions and template generation. You don't nessesarily want to save each set of deploy/edit actions as a heat template everytime.
16:50:57 <sambetts> is that a complete redeploy?
16:51:32 <john-davidge> rebertram: Yes that's a good idea. Perhaps something along the lines of greying out invalid nodes when the root node is selected?
16:51:35 <david-lyle> but I think this works in lieu of the network topology, but complete the actions as they are made, rather than delaying them
16:52:02 <amotoki_> the recent development of network topology is not so active, and it would be really great if we have more active contributions :-)
16:52:12 <rbertram> john-davidge: yeah - just thinking of novices
16:52:19 <amotoki_> in addition, we can switch both panels.
16:52:41 <david-lyle> I think the first blueprint should target updating/replacing network-topology
16:53:16 <david-lyle> we can hash out the interaction details in the blueprint process
16:53:52 <doug-fish> yeah good approach.  this is really cool and would be a great improvememt
16:53:57 <david-lyle> then perhaps use that foundation for generating heat templates, if there is desire to do so by the developers
16:54:04 <robcresswell> david-lyle: Sounds like a good start to us. We're really keen on getting community input on how it would be useful.
16:54:13 <robcresswell> We'll work on a blueprint
16:54:16 <rbertram> How easy is it to install as-is, so people can play with it hands-on?
16:54:24 <david-lyle> might make a good landing page, once it's in
16:54:25 <john-davidge> david-lyle: That sounds like a sensible place to start.
16:54:46 <david-lyle> I always wanted a more visual landing page
16:54:47 <robcresswell> rbertram: https://github.com/CiscoSystems/curvature
16:55:06 <sambetts> rbertram: The README on that github should get you up and running ^^
16:55:08 <robcresswell> Its straightforward, but currently uses Ruby
16:55:10 <david-lyle> network topology just didn't quite get there
16:55:17 <john-davidge> david-lyle ++
16:55:33 <amotoki_> +1
16:55:59 <robcresswell> On the subject of network topology, is that why we still include jquery-ui?
16:56:18 <robcresswell> I was wondering why we still have jquery-ui and bootstrap
16:56:24 <david-lyle> I think there may be another reason, but it escapes me
16:56:31 <david-lyle> a date picker maybe
16:56:36 <rbertram> yeah
16:56:37 <john-davidge> Great, well as long as there's interest that gives us something to work towards. Once there's some working code up for review we can talk more about where exactly it will all fit in.
16:57:01 <robcresswell> david-lyle: Fair enough. I was wondering about getting rid of it. It seems an unnecessary requirement, doesnt it?
16:57:04 <rbertram> but I thought there were other things
16:57:06 <david-lyle> john-davidge: please write up a blueprint and target it to k-2 or k-3
16:57:08 <robcresswell> john-davidge: +1
16:57:25 <john-davidge> david-lyle: Will do!
16:57:40 <amotoki_> BTW, there are two hot topics on the dev list: JS tooling (especially dependency management) and horizon/dashboard split.
16:57:45 <david-lyle> robcresswell: well the calendar date picker would need a replacement
16:57:55 <amotoki_> I would like to see who leads the work, and they are good candidates of next week topics.
16:58:29 <amotoki_> (regarding splitting, mrunge is leading the work already)
16:58:38 <david-lyle> amotoki_: indeed, I wanted the distro vs js developer debate to drift toward a mutually acceptable solution
16:58:47 <robcresswell> david-lyle: Yes, understood. I just meant the library seems a bit much for a date picker.
16:58:56 <robcresswell> david-lyle: I'll look into it.
16:58:58 <david-lyle> robcresswell: oh, absolutely
16:59:07 <david-lyle> no argument here
16:59:34 <david-lyle> amotoki_: for the split, I think we need mrunge here to discuss
16:59:42 <rbertram> robcresswell: are you just asking why we have jquery-ui? or also why we have bootstrap?
16:59:56 <david-lyle> maybe with the offset meeting times
16:59:59 <amotoki_> david-lyle: no doubt on that.
17:00:02 <david-lyle> which is another thread
17:00:04 <robcresswell> rbertram: Why we have both. I thought they achieved similar things.
17:00:09 <david-lyle> please fill out the doodle
17:00:15 <david-lyle> also on the mailing list
17:00:25 <david-lyle> time's up, thanks everyone!
17:00:29 <david-lyle> #endmeeting