16:01:10 <david-ly_> #startmeeting Horizon
16:01:11 <openstack> Meeting started Tue Sep 23 16:01:10 2014 UTC and is due to finish in 60 minutes.  The chair is david-ly_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:14 <openstack> The meeting name has been set to 'horizon'
16:01:16 <jrist> o/
16:01:21 <ericpeterson> yo
16:01:22 <crobertsrh> Hello/
16:01:25 <jgravel> hi
16:01:28 <gary-smith_> hello
16:01:35 <clu_> hi!
16:01:36 <doug-fish> Greetings.
16:01:59 <amotoki> hi
16:02:16 <pawelss> Hi
16:02:34 <akrivoka> hello
16:02:40 <jomara_> hi
16:02:41 <akrivoka> \o
16:02:44 <tmazur> o/
16:02:49 <absubram_> hi
16:03:02 <johnma> hello
16:03:05 <lcheng> hello
16:03:19 <gugl2> hi
16:03:51 <david-ly_> I wanted to start by discussing RC1
16:04:00 <david-ly_> https://launchpad.net/horizon/+milestone/juno-rc1
16:04:10 <david-ly_> I've been cleaning up the list of items for RC1
16:04:18 <rdopieralski> hi
16:04:26 <david-ly_> I still have a few more to prune
16:04:45 <david-ly_> the idea is that we can't close RC1 until the remaining list are merged
16:05:02 <david-ly_> other bugs can merge opportunistically, but don't need to be assigned to RC1
16:05:35 <david-ly_> does anyone have info on https://bugs.launchpad.net/nova/+bug/1299517?
16:06:46 <david-ly_> I see no Horizon related work attached to that, i.e., no patches
16:07:11 <david-ly_> may punt that to K-1 unless anyone has a strong objection
16:07:23 <doug-fish> I'm kind of concerned about that
16:07:36 <doug-fish> I got significant grief about the missing function
16:08:03 <doug-fish> This should mostly be about restoring the code that once existed, right?
16:08:07 <david-ly_> doug-fish: it's an admin extension though, is it not?
16:08:26 <doug-fish> maybe?
16:08:33 <david-ly_> doug-fish: I don't see a patch at this point
16:08:45 <david-ly_> I'll look more later today before punting it
16:08:51 <doug-fish> What if I created one today?
16:09:17 <david-ly_> make it so :)
16:09:18 <doug-fish> Maybe I'm being naive, but I think this is a simple matter of restoring the panel as it existed in Havana
16:09:26 <ericpeterson> is this something you could test if the extension is avail, then disable as needed????
16:09:37 <david-ly_> ericpeterson: there is now
16:09:45 <amotoki> Isn't related to the default quota work?
16:09:56 <doug-fish> ericpeterson:  if that's how it worked in Havana, I'd be happy to do so
16:09:58 <amotoki> I see jpich's comment https://bugs.launchpad.net/nova/+bug/1299517/comments/3
16:11:10 <david-ly_> ok, doug-fish see where you get to
16:11:15 <doug-fish> will do.  Thanks!
16:11:20 <doug-fish> (for the extra work)
16:11:23 <doug-fish> :-)
16:11:29 <david-ly_> I'm not sure it's a release blocker, but I'll leave it for now
16:11:46 <david-ly_> we started the day with 44, so we're looking better
16:12:08 <david-ly_> I left two of the mediums because they are already approved and in the gate
16:12:16 <david-ly_> which seems to be suffering again
16:12:52 <david-ly_> rdopieralski: django-pyscss, just blocked on requirements FFE?
16:12:58 <david-ly_> correct?
16:14:08 <david-ly_> other than that I think the remainders are just a matter of reviews
16:14:21 <gugl2> david-ly_, https://review.openstack.org/#/c/121714/ was in rc-1, it is approved and waiting for passing the gate...but I saw you moved it to k-1, what does it mean?
16:14:52 <david-ly_> gugl2: just that I won't hold release of RC1 if it doesn't make it through the gate by the time we cut RC1
16:15:01 <david-ly_> which I hope to be the end of the week
16:15:08 <amotoki> david-ly_: https://bugs.launchpad.net/horizon/+bug/1324634 can be deferred to Kilo. I don't see any negative impact so far.
16:15:40 <gugl2> david-ly_, thanks
16:15:41 <david-ly_> amotoki: ok done, we'll see if we can add it opportunistically
16:16:06 <amotoki> the exact behavior is a bit different but there is no case we hit actually.
16:16:26 <david-ly_> would be nice to have
16:16:53 <david-ly_> once we cut RC1, it will be on a branch and master will open for Kilo commits
16:16:58 <amotoki> regarding yves's session timeout handling, I sent a mail of django-openstack-auth dependency FFE
16:17:01 <amotoki> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046799.html
16:17:22 <amotoki> but the deadline is over last Friday and it is pending approval.
16:17:38 <david-ly_> amotoki: I saw, in the program meeting later today FFEs on requirements will be discussed
16:17:54 <david-ly_> we have two that should go through
16:17:55 <amotoki> david-ly_: thanks please.
16:18:33 <david-ly_> and we'll open an RC2 for final translations
16:18:44 <david-ly_> and hopefully no critical bug fixes
16:18:45 <rdopieralski> david-ly_: yes, sorry, I was distracted
16:18:47 <david-ly_> hopefully
16:18:55 <david-ly_> rdopieralski: no problem
16:19:23 <david-ly_> rdopieralski: the jquery bug is a nice to have at this point correct
16:19:30 <david-ly_> not an essential
16:19:31 <david-ly_> ?
16:19:45 <rdopieralski> david-ly_: yes
16:19:55 <david-ly_> ok, thanks!
16:19:59 <rdopieralski> david-ly_: it will save packagers work
16:20:21 <david-ly_> understood, there really shouldn't be a reason not to accept the FFE on it
16:20:42 <david-ly_> I'll see how we do later today
16:21:10 <david-ly_> The agenda for today is https://wiki.openstack.org/wiki/Meetings/Horizon
16:21:25 <david-ly_> #topic Future of table sorting/filtering/count/paging
16:21:34 <david-ly_> clu_: is that you?
16:21:42 <clu_> david-ly_: yes :)
16:22:23 <clu_> not sure what the plan is anymore - since it seems like keystone v3 doesn't support any pagination, instead relies on filtering?
16:23:09 <david-ly_> clu_: I've made the proposal to look at controlling all the pagination, filtering, sorting, etc in Horizon
16:23:23 <david-ly_> I need to back it with a BP and a prototype
16:23:33 <clu_> so do you think it's up to horizon to provide the complete solution?
16:23:57 <clu_> regardless of what the project api supports?
16:23:58 <david-ly_> I think we can't count on the various services to provide a consistent interface, so we need to own it
16:24:03 <rbertram> david-ly: does that imply caching all the data, rather than getting it directly from services?
16:24:23 <david-ly_> rbertram: it means asking for more data from the services
16:24:24 <david-ly_> yes
16:24:29 <asahlin> +1 to consistency
16:25:15 <clu_> what about consistent filtering?
16:25:32 <david-ly_> so, briefly...
16:25:32 <tqtran> that sounds like a great plan
16:25:37 <amotoki> I think filtering works more compared to pagination. some projects sopport listing with filtering but some not. If avialable, using filter API sounds good to me.
16:25:37 <clu_> some projects only allow the "exact" match, others allow you to filter on "subset"
16:26:03 <david-ly_> I think Horizon needs to pull all data available to the user for a particular view, dynamically
16:26:08 <david-ly_> building the list
16:26:30 <amotoki> david-ly_: without filtering?
16:26:33 <tqtran> is it possible for horizon to have its own DB? or are we restrictly sticking to the cache only
16:27:07 <david-ly_> from there all filtering is string based, js that we have now, but instead of just querying the onscreen, it queries off screen data as well
16:27:52 <clu_> sounds powerful :)
16:27:53 <ericpeterson> that seems like some changes would be needed, to get additional data from following pages
16:27:58 <rbertram> david-ly_: will you keep the cache fresh via events? polling? Or let it grow stale?
16:28:09 <david-ly_> I think it's best to just write the proposal in BP form and have the discussion go there
16:28:16 <amotoki> it makes sense to some extent. I wonder if it scale with thousands of resources...
16:28:25 <david-ly_> tqtran: db no
16:28:33 <david-ly_> we don't want to maintain that
16:29:10 <tqtran> ok
16:29:14 <lcheng> tqtran: maybe we can make the caching strategy configurable, using in-memory, file-based or database.
16:29:16 <david-ly_> amotoki: for admin type views I need to better determine some more basic filtering of the data before requesting everything
16:29:32 <amotoki> agree
16:30:16 <clu_> the new blueprint process will definitely help out with figuring out the strategy :)
16:30:19 <david-ly_> but if we continue to thinly represent the API structure, we are never going to have a consistent UX
16:30:43 <tqtran> lcheng: i like that idea, this way, if 3rd party decides to have their own filtering/caching implementation to ensure scaling they still can. and it would even allow future incubation projects
16:30:46 <david-ly_> and thus not be very effective
16:31:23 <rbertram> david-ly_: so for tables exceeding a certain length, user is asked to filter before all (any?) of it is loaded
16:31:28 <david-ly_> tqtran: lcheng: caching the topology of a large scale cloud is not really an effort I believe we want to take on
16:32:03 <david-ly_> rbertram: perhaps for users who have cross project visibility
16:32:04 <doug-fish> caching every user known to a large company's LDAP server is probably not a good idea either.
16:32:08 <amotoki> the topic is very related to openstacksdk/python client libary discussion.
16:32:09 <jpomero> i'm confused why any caching would be involved
16:32:25 <david-ly_> I'm not advocating caching
16:32:31 <david-ly_> that's a fools errand
16:32:37 <jpomero> right
16:32:41 <rbertram> david-ly_: thinking about needing to refresh the data - at least in scenarios where a change is expected, like after adding a now instance. we poll now.
16:32:42 <david-ly_> these are API requests
16:32:43 <ericpeterson> for almost every admin table, we should not be displaying all the data.  instead we should first have the admin provide some type of filter, even if it's implicit
16:32:48 <david-ly_> we're just asking for more datat
16:32:51 <david-ly_> *data
16:32:59 <david-ly_> ericpeterson: ++
16:34:11 <amotoki> ericpeterson: +1
16:34:18 <david-ly_> #action: david-lyle files BP on new horizon data-model, filtering, pagination
16:34:20 <ericpeterson> = 3  ;)
16:34:56 <lcheng> david-ly_: if we don't have any caching at all, we need to fetch ALL the data every time as the user navigates through each page in the table ?
16:35:25 <david-ly_> lcheng: depends how the page flow is structured
16:35:36 <david-ly_> but each load of the main table yes
16:35:59 <david-ly_> things like detail views shouldn't require a page load
16:36:09 <ericpeterson> also, if data requested via an ajax call, sometimes the browser can cache that and don't even bother the server
16:36:30 <david-ly_> we'd persist the page data as long as we could
16:36:35 <tqtran> yes, but that single api call to fetch it all will cause a significant delay
16:36:56 <david-ly_> tqtran: there's typically an API result limit
16:37:05 <david-ly_> so we really need to paginate anyway
16:37:05 <lcheng> david-ly_: the level of caching I am thinking is just within the scope of the page or request.  But I think those are details can be figured out later as we hash out the design in the bp.
16:37:18 <david-ly_> lcheng: sure
16:37:31 <david-ly_> as long as we're not talking a session level cache
16:37:40 <david-ly_> I think we're talking in the same direction
16:37:58 <jpomero> my experience has been that requesting lots of data is fairly quick, rendering is the bottleneck
16:38:23 <david-ly_> I'm going to move on for now, we'll discuss more when we have something more concrete
16:39:00 <david-ly_> #topic Clientside tables (ericpeterson, tqtran)
16:39:21 <ericpeterson> so.... a bit of background / update
16:39:44 <ericpeterson> tqtran and I are on something like patch 54, in what is turning out to be a difficult patch
16:40:21 <ericpeterson> what we are going to change to.... is to make 1 patch with some core horizon/* type fixes..... this will make it so you can have a ajax supported table
16:40:50 <ericpeterson> https://review.openstack.org/#/c/94706/   (is the change I speak of)
16:41:14 <ericpeterson> that patch, as it has been sitting, changed the instances table to be ajax/angular
16:41:28 <ericpeterson> we are going to move to smaller changes
16:41:46 <ericpeterson> I just didn't know how other people would view that
16:42:03 <ericpeterson> (big patches are a pain to review, and to rebase)
16:42:55 <ericpeterson> and if we get to patch #100.... do we win a prize?  like a free swift container???
16:43:02 <ericpeterson> ;)
16:43:03 <doug-fish> yeah, I know you guys have done a ton of work on that.  It has been difficult to keep up with reviewing it lately because its a monster.  Big and lots of things to think about.
16:43:37 <david-ly_> ericpeterson: I certainly think breaking up the patch makes it more manageable, my greater concern is if this patch goes far enough
16:43:39 <doug-fish> breaking it up seems right to me
16:43:59 <david-ly_> re: our previous discussion
16:44:12 <david-ly_> it could be a decent interim step
16:44:39 <david-ly_> as I think the changes proposed above are a release cycle length change
16:44:44 <david-ly_> at least
16:45:08 <ericpeterson> yep.... so tqtran and I will break this one into at least two changes, if not 3
16:45:16 <amotoki> I wonder how we can have good test coverage on a large JS patch.
16:45:41 <tqtran> i will be including jasmine tests
16:45:43 <pawelss> How many LOC is it?
16:45:45 <ericpeterson> one will be common horiozn/* stuff..... one might be common openstack_dashboard/*  stuff.... then like the instances page can depend upon these other two
16:45:59 <tqtran> right now, its already pretty big, once we split it, will be a bit more manageable
16:46:01 <ericpeterson> +1003, -77
16:46:31 <ericpeterson> the other part is we fundamentally change the instances page, which is a big deal / risky
16:46:39 <pawelss> That's something
16:48:23 <gugl2> amotoki, I am just wondering the same...not only about the unit tests...how we can QA the big change
16:48:50 <tqtran> how are we doing that today?
16:48:52 <david-ly_> so jumping ahead a bit, in the new bp template I've added a "Motivation" section, what's the problem is we're attempting to solve is.  My question to you is what would be in that section for this patch?  I have ideas, but would like to hear yours
16:49:04 <david-ly_> *what
16:49:46 <tqtran> a few reasons: first, the move to angular is more scalable and would in the long run result in better performance
16:50:39 <tqtran> second, because we rely more on client and ajax requests, our web app will a lot more responsive
16:50:43 <ericpeterson> also, having more data in the client can support a faster, richer experience.... right now the client only gets the columns being displayed
16:51:10 <tqtran> right now, any action we take triggers a full page refresh, which is not really responsive, it feels clunky
16:51:30 <ericpeterson> if you ship more of the row's data.... you can do stuff like hover over the row/cell and display a great deal of detailed info
16:52:11 <tqtran> and third, it would also allow more client centric developers to contribute (w/o knowing too much python)
16:52:35 <david-ly_> tqtran, ericpeterson: I agree with those, I think it's essentially an enablement patch
16:52:36 <ericpeterson> yep, js customization could be done with 0 knowledge of python, good point
16:53:08 <david-ly_> I think part of the hurdle to reviews may also be that none of that is in the BP
16:53:41 <ericpeterson> ack, good point on the bp lacking supporting materials
16:54:22 <david-ly_> regardless, I think breaking up the review into logical pieces makes sense and will help drive greater feedback
16:54:35 <ericpeterson> thanks all, we'll work in this direction :D
16:55:02 <tqtran> =)
16:55:10 <david-ly_> #topic Continued discussion of potential changes to the blueprint process (david-lyle)
16:55:27 <david-ly_> #link https://blueprints.launchpad.net/horizon/+spec/template
16:55:44 <david-ly_> is my pass at a template for new blueprints
16:56:47 <david-ly_> is there any feedback on omissions or commissions?
16:56:52 <doug-fish> how do you want us to share comments?  (because I see we will be running out of time)
16:57:20 <david-ly_> doug-fish: let's just put them in the whiteboard of the template for now
16:57:30 <doug-fish> sounds good!
16:57:40 <david-ly_> once finalized, we can either clean those up, or leave them as a record
16:58:07 <david-ly_> please take some time to provide feedback so we can start making proposals to Kilo
16:58:22 <pawels> I am testing it now while writing new bp :)
16:58:30 <david-ly_> And I'll draft a wiki page as to the intended flow
16:59:00 <lcheng> david-ly_: Does "motivation" covers describing the actors/users of the panel/bp?
16:59:01 <david-ly_> #action david-lyle draft a wiki page as to the intended bp flow
16:59:01 <rbertram> pawels: +1 I think seeing some real bps using the template is important
16:59:40 <david-ly_> lcheng: I meant it more as to why should we do this, or what are we trying to solve
16:59:49 <absubram_> david-ly_ : Off topic sorry - I know this is a low priority vendor specific bug : https://bugs.launchpad.net/horizon/+bug/1260435 You just pushed it out of RC1.. but it had 2 core approvers y'day.. until it got yanked because of the gate issue.. can we please still get this into RC1, if the cores give back the +2s? :p
17:00:02 <david-ly_> I think actors/users should go in UX
17:00:09 <david-ly_> I'll update the comments
17:00:17 <lcheng> david-ly_: sounds good
17:00:25 <amotoki> absubram_: as david-ly_ said, RC1 bug list is to check what are release-critical bugs.
17:00:27 <tqtran> david-ly: i like the template, its a lot more informative than it is now lol
17:00:44 <david-ly_> absubram_: bug fixes can continue land until RC1 even if not in the list
17:00:50 <absubram_> amotoki: oh ok! thanks.. got it
17:00:55 <david-ly_> but I won't block RC1 on items not in the list
17:01:00 <david-ly_> and time
17:01:02 <absubram_> david-ly_: ty
17:01:09 <david-ly_> Thanks everyone, have a great week!
17:01:15 <david-ly_> #endmeeting