20:00:35 <ying_zuo> #startmeeting horizon
20:00:36 <openstack> Meeting started Wed Oct 18 20:00:35 2017 UTC and is due to finish in 60 minutes.  The chair is ying_zuo. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:39 <openstack> The meeting name has been set to 'horizon'
20:00:45 <ying_zuo> Hi everyone o/
20:01:13 <e0ne> hi
20:01:30 <lajoskatona> Hi
20:01:32 <Kvisle> hi!
20:01:38 <gary-smith> o/
20:01:41 <lajoskatona> Hi
20:01:44 <rdopiera> o/
20:01:51 <jeremy_moffitt> o/
20:01:59 <Zergnomen> hi
20:01:59 <lajoskatona> o/
20:02:30 <ying_zuo> o/
20:02:32 <ying_zuo> #topic Notices
20:02:41 <ying_zuo> #topic Queens-1 milestone
20:02:46 <ying_zuo> #link https://launchpad.net/horizon/+milestone/queens-1
20:02:53 <ying_zuo> I will be tagging Horizon for the Queens-1 release shortly
20:02:56 <robcresswell> o/
20:03:06 <ying_zuo> We got a good list of tickets resolved and the backlog has been reduced from over 800 open tickets at the PTG to 634 right now.
20:03:18 <ying_zuo> Thank you all for your contribution towards this achievement!
20:03:19 <robcresswell> Even lower if you exclude the Incomplete bugs
20:03:28 <robcresswell> Since we have to wait 60 days for those to expire :)
20:03:33 <ying_zuo> that's right :)
20:03:46 <e0ne> good news!
20:03:50 <robcresswell> amotoki did a check after removing Incomplete and Wishlist and it was around 400, iirc
20:03:56 <robcresswell> Which is a huge improvement
20:04:00 <ying_zuo> 👏
20:04:13 <robcresswell> I'm really happy that people are helping to shrink the bug list down :)
20:04:32 <e0ne> robcresswell: +1
20:04:37 <gary-smith> +1
20:05:00 <ying_zuo> +1
20:05:09 <ying_zuo> #topic Mox to Mock migration
20:05:32 <e0ne> ying_zuo: thanks!
20:05:55 <e0ne> I just want to get some attention to my patches from the all team
20:05:59 <e0ne> #link https://review.openstack.org/509618
20:06:10 <e0ne> ^^ it's the first patch
20:06:22 <e0ne> amotoki helped me a lot with reviewing
20:06:48 <e0ne> the first two patches are in a pretty good shape (I hope)
20:06:54 <rdopiera> I promised to help, but didn't have the time, I'm sorry
20:07:12 <e0ne> so we need to decide how do we want to go forward with it
20:07:24 <e0ne> rdopiera: np
20:08:15 <e0ne> mostly, it's about code style: there are several ways how it can be done
20:08:45 <e0ne> the last patch (https://review.openstack.org/510118) should be refactored a bit, to be more clean. I'll do it this week
20:09:46 <e0ne> I'll be happy to get any feedback
20:10:12 <ying_zuo> e0ne: thanks for working on this
20:10:16 <e0ne> as discussed with robcresswell earlier, we want to get all patches to be merged together
20:10:32 <e0ne> so we won't be in a half way on implementing this
20:11:19 <ying_zuo> what still needs to be decided?
20:11:49 <e0ne> ying_zuo: codestyle, I guess
20:12:10 <e0ne> e.g. use @mock.patch or 'with mock.patch()' statement
20:12:23 <e0ne> I mean what to use in general
20:12:42 <ying_zuo> I think they are both okay
20:12:51 <e0ne> I don't  think that we should allow only one
20:12:59 <e0ne> ying_zuo: +1
20:13:47 <e0ne> I think, that's all from my side. I'll be waiting for reviews to go forward with this as it was discussed at PTG
20:13:59 <ying_zuo> cool. thanks
20:14:14 <ying_zuo> #topic Changes Made in https://review.openstack.org/#/c/509038/
20:14:33 <ying_zuo> some of you may have seen the discussion in irc regarding this
20:14:45 <ying_zuo> It seemed okay since the quota check is also done when the modal is opened and it would mitigate the bad performance on this panel
20:15:03 <ying_zuo> amotoki raised the concern about the inconsistency that this patch introduced since we normally check the quota for such button
20:15:31 <ying_zuo> I’d like to hear what everyone thinks of this
20:15:52 <robcresswell> I don't really like it, personally :/ 0.1 seconds is so minor.
20:16:15 <gary-smith> is it 0.1 seconds per row or per page?
20:16:16 <robcresswell> There are bigger issues with panels taking literally minutes to load
20:16:28 <david-lyle_> What quota check completes 0.1 seconds?
20:16:32 <ying_zuo> that depends on the number of instances
20:16:51 <e0ne> it would be great to have the same behavior for all such buttons, not only for instances
20:17:22 <robcresswell> It's a single nova api call afaik
20:18:04 <ying_zuo> 0.1 seconds for one instance
20:18:05 <e0ne> robcresswell: imo, we have to decrease number of calls to nova, neutron and glance APIs
20:18:20 <david-lyle_> Even a single nova api call in a deployed env will take longer than that
20:18:43 <robcresswell> ying_zuo: Isn't it just one API call overall?
20:18:58 <david-lyle_> Is 0.1 on devstack?
20:19:01 <robcresswell> Its just the Launch Instance button at the top of the instances page
20:19:16 <robcresswell> "which takes about 0.14 seconds based on our prod env (prod API with local horizon)"
20:19:20 <ying_zuo> robcresswell: oh right. just that call
20:19:20 <robcresswell> From the patch commit msg
20:19:27 <robcresswell> https://review.openstack.org/#/c/509038
20:19:44 <robcresswell> I can understand it if its doing it per-row, perhaps like in the Images table or volumes or something
20:20:16 <robcresswell> Personally I feel like this is a bit of an over-optimisation. Its kinda stripping functionality for the sake of raw speed.
20:20:38 <ying_zuo> alright. we can revert it then
20:20:56 <amotoki> joined now. we call server_list() to count the number of servers. if you say server_list() is one call, it is true.
20:21:01 <david-lyle_> 0.14 Is much less than we discussed in the horizon channel
20:21:15 <robcresswell> ¯\_(ツ)_/¯
20:21:36 <ying_zuo> yes, that sounded like a big  performance improvement
20:21:42 <david-lyle_> Can we just replace the page already :)
20:22:21 <robcresswell> amotoki: We use server_list to count instances? Don't we just use the limit value? That makes no sense
20:22:43 <robcresswell> I know in Neutron they dont do quotas properly so thats not an option
20:22:53 <amotoki> robcresswell: I think _get_tenant_compute_usages() in openstack_dashboard/usage/quotas.py is still used
20:23:02 <amotoki> but I might be missing something
20:23:05 <e0ne> did anybody so some perf testing what exactly takes a lot of time>
20:24:19 <ying_zuo> I think the owner of the patch did some performance testing
20:24:39 <robcresswell> flwang has a few patches on the go
20:24:43 <robcresswell> I agree with some, disagree with others
20:25:05 <amotoki> It totally depends on a scale of deployments, so I think it is better to introduce a setting if it really needs it
20:25:15 <e0ne> it would be great to have something like https://cl.ly/1C381K3V2U21
20:25:36 <ying_zuo> I think robcresswell suggested a setting for one of the tickets
20:25:37 <e0ne> unfortunately, I don't have more profiler results by the hand at the moment
20:26:11 <ying_zuo> filter by image name or something
20:26:16 <david-lyle_> Tenant limits call was removed
20:26:18 <robcresswell> Its just a single limits api call then checking if the current is less than the absolute
20:26:28 <david-lyle_> This is usage and limits
20:26:29 <robcresswell> unless our API layer is doing some funky stuff
20:26:29 <e0ne> amotoki: I don't thinks that introducing cofig params for different scale of deployments is good idea
20:26:38 <e0ne> s/cofig/config
20:28:01 <amotoki> robcresswell: ah, tenant_limit_usages is used.
20:28:54 <robcresswell> Yeah
20:29:02 <robcresswell> I really don't think this is an expensive issue
20:29:16 <robcresswell> The patch itself even says 0.14 seconds...
20:29:58 <david-lyle_> At 0.14 I would agree that doesn't make sense. I would verify the 0.14 wasn't a typo though
20:30:22 <robcresswell> That would be wise :)
20:30:29 <david-lyle_> I never had a nova api call in production ever go that quickly
20:30:44 <amotoki> I would like to know how long it takes as a whole and 0.14 occupies what portion of the whole.
20:31:29 <ying_zuo> the ticket said the page load is very slow but 0.14 wouldn't be noticeable...
20:31:46 <robcresswell> I'm kinda surprised you could even do a network roundtrip in 0.14s :p
20:32:30 <flwang> the problem is we have too much unnecessary 0.14s
20:32:37 <e0ne> david-lyle_: :)
20:33:00 <david-lyle_> flwang  around?
20:33:02 <ying_zuo> flwang: but that's just one call
20:33:12 <flwang> david-lyle: yep
20:33:15 <flwang> just in office
20:33:53 <flwang> ying_zuo: sorry for the interrupt, i mean we have some unnecessary api calls
20:34:03 <robcresswell> I would assume the issue is usually many small calls happening per-row, so its unnecessary api calls many times
20:34:17 <e0ne> flwang: what calls do you mean?
20:34:21 <flwang> for most of the cases as I know, user just want to see a list and don't really care about all the details on one page
20:34:26 <e0ne> robcresswell: +1
20:34:33 <flwang> robcresswell: exactly
20:34:42 <robcresswell> flwang: But this is just one API call, one time
20:34:47 <robcresswell> Not per-row, afaik
20:34:50 <e0ne> flwang: it's not True for my customers
20:35:20 <flwang> like robcresswell said above, it depends on the scale
20:35:37 <flwang> just double check, are you talking about the image list call or nova list?
20:35:54 <ying_zuo> we are talking about this patch https://review.openstack.org/#/c/509038
20:36:51 <flwang> ok, for that patch, I think even there is only 0.1s, we should remove it
20:37:02 <flwang> because there are duplicated calls when launch instnace
20:37:37 <flwang> especially when your nova list take more than 1s, at that moment, you just want to remove any unnecessary api call
20:38:11 <ying_zuo> but the launch resource button usually has quota check
20:38:18 <amotoki> this raises another inconsistency: buttons are disabled in some tables and not disabled in others.
20:38:26 <flwang> 0.14s could be a small time for some deployments, but for a serious prod env, it does matter
20:38:58 <flwang> amotoki: we should improve all of them if it's the right thing
20:39:07 <amotoki> what is the right thing?
20:39:20 <flwang> remove duplicated calls and improve the perf
20:39:20 <robcresswell> If your prod env is seriously bottlenecked by 0.14s, I think you should be documenting everything you have done so the world can marvel at its efficiency :p
20:39:41 <flwang> robcresswell: it's not fair
20:40:28 <flwang> it sounds like "my nova list api call only takes 0.5s so I don't care about the extra 0.14s"
20:40:38 <robcresswell> My personal feeling is that this introduces an inconsistency, its ripping code out of Horizon for the sake of tiny savings when there are much, much bigger issues you / we could spend our coding / reviewing / investigating time on
20:40:39 <flwang> it's true for somebod
20:41:04 <robcresswell> Its more like, my Instances page takes 2 minutes to load, lets spend time reducing it by 0.14s :/
20:41:29 <flwang> robcresswell: i think we're talking about if it should save
20:41:59 <robcresswell> I understand that your use case is clearly based around barebones data and max performance; but I dont think that should be what Horizon is.
20:42:36 <robcresswell> We definitely need performance improvements, I just think this crosses the line between performance / utility, personally. Anyway I'll stop speaking so others can :)
20:42:39 <flwang> okay, then feel free revert it and we can keep the patch in our private repo
20:43:19 <ying_zuo> flwang: I appreciate that you are trying to improve the performance, but sorry, consistency is important for the UI
20:43:25 <ying_zuo> it's my bad
20:43:48 <ying_zuo> I somehow thought that's more than one call
20:44:01 <ying_zuo> I think we would like to revert it
20:44:53 <ying_zuo> I think we will skip the bug reports review for this week
20:44:53 <flwang> ying_zuo: that's all good. most of the work I'm proposing is to get a better performance based on current status,   before the perfect angularized instance panel
20:45:02 <flwang> but we can't wait
20:45:43 <ying_zuo> alright
20:45:51 <ying_zuo> #topic Open Discussion
20:46:17 <ying_zuo> if you have any code review requests or questions, this is the perfect time to raise them
20:46:47 <lajoskatona> ying_zuo: and all cores:-) https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/neutron-trunk-ui
20:47:32 <ying_zuo> thanks lajoskatona. I was going to mention that since you have asked earlier in the channel
20:47:40 <lajoskatona> In Denver we asked for help to get review even without perfect coverage, as we need feedback to see if the direction for the trunk actions are good.
20:47:50 <lajoskatona> In Denver we asked for help to get review even without perfect coverage, as we need feedback to see if the direction for the trunk actions are good.
20:47:53 <lajoskatona> Could you please help us in that?
20:48:02 <e0ne> it will be great if somebody can test and/or review my IE-related patches: https://review.openstack.org/505617 and https://review.openstack.org/505710
20:48:20 <gary-smith> what is this IE you speak of? ;-)
20:48:39 <lajoskatona> ying_zuo: Thanks
20:48:40 <e0ne> gary-smith: I said the same to customer
20:48:50 <e0ne> but had to fix these bugs :(
20:49:52 <lajoskatona> ying_zuo: Me or Bence can collect the fishy parts (as I remember there are TODOs and NOTEs for them, but need to doublecheck) and send in mail or irc
20:50:02 <lajoskatona> ying_zuo: Me or Bence can collect the fishy parts (as I remember there are TODOs and NOTEs for them, but need to doublecheck) and send in mail or irc
20:50:35 <amotoki> lajoskatona: or you file bugs on them with tags like trunk and/or neutron
20:50:43 <ying_zuo> lajoskatona: maybe it's in the etherpad
20:50:58 <amotoki> lajoskatona: or you can add them to the blueprint page
20:51:27 <e0ne> 9 mins reminder
20:51:54 <amotoki> i have one question on ngdetail reload fix. we rejected the fix(es) proposed as it is not a good approach.
20:52:07 <amotoki> on the other hand, we haven't fixed an high priority bug. can we compromise on an approach at some point?
20:52:17 <lajoskatona> yeah some is really on the pad
20:53:01 <ying_zuo> amotoki: I think you are talking about this patch https://review.openstack.org/#/c/491346/
20:53:15 <lajoskatona> Ok, We can add them to the blueprint page
20:53:46 <amotoki> ying_zuo: actually I am not sure what is the exact patch we are now moving forward. several changes have been proposed.
20:54:28 <ying_zuo> yes. I think this is only active one though
20:54:32 <lajoskatona> amotoki: the patches in question are still open, but we were lazy to fix the missing tests without knowing that the direction is good or not (i.e.: using the stepModels in a perhaps "new" way)
20:56:09 <ying_zuo> lajoskatona: is there a problem for the current approach?
20:57:15 <ying_zuo> I mean if you have any specific question or ran into some issue
20:57:22 <lajoskatona> ying_zuo: you mean by listing the most questionable parts in the blueprint for the open trunk panel changes?
20:57:58 <ying_zuo> yes, would be great if you leave the questions on the blueprint.
20:58:07 <ying_zuo> there's a whiteboard section
20:58:15 <lajoskatona> ying_zuo: ok we do that, thanks for the help
20:58:36 <amotoki> lajoskatona: btw, as a quick look https://review.openstack.org/#/c/493070/ looks unrelated to the trunk-ui blueprint. is it related?
20:59:17 <amotoki> i wonder there is any dependency.
20:59:33 <lajoskatona> amotoki: it is, as the creat and edit button uses the transfer-table and Bence found some issues in that
20:59:58 <lajoskatona> amotoki: so to make the create and edit work that was included to the patch chain
21:00:16 <amotoki> lajoskatona: thanks for clarification
21:00:40 <ying_zuo> I am glad that we had some great discussion today
21:00:45 <ying_zuo> thanks everyone for joining
21:01:03 <lajoskatona> amotoki: thanks for the attentions
21:01:07 <ying_zuo> #endmeeting