20:01:22 <robcresswell> #startmeeting HorizonDrivers
20:01:24 <openstack> Meeting started Wed Feb 17 20:01:22 2016 UTC and is due to finish in 60 minutes.  The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:27 <openstack> The meeting name has been set to 'horizondrivers'
20:01:31 <r1chardj0n3s> hey, a bot!
20:01:33 <robcresswell> Success!
20:02:09 <TravT> if i remember right, david-lyle is on biz travel this week
20:02:16 <robcresswell> Yup
20:02:25 <robcresswell> So, notices
20:02:42 <robcresswell> 2 weeks till M-3. Make sure your bps are ready for review and start nagging them cores.
20:03:26 <robcresswell> I'd like to avoid having quite so many FFEs this cycle :)
20:03:48 <TravT> i have an idea for clearing the review backlog
20:03:52 <robcresswell> We have the midcycle coming up too so we can get through some reviewing I imagine
20:04:08 <TravT> let's just approve all of them and see what happens.  :P
20:04:29 <robcresswell> >.<
20:04:43 <^Gal^> I have a design question, was told the drivers meeting is the place to be
20:04:53 <^Gal^> regarding a patchset i suggested
20:05:04 <robcresswell> The other notice is the midcycle: make sure your topics are up for discussion https://wiki.openstack.org/wiki/Sprints/HorizonMitakaSprint
20:05:08 <robcresswell> See the etherpad linked inside
20:05:21 <robcresswell> If you can't make it, ask somebody else to represent :)
20:05:51 <robcresswell> Anyone else have any general notices?
20:06:10 <robcresswell> ^Gal^: One moment :)
20:06:17 <r1chardj0n3s> got that bug smash link handy? :-)
20:06:21 <^Gal^> sure, np :)
20:06:25 <r1chardj0n3s> https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
20:06:34 <robcresswell> dammit, beat me to it.
20:06:34 <r1chardj0n3s> (still open from last night ;-)
20:06:57 <robcresswell> So, this is very similar to the bug day we've been doing within Horizon, but much bigger.
20:07:11 <robcresswell> Well. more with a focus on actually solving them
20:07:31 <robcresswell> Either way, it aligns well IMO, and it would be good to drive attendance.
20:07:59 <robcresswell> So please read the etherpad and get involved.
20:08:36 <robcresswell> I think thats all for notices, and there are no agenda items.
20:08:53 <robcresswell> #topic Open Discussion
20:09:01 <robcresswell> ^Gal^: Go ahead
20:09:04 <^Gal^> yey
20:09:14 <^Gal^> regarding the patchset https://review.openstack.org/#/c/271771/
20:09:23 <^Gal^> Added option for cell_attributes_getter to return row data
20:09:39 <^Gal^> Hm I needed cell to access fellow cell's data
20:09:54 <^Gal^> and came out with a solution
20:10:05 <^Gal^> but it is not quite neat design wise
20:10:27 <^Gal^> just wanted to hear your thoughts and how should I approach that one
20:11:03 <tsufiev> tables code is already crumbling upon its own weight :/
20:11:26 <^Gal^> yeah I guess we'll better of angular
20:11:34 <^Gal^> but just for a quick python solution
20:11:54 <robcresswell> We're not giving up on python tables just because angular exists :/
20:12:21 <^Gal^> :)
20:14:06 <tsufiev> If it's needed by only one table, why not implement it in that specific table?
20:14:21 <^Gal^> just what I did
20:14:31 <^Gal^> just thought it'll be nice to have in Horizon base
20:14:43 <^Gal^> IMO anyhow
20:14:58 <robcresswell> Hmm. If its not common code, and there doesn't appear to be any need from other developers
20:15:08 <robcresswell> I'm inclined to say no
20:15:48 <^Gal^> I understand where you're coming from, just thought it is quite basic for cell to adress its row members
20:16:42 <robcresswell> Right, but there's no need for it
20:17:01 <robcresswell> Unless there's a good use case for Horizon, I don't really see the value in adding more complexity.
20:17:32 <^Gal^> OK
20:17:34 <tsufiev> +1 on banning more complexity w/o clear use cases
20:17:48 <^Gal^> hmm
20:17:52 <^Gal^> my use case is a tooltip
20:18:14 <^Gal^> of a success row
20:18:40 <^Gal^> if it is unsecessful, show the error on a quick hover
20:18:46 <^Gal^> unsuccessful
20:19:08 <^Gal^> but if you guys think it's an overhead for the entire Horizon, I understand
20:19:35 <robcresswell> Yeah, I'd prefer you just kept it in the plugin unless there is a requirement from other code.
20:19:46 <^Gal^> sure
20:19:59 <robcresswell> Any other bps/ items to discuss?
20:20:01 <tsufiev> ^Gal^: do you want to show a specific tooltip for a any cell in a row if a specific cell has specific state?
20:20:01 <^Gal^> thanks for your thoughts
20:20:13 <mnaser> i had some ideas regarding the long term arch. of horizon.  i wanted to know how does everyone feel about adopting a model where horizon becomes a lightweight proxy (that basically works around cross domain requests) with an option for deployers to just use apache + mod_proxy as a stronger option.. and basically having a strong powerful frontend that talks to native openstack api's... this would obviously be a very long-term thing
20:20:56 <mnaser> having this type of thing implemented with swift for starters would make it much better performing and makes scaling horizon easier for example
20:20:57 <^Gal^> tsufiev: yep something like that
20:21:24 <^Gal^> tsufiev: I did manage to acheive what I was after, just thought I'll contribute it
20:21:35 <tsufiev> ^Gal^: then you could add a specific class to every cell and act accordingly
20:22:38 <^Gal^> tsufiev: oh - I wanted only to show tooltip on one cell, but to alter the tooltip data
20:22:48 <tsufiev> mnaser: are you talking about swift refactoring richardjones is currently working on?
20:22:51 <robcresswell> mnaser: Aren't you basically just proposing a different UI?
20:23:09 <^Gal^> tsufiev: and for that i needed to access the row data, for me to get to other cells data
20:23:19 <robcresswell> I mean, that sounds like an entire rewrite without using any of the existing code, no?
20:23:30 <mnaser> user interface can be the same, but the idea is to minimize client => horizon communication and try to adopt a client => openstack APIs directly
20:24:03 <tsufiev> ^Gal^: well, you could just modify that cell attrs with oython
20:24:08 <tsufiev> Python
20:24:34 <mnaser> if horizon keeps adopting more angular related things in it and includes more client-side logic, then why not just talk directly with openstack if most of the logic will sit in the angular controllers/et
20:25:08 <mnaser> i'm not sure if the current swift refactoring includes communicating directly with swift, so im not aware of that
20:25:46 <robcresswell> mnaser: The "why not" would be because we don't have time to start rewriting APIs that frankly, work okay.
20:26:33 <mnaser> sure, but the idea is to look into adopting the model (as I can see, there's lots of refactors happening to use angular that still talk with horizon)
20:26:53 <robcresswell> Well... propose a patch :)
20:27:03 <robcresswell> IIRC krotscheck was working on CORS support
20:27:21 <mnaser> well, the idea was to hear what everyone feels about it as a project before starting some work
20:27:44 <mnaser> if there's any stoppers or issues that may seem problematic for anyone here, perhaps its good to hear them
20:27:57 <r1chardj0n3s> sorry, wandered off for a moment there
20:28:05 <tsufiev> I feel it's many steps ahead of where we're now
20:28:10 <r1chardj0n3s> mnaser: your proposal is pretty much what I took to the Horizon devs about 18 months ago
20:28:11 <krotscheck> yesssss
20:28:35 <robcresswell> krotscheck: Heh, thought you might like to be involved.
20:28:42 <krotscheck> Yeah, reading backscroll
20:28:44 <mnaser> i'll disclose, we have our own control panel (vexxhost), we spent a lot of time building it but we want to start adopting horizon now instead of our own portal
20:28:48 <r1chardj0n3s> mnaser: and the community decision at the time was to go with the middle ground approach we're currently implementing
20:29:08 <krotscheck> Swift is the only API that is not using the oslo middleware cors support - they ahve their own implementation.
20:29:09 <mnaser> we started out with a similar horizon model, right now, we have angular talking to openstack APIs directly (with nginx proxying for cors issues)
20:29:20 <r1chardj0n3s> mnaser: my implementation is here https://github.com/r1chardj0n3s/angboard
20:29:54 <krotscheck> All other API's implement oslo_middleware's version.
20:30:05 <mnaser> i know it's a huge leap but the performance improvements we saw, as well as easier overall code usage
20:30:42 <mnaser> krotscheck: we wanted to avoid messing with existing cors settings of services so we proxied back to the api endpoints using nginx, this could be easily done in apache over the long term
20:31:22 <mnaser> i know it's a biiiiiig leap away, but long term it'll help scaling, make codebase easier (logic is kinda duplicated), and runs much faster
20:31:48 <krotscheck> mnaser: That only works until you hit API's that express internal data relationships in absolute URL's.
20:31:53 <mnaser> r1chardj0n3s: i've actaully ran into that impl and i was sad to see it was kinda left out
20:32:19 <mnaser> krotscheck: true, but we basically started using async.js to do fetching logic to retrieve what we need
20:32:50 <mnaser> for example, for server detail page, initial server request, then flavor and image info request can happen in parallel too
20:33:28 <mnaser> first-load will be much faster, extra info will load in eventually after
20:33:53 <TravT> mnaser: i've been thinking about doing that kind of approach on my search panel
20:34:19 <TravT> are you coming to the mid-cycle?
20:34:34 * krotscheck_dcm wasnt able to line up daycare.
20:35:09 <mnaser> TravT: no, ill be at the summit however
20:35:35 <mnaser> (but that could be a bit too late :-p)
20:35:41 <r1chardj0n3s> why too late?
20:35:53 <TravT> mnaser: that's not too late.
20:36:05 <mnaser> oh okay, that works then :)
20:36:17 <r1chardj0n3s> as I said, this conversation started 2 years ago :-)
20:36:59 <mnaser> and i dont mind sharing our experience in this and maybe even showing some of the code which we use and how we solved issues that the horizon team might feel like they will come up down the road
20:37:28 <robcresswell> I don't think anyone strongly disagrees with it. Any idea that results in a faster UI is obviously good. The issue is how to manage workload and how we maintain a forward moving UI while simultaneously rewriting huge chunks of it.
20:37:45 <r1chardj0n3s> what rob said
20:38:30 <tsufiev> +1
20:38:52 <mnaser> I guess all it boils down to: first, the foundation has to be laid down, the ability to requests that go through a very very lightweight path and using an auth token only to talk with any API from the existing angular modules
20:39:09 <TravT> mnaser: i do have a question that you could maybe refer me to. why async.js over angular promises and $q functions?
20:39:25 <r1chardj0n3s> mnaser: that's the easy bit ;-)
20:39:49 <r1chardj0n3s> (I was also curious about async.js)
20:39:51 <mnaser> TravT: easier flow control mostly.  async.js gives you a nice way to transition between one callback to another
20:40:13 <mnaser> $q doesnt allow for as easy or clean code for these flows
20:40:59 <mnaser> i think if i remember, you have $q method to allow for using more than a single promise
20:41:08 <mnaser> but, that's about it
20:42:05 <mnaser> r1chardj0n3s: but i think once we establish the foundation, and we can get one or two small panels migrated (say.. list of agents, or something like that)
20:42:29 <robcresswell> So much deja vu, this is glitch in the matrix time.
20:42:31 <tsufiev> Hehe
20:42:41 <mnaser> and then the simplicity and how fast the code works could perhaps encourage slowly starting to use it for bigger use-cases
20:42:42 <r1chardj0n3s> robcresswell: heh, I know, right?
20:42:44 <mnaser> haha :-P
20:42:58 <TravT> mnaser: that's already in progress.
20:43:03 <TravT> come join the fun
20:43:19 <mnaser> this is why i wanted to bring this up here and maybe help speed up the process :)
20:43:26 <r1chardj0n3s> we're not using a direct proxy because the APIs are typically quite terrible :-)
20:43:33 <r1chardj0n3s> and Horizon already wraps them in a layer of nice
20:43:36 <r1chardj0n3s> well
20:43:38 <r1chardj0n3s> nicer
20:43:56 <mnaser> so what stops us from having that layer of nice on the client side? :)
20:44:09 <r1chardj0n3s> that's precisely what we're doing right now :-)
20:44:16 <r1chardj0n3s> oh, not the API fix stuff
20:44:26 <TravT> well, eventually API could get us there
20:44:29 <r1chardj0n3s> because that stuff is already written in Horizon
20:44:37 <TravT> we have a API layers client and horizon server side
20:44:45 <r1chardj0n3s> why write it again in JS when it's already there in Python?
20:45:03 <TravT> in *THEORY* the client side API could at some point change to direct access *if needed*.
20:45:07 <robcresswell> One thing I am curious about, is why python hangs when loading a detail page but angular manages it in <1 second, when hitting the same API.
20:45:09 <r1chardj0n3s> hmm, the API "layer" is intentionall very thin on the client side, yes TravT?
20:45:31 <tsufiev> robcresswell: django overhead?
20:45:32 <r1chardj0n3s> robcresswell: which detail page in particular?
20:45:36 <mnaser> robcresswell: my experience is the same, i've always tried to figure out why but never could.  there is just so much django overhead
20:45:51 <r1chardj0n3s> OK, wait up
20:45:54 <robcresswell> r1chardj0n3s: Compare images in python to angular. The difference is v noticeable.
20:46:08 <r1chardj0n3s> the swift UI, which also goes through Django, is almost delay-free
20:46:29 <r1chardj0n3s> so I'd like to know which angular details page appears to be incurring a Django hit, as I'd like to know why
20:46:47 <tsufiev> I think horizon tables code is then to blame
20:46:48 <r1chardj0n3s> (sorry, the *new* swift UI, obviously ;-)
20:46:52 <robcresswell> Nono, you're misreading I think.
20:47:09 <mnaser> (ps: the new swift ui proposal looks amazing! +1)
20:47:23 <robcresswell> I'm saying that if you compare python image details to angular, I'm surprised at how fluid angular is. Granted, there are obvious benefits to client side magic.
20:47:28 <r1chardj0n3s> ok, so Python details pages are doing *way* more than just hitting that one API. They're also typically hitting all those other APIs like extensions, etc
20:47:42 <r1chardj0n3s> mnaser: thanks :-)
20:47:47 <robcresswell> And the angular ones just aren't right now?
20:48:02 <robcresswell> well, angular *one* :p
20:48:56 <r1chardj0n3s> robcresswell: for an initial angular page load, yes you still need to hit those things (because we're not Single Page App yet) but for the ng images stuff the detail page is SPA and only needs to load that one API call because the rest of the page is already loaded
20:49:11 <r1chardj0n3s> I *think* that minght be the detail page you're thinking of
20:49:20 <robcresswell> Sure, thats the one.
20:49:22 <TravT> mnaser: this talk from vancouver gives some background on where we are (which is after when the big explosions happened at the summit before it).
20:49:23 <TravT> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/beyond-the-horizon-innovating-and-customizing-horizon-using-angularjs
20:49:43 <robcresswell> Just surprised at the speed difference. Makes me think we're doing something very wrong in our django views.
20:49:47 <r1chardj0n3s> also, the images detail page async loads several APIs to fill in its details whereas the Python implementation will serially hit those APIs in turn
20:49:49 <mnaser> i'll spend sometime looking at that
20:50:04 <r1chardj0n3s> robcresswell: yes, zero parallelisation :-)
20:50:11 <robcresswell> That could be causing it. I'll look into it more.
20:50:31 <r1chardj0n3s> parallelising inside django ... eek :-=)
20:50:51 <mnaser> so i guess what we could say here is to continue to build on these client facing APIs of horizon
20:50:52 <TravT> r1chardj0n3s: robcresswell: even if we parallelized on django side, you wouldn't get the progressive disclosure without intro-ing some other black magic
20:51:01 <r1chardj0n3s> yep
20:51:03 <mnaser> and should we one day want to speed things up, we can implement those "nice" APIs on the client side?
20:51:14 <TravT> e.g. show base instance details and paint in additional project, flavor, etc details afterwards
20:51:18 <r1chardj0n3s> mnaser: that was my secret plan, yes
20:51:28 <TravT> shhh
20:51:35 <r1chardj0n3s> it's not really a secret ;-)
20:51:36 <robcresswell> TravT: Oh sure. The angular is a big improvement on fluidity.
20:51:36 <TravT> don't tell anybody!
20:51:41 <mnaser> alright, well this clears things out overall
20:51:55 <mnaser> one question (and maybe i should go read the horizon codebase about this)
20:52:04 <TravT> manser: there is a really cool demo that a few of will be doing at the mid-cycle using searchlight as well
20:52:12 <TravT> maybe we'll make a recording and send it along
20:52:17 <robcresswell> TravT: As I said, I was just suprised at the sheer difference. On devstack its like zero load in angular vs a several second hang in django.
20:52:44 <robcresswell> r1chardj0n3s: I was arguing with the london designers about swift UI today :p
20:52:58 <mnaser> oops i almost printed the entire buffer of this channel out, hah.
20:52:58 <r1chardj0n3s> robcresswell: fight the good fight! :-)
20:53:20 <r1chardj0n3s> I've tried to be inspired by some of their ideas in my patch
20:53:22 <mnaser> but are the angular pages still very much tied up to the django backend (ex: table actions, etc) or are they defined in the angular side of things?
20:53:31 <TravT> angular side
20:53:41 <r1chardj0n3s> yep, very much angular side
20:53:42 <robcresswell> r1chardj0n3s: I told them to shift the breadcrumb so its usable, work on making the container delete more clear
20:53:43 <TravT> django provide API pass through, negotiation
20:53:58 <r1chardj0n3s> robcresswell: snap, that's what I told 'em too :-)
20:54:09 <mnaser> ok good, we're really really trying to leave our panel and move our customers to horizon, but we want to get it to a good state
20:54:20 <mnaser> (i'd be more than happy to share our customers feedback as the roll out starts)
20:54:33 <TravT> sounds like a great topic for the summit in Austin
20:54:40 <mnaser> for example, instance actions right now are really poorly done :-(
20:54:54 <r1chardj0n3s> mnaser: we have a UX team that's always looking to involve actual users in their design process!
20:54:59 <robcresswell> mnaser: Best way would be to get involved in the angular work IMO. The API is good enough I think.
20:55:01 <mnaser> on the details page, they're stolen from the table instance actions, so doing any action will redirect you back to the list of servers
20:55:05 <robcresswell> Yeah, talk to piet!
20:55:10 <r1chardj0n3s> mnaser: please talk to piet!!
20:55:12 * tsufiev curious if with all these great promises we still need to optimize django views performance?
20:55:31 <TravT> robcresswell: r1chardj0n3s: that is part of what the registry patch solves on angular side
20:55:31 <robcresswell> tsufiev: We're still a long way from replacing all of django.
20:55:36 <r1chardj0n3s> tsufiev: we still need to concern ourselves with horrible API performance :-)
20:55:36 <TravT> decoupling actions for views
20:55:39 <tsufiev> Page more tables, optimize calls, other stuff...
20:55:39 <mnaser> we also introduced a new networking tab into horizon, perhaps we'll submit a patch if folks feel that it's something that's wanted? let me show quickly
20:55:55 <mnaser> and i'll try to get in touch with piet in that case
20:55:58 <r1chardj0n3s> TravT: not sure I follow the connection
20:56:21 <mnaser> i mean our horizon doesnt look so horizon-y anymore but
20:56:26 <robcresswell> mnaser: Just looking at time, but feel free to share images or blueprint ideas in the Horizon chat after.
20:56:33 <mnaser> ah gotcha
20:56:57 <robcresswell> The intel guys in London have some good suggestions for improving the base Horizon theme.
20:57:02 <TravT> r1chardj0n3s: connection is that we want the actions to truly not be bound to any particular view (details, particular table, etc)...
20:57:05 <robcresswell> ux midcycle has been interesting so far
20:57:16 <TravT> but maybe better to talk elsewhere (time running thin)
20:57:24 <mnaser> i'll be in #openstack-horizon
20:57:33 <r1chardj0n3s> TravT: sure, I'm cool with that :-)
20:57:37 <TravT> robcresswell: what's coming out of it
20:57:55 <robcresswell> mnaser: FYI, there are simple workarounds for that redirect issue in django.
20:58:02 <robcresswell> We could definitely fix that.
20:58:34 <mnaser> yup, its quite poor ux imho
20:59:20 <robcresswell> We're almost at time
20:59:25 <robcresswell> Anything else?
20:59:34 <mnaser> i'm good, good interesting discussion :)
20:59:38 <r1chardj0n3s> thanks all
20:59:53 <robcresswell> Yup, good discussion, thanks everyone!
21:00:03 <^Gal^> thanks, take care
21:00:04 <robcresswell> #endmeeting