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