20:00:08 <robcresswell> #startmeeting horizon
20:00:09 <openstack> Meeting started Wed Jun 14 20:00:08 2017 UTC and is due to finish in 60 minutes.  The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:13 <openstack> The meeting name has been set to 'horizon'
20:00:17 <david-lyle> o/
20:00:19 <ying_zuo> o/
20:00:20 <ducttape_> o/
20:00:34 <e0ne> hi
20:00:52 <robcresswell> Hi everyone
20:01:07 <choyj> o/
20:01:36 <robcresswell> We've an empty agenda again :)
20:02:06 <e0ne> so I've got a chance to ask a question today:)
20:02:31 <robcresswell> I don't have any notices either, other than Pike-2 was tagged and released last week. There's also been a few more stable backports, so I'll tag new stables too.
20:02:40 <robcresswell> #topic Open Discussion
20:02:58 <robcresswell> If you have any questions, blueprints, bugs, patches, feel free to ask
20:03:00 <e0ne> I'll appreciate any feedback on my thread in openstack-dev: Poorly Pagination UX
20:03:04 <e0ne> #link  http://lists.openstack.org/pipermail/openstack-dev/2017-June/118352.html
20:03:40 <rdopiera> o/
20:03:58 <robcresswell> e0ne: I disagree with the assessment that they "can't be fixed"
20:04:09 <david-lyle> e0ne, I think the long and the short is without something like searchlight it won't get better
20:04:10 <rdopiera> I have a question about the federation and regions
20:04:27 <rdopiera> How stable is that feature, actually? Has anybody been using it?
20:04:36 <e0ne> robcresswell: it's good
20:04:46 <robcresswell> Its just not a trivial solution, because the delete is done via client side and ajax iirc, while the page (with back/next) is generated by the server
20:04:50 <robcresswell> So they get out of sync
20:05:25 <ducttape_> until the apis have robust paging support, horizon will continue to be in trouble.  searchlight could have fixed that
20:05:25 <e0ne> robcresswell: if I understand correct, deletion causes full page  reload
20:05:47 <robcresswell> e0ne: Oh, does it? I can't remember off the top of my head
20:05:53 <david-lyle> rdopiera, federation and regions?
20:05:55 <ducttape_> rdopiera: federation and regions???  more details please
20:06:08 <robcresswell> Hang on, lets talk pagination first.
20:06:10 <david-lyle> get out of my head ducttape_
20:06:15 <robcresswell> Too much crosstalk.
20:06:27 <rdopiera> So Horizn has this AVAILABLE_REGIONS feature, where you can have several Keystone addresses defined
20:06:30 <david-lyle> pagination, you're stuck
20:06:36 <david-lyle> end of story
20:06:37 <rdopiera> and then you can switch between them in the UI
20:06:38 <e0ne> robcresswell: I don't have working env now, but it did GET and re-load all js files after delete call on my fresh devstack today
20:06:53 <e0ne> david-lyle: :)
20:06:53 <ducttape_> yeah, not much to do to really fix paging.   says the inside of david-lyle's head
20:07:09 <robcresswell> e0ne: Basically; those bugs can be fixed. I've done it locally with angular. The logic isn't terribly nice, and its a big change from what we have now.
20:07:23 <robcresswell> It also has to be done on a per-API basis because they all do things differently
20:07:29 <rdopiera> and then it has web sso, which lets you share the logins between those multiple keystones
20:07:45 <e0ne> robcresswell: could  you please submit that code to the gerrit?
20:07:53 <robcresswell> You *also* have to do a lot of the tracking yourself as the next/prev links aren't reliable from the API (they often show up even if "next" is empty, for example)
20:08:08 <robcresswell> e0ne: It wasn't part of Horizon, totally separate investigation.
20:08:31 <ducttape_> rdopiera  It's been a couple of years, but that multi region / login thing was kind of working for a deployment we had
20:09:17 <e0ne> robcresswell: TBH, I don't know how to fix everything with current APIs without additional API calls
20:09:25 <ducttape_> I would not be shocked if the multi region login thing is partially broken right now, as I'm not sure if anyone is still using it
20:09:27 <david-lyle> rdopiera, if you're wanting federated keystone between those regions that went in two cycles ago, should work
20:09:45 <david-lyle> if you're wanting separate logins, that should work still too
20:09:56 <david-lyle> but the UX is different
20:10:23 <rdopiera> david-lyle: I think they want common logins
20:10:46 <ducttape_> so why not just have multi region and single login rdopiera???
20:11:04 <david-lyle> I suppose you could set multiple REGIONS and use federation
20:11:17 <rdopiera> ducttape_: I have no idea, I didn't even KNOW about this feature until they came to me asking how stable it is :)
20:11:26 <rdopiera> so I promised to ask upstream
20:11:26 <robcresswell> e0ne: This is what I mean; its not an easy solution :)
20:11:28 <rdopiera> and here I am
20:11:55 <david-lyle> but the intended usage was provide a keystone REGION then your service catalog will contain the endpoints for the other federated keystones
20:11:58 <ducttape_> here we all are.  indeed. ;)
20:12:12 <david-lyle> when you login, then you will get a drop down of other keystones to switch to
20:12:19 <e0ne> robcresswell: I'm glad to help with it if you share your ideas
20:12:37 <e0ne> robcresswell: here is a case what I can't resolve for now: http://paste.openstack.org/show/612591/
20:13:19 <lucasxu> rdopiera: I was using the keystone federation plugin
20:13:22 <lucasxu> it works well
20:13:48 <robcresswell> e0ne: The only sensible way to do that is probably to drop on to the first page after a refresh :/
20:13:52 <rdopiera> thanks you all for the feedback
20:13:57 <rdopiera> thank you*
20:14:08 <david-lyle> rdopiera, I think you're mixing two ways of using multiple keystones which is confusing things
20:14:13 <e0ne> robcresswell: it's a bad idea from UX perspective if you've got a lot of pages :(
20:14:31 <rdopiera> david-lyle: it's possible I simply didn't understand what they are doing
20:14:37 <robcresswell> e0ne: You shouldnt be trying to manipulating large amounts of data by paging through it. Use filtering.
20:14:41 <rdopiera> david-lyle: I will try to clarify
20:14:50 <rdopiera> david-lyle: thanks for the hints
20:15:00 <robcresswell> Or up the page size. But going to page 10 to get something done is not productive.
20:15:07 <david-lyle> robcresswell, e0ne I think storing the previous page marker in the session is what you would want
20:15:44 <david-lyle> you can store previous markers and page back
20:15:49 <david-lyle> if back is all you want
20:16:00 <david-lyle> but it's baggage to carry around
20:16:59 <robcresswell> Yeah, the only option would be to load the page, check its [], then load the page before
20:17:11 <e0ne> or the next page
20:17:32 <e0ne> but in corner case, we still will get [] :(
20:17:37 <david-lyle> you should get an API error if you ask for a missing marker, no?
20:17:54 <e0ne> david-lyle: that's what is supposed to be
20:18:08 <robcresswell> david-lyle: No, most APIs will return a Next link for an empty page.
20:18:15 <robcresswell> Cinder definitely does this.
20:18:19 <robcresswell> I think I have bug open for it
20:18:30 <david-lyle> an empty result with a next link?
20:18:34 <david-lyle> *result set
20:18:57 <david-lyle> how does it know what next is?
20:19:05 <david-lyle> if you're asking for a missing ID?
20:19:10 <robcresswell> So if I'm looking at page of items 5 - 10, with marker 4 (the last item in the previous page)
20:19:11 <e0ne> it depends on your pagination order: we need prev or next link
20:19:20 <robcresswell> And I deleted 5 - 10
20:19:46 <rdopiera> hmm, there are prev and next links already
20:19:54 <rdopiera> you have to genereate them for the page
20:19:55 <robcresswell> and I request 1 - 4, for example, I'll get a "next" link even though there is nothing there
20:20:11 <ducttape_> if you are going to have partially supported pagination apis underneath the UI, this seems pretty futile to have a consistent pagination experience
20:20:14 <rdopiera> so we don't need to store the last marker
20:20:14 <robcresswell> Because the "next" link is always the last item on your current page, not the first item on the next one.
20:20:21 <david-lyle> yeah, I gave up on pagination 4+ years ago in OpenStack
20:20:47 <david-lyle> have washed away most of the painful memories
20:20:51 <robcresswell> rdopiera: Right, this is what Im saying; those links aren't reliable, because they will still generate them even if the next page is empty.
20:20:56 <robcresswell> Also most APIs dont do Prev
20:21:07 <rdopiera> bummer
20:21:14 <david-lyle> the real answer is filtering to reduce the result set and store all the results on the client and handle pagination there
20:21:26 <david-lyle> for the handful of pages
20:21:42 <david-lyle> that was part of the Paris accord IIRC
20:21:56 <david-lyle> not the famous Paris accord of course
20:22:03 <david-lyle> but the summit
20:22:12 <rdopiera> what is the sense of pagination then, if you have the whole list anyways
20:22:16 <rdopiera> just display it all
20:22:22 <ying_zuo> instead of showing pre and next, would it be better if we just show a link for more and just keep adding more rows to the table?
20:22:25 <rdopiera> it's a web page, it can be scrolled, you know
20:22:32 <rdopiera> doesn't have to fit on the screen
20:22:47 <david-lyle> because throwing more people into the pagination volcano hasn't quieted the pagination volcano's anger yet
20:22:48 <rdopiera> ying_zuo: that's an idea
20:22:49 <ying_zuo> that will solve the problem for apis don't have pre
20:22:57 <ducttape_> maybe we can just post all the cloud resources to twitter.  they do scrolling pretty well
20:23:00 <rdopiera> ying_zuo: and it's popular these days
20:23:05 <e0ne> hm... we can't always show all but links like "show more" are an option for me
20:23:16 <david-lyle> rdopiera, status checks can kill performance
20:23:28 <rdopiera> and that would also encourage filtering
20:23:30 <david-lyle> there were reasons, they may no longer be valid
20:23:38 <rdopiera> david-lyle: I see
20:24:14 <david-lyle> we didn't limit the thread pool for polling previously
20:24:22 <robcresswell> Show more works, but that has its own issues. Like how much data you hold in the client, and what your JS is doing
20:24:32 <ducttape_> it was 10 requests for polling I thought
20:24:34 <david-lyle> that has been fixed, so showing all may not make things fall over any more
20:24:48 <david-lyle> that's why filtering
20:24:59 <david-lyle> 1000 pages isn't really useful, ever
20:25:42 <ying_zuo> probably the biggest problem for show more is the update
20:25:46 <e0ne> polling for 100 items statuses per page is also not a good idea from the performance PoV
20:25:57 <e0ne> ying_zuo: +1
20:25:58 <ying_zuo> update for the deleted resources
20:26:02 <david-lyle> that's why the # of threads has been limited
20:26:03 <rdopiera> robcresswell: that's where filtering comes in
20:27:08 <david-lyle> let's just agree to agree to filter
20:27:10 <david-lyle> :)
20:27:15 <e0ne> :)
20:27:42 <rdopiera> personally, when there are more results than one page, I would just display "there are XXX results, that's too much to show, enter some filtering criteria"
20:27:56 <robcresswell> rdopiera: How do you know how many results there are?
20:27:57 <david-lyle> or make searchlight ubiquitous
20:27:59 <ducttape_> the next item I'd like to talk about is the lack of a consistent search / filter feature on pages.  ;)
20:28:13 <rdopiera> robcresswell: you stop reading them as soon as you get one pagefull
20:28:29 <robcresswell> Ah, I see your point.
20:28:31 * david-lyle throws the search icon at ducttape_
20:28:52 <robcresswell> ducttape_: Its not toooo bad now. Davids minions improve it a lot.
20:30:04 <rdopiera> by the way, I wanted to ask about one more thing
20:30:20 <rdopiera> I asked Richard about https://review.openstack.org/#/c/410860/
20:30:36 <rdopiera> and he said that he can't do it, but that it really needs to be done soon
20:30:56 <rdopiera> and I'm familiar with the microversions code already...
20:31:13 <robcresswell> Oh yeah, that was the feature Cinder supported for ~1 cycle that I spent ages reviewing.
20:31:13 <david-lyle> rdopiera, you win
20:31:40 <robcresswell> rdopiera: +1
20:31:45 <robcresswell> Well volunteered :)
20:32:05 <rdopiera> however, that patch is supposed to have subsequent patches
20:32:11 <rdopiera> and that's not something I am up for
20:32:37 <e0ne> robcresswell: TBH, we removed consistency groups in Pike in flavor of generic groups
20:33:00 <robcresswell> e0ne: Yeah, that was the issue I was mentioning :)
20:34:21 <robcresswell> e0ne: We spent a fair bit of time adding support only for it to be immediately deprecated. That's not really ideal when reviewer bandwidth is low.
20:34:53 <e0ne> robcresswell: I have to agree with you :(
20:35:26 <david-lyle> on the plus side, no one must have been using it
20:35:32 * david-lyle ducks
20:36:01 <robcresswell> david-lyle: I don't think anyone's upgraded past Mitaka yet to notice
20:36:25 <rdopiera> so if we remove it quickly, we should be fine?
20:36:37 <ducttape_> no
20:36:42 <ducttape_> thats now how it works
20:36:45 <ducttape_> not*
20:36:49 <rdopiera> aww
20:37:03 <ducttape_> customers will be on Newton / whatever in another 6-9 months etc
20:37:22 <e0ne> can we have such features implemented as plugins?
20:37:25 <david-lyle> IIUC it was a proprietary extension disguised as a Cinder API feature
20:37:33 <david-lyle> but there are many of those
20:37:47 <david-lyle> so there may be a limited set of people that used it
20:38:02 <e0ne> david-lyle: +1
20:38:24 <e0ne> and now it's migrated to generic groups
20:38:51 <e0ne> so in a pike release, it would be good to have generic groups support instead of CGs
20:39:01 <ducttape_> this isn't allowed I think, but in an ideal world you'd change the docs for old releases and tell people to avoid features like this
20:39:03 <david-lyle> agreed
20:39:31 <robcresswell> Well, microversions means its around forever now
20:40:06 <david-lyle> yay, microversions
20:40:13 <david-lyle> :(
20:40:14 <e0ne> robcresswell: it's crazy world
20:40:38 <ducttape_> every time a microversion is added, a kitten feels pain.  I hope upstream is happy with this path
20:40:43 <robcresswell> e0ne: Regardless, its unlikely to get done unless somebody wants to really push for it.
20:41:52 <david-lyle> guarding CG with microversions seems straightforward and volunteered for
20:42:04 <david-lyle> the support for Groups less so
20:42:19 <david-lyle> unless that's happening somewhere already?
20:42:49 <robcresswell> Not until someone new volunteers to do it
20:42:54 <robcresswell> I've got enough to get done for now :)
20:43:03 <rdopiera> even if we do that, should there be a migration path then?
20:43:19 <rdopiera> from cg to gg
20:43:33 <david-lyle> rdopiera, I would have to think that falls in Cinder's boat
20:43:34 <rdopiera> I guess that's cinder's problem
20:43:38 <rdopiera> right
20:43:45 <robcresswell> yeah
20:44:06 <rdopiera> see, could have been worse ;)
20:44:19 <e0ne> cinder did migration from CGs to generic groups
20:44:36 <david-lyle> there problem solved
20:44:39 <e0ne> :)
20:45:22 <rdopiera> the problem is, by the time the users realise they need gg support, it will be too late to add it in Pike
20:45:44 <e0ne> :(
20:47:05 <e0ne> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106720.html
20:48:06 <rdopiera> by Pike-1, haha
20:48:12 <rdopiera> when was that
20:48:28 * rdopiera cries a little
20:49:05 <rdopiera> e0ne: is the api very different?
20:49:39 <e0ne> rdopiera: I have to check a code to answer
20:49:52 <e0ne> rdopiera: I didn't use CGs at all
20:50:05 * rdopiera reads https://docs.openstack.org/admin-guide/blockstorage-groups.html
20:51:26 <e0ne> generic groups work for all backends, so everybody can  use it
20:52:36 <rdopiera> looks similar to https://specs.openstack.org/openstack/cinder-specs/specs/kilo/consistency-groups-kilo-update.html
20:52:41 <rdopiera> functionality-wise
20:55:06 <david-lyle> thanks everyone, I have to run, #endmeeting robcresswell
20:55:22 <robcresswell> Yeah I was just reading
20:55:29 <rdopiera> I will ask our pm about this, maybe I will get a go ahead for it
20:55:32 <david-lyle> ah, thought you went for a pint
20:55:47 <robcresswell> nah, just didn't have much to add
20:56:12 <robcresswell> rdopiera: I can review it if you get the time to work on it
20:56:18 <e0ne> thanks!
20:56:19 <robcresswell> ..reluctantly.
20:56:44 <rdopiera> reluctant reviews are the best ;)
20:56:50 <e0ne> robcresswell: I'll send a notes about paging to openstack-dev tomorrow as a follow-up of discussion
20:57:21 <robcresswell> e0ne: The page numbers part will never get done, but the rest should be viable. The APIs should provide prev links, IMO, but many dont.
20:58:04 <robcresswell> Anyway, we've 2 minutes left
20:58:06 <robcresswell> any final remarks?
20:58:09 <e0ne> robcresswell: page numbers is not a bug. I more care about current bugs than features
20:58:45 <robcresswell> Sure
20:59:18 <robcresswell> Okay well, thanks for your time everyone :)
20:59:24 <rdopiera> bye
20:59:49 <robcresswell> #endmeeting