15:00:16 <e0ne> #startmeeting horizon
15:00:17 <openstack> Meeting started Wed Apr 10 15:00:16 2019 UTC and is due to finish in 60 minutes.  The chair is e0ne. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:20 <openstack> The meeting name has been set to 'horizon'
15:01:03 <dklyle> o/
15:01:07 <rdopiera> o/
15:01:11 <vishalmanchanda> hi all
15:02:08 <e0ne> lets's start with some notices. maybe Akihiro will join us
15:02:15 <e0ne> amotoki: ^^
15:02:32 <e0ne> #topic Notices
15:02:52 <e0ne> OpenStack Stein is released today!
15:02:55 <e0ne> #link https://review.openstack.org/#/c/650362/
15:03:18 <dklyle> \o/
15:03:22 <e0ne> congratulations to everyone and thanks for your contributions!
15:03:55 <amotoki> hi
15:04:27 <e0ne> also I've just added vishalmanchanda to the horizon-core team in gerrit!
15:04:41 <dklyle> welcome vishalmanchanda
15:04:48 <e0ne> vishalmanchanda: I hope to see more your reviews now :)
15:05:04 <vishalmanchanda> dklyle: e0ne : Thanks...
15:05:20 <vishalmanchanda> e0ne: yeah sure.
15:05:24 <e0ne> :)
15:05:24 <amotoki> vishalmanchanda: welcome
15:05:36 <vishalmanchanda> amotoki: thanks :)
15:06:05 <e0ne> I'm going to check if we need to release stable/* branches too and propose new stable releases if needed later this week
15:07:37 <e0ne> I hope we'll updates our priorities etherpad  https://etherpad.openstack.org/p/horizon-release-priorities after the PTG discussions
15:07:53 <e0ne> that's all updates from me this week
15:08:01 <amotoki> it is worth releasing pike before entering EM.
15:08:19 <e0ne> amotoki: +1
15:09:09 <amotoki> there seems a lot of confusion around extended maintenance phase (EM), especially it is a decision of individiaul project or global one. I have no clear answer now.
15:10:14 <amotoki> perhaps entering EM is global and marking EOL is a project team decision.
15:10:27 <e0ne> amotoki: we'll have this topic at PTG.
15:10:43 <e0ne> amotoki: I'll ask this question to our release team
15:12:21 <e0ne> #topic PTG planning
15:12:29 <e0ne> here is our therpad:
15:12:31 <e0ne> #link https://etherpad.openstack.org/p/horizon-train-ptg
15:13:06 <e0ne> we'll have a half of day on Thursday
15:13:16 <e0ne> Team Photo: 11:30-11:40
15:13:39 <e0ne> place for team photo will be announced later
15:14:16 <e0ne> #topic Open Discussion
15:14:52 <amotoki> I would like to hear your opinions on https://review.openstack.org/#/c/649379/
15:15:06 <amotoki> I have no strong opinion on this and will remove my -1 from now.
15:16:34 * e0ne hates DST
15:17:44 <e0ne> I prefer to have a current local timezone everywhere
15:18:18 <e0ne> another option is UTC, but it's not a user-friendly way
15:18:44 <amotoki> hopefully folks with experiences on DST can comment it.
15:20:12 <rdopiera> I think that technically DST is a separate timezone
15:20:26 <e0ne> amotoki: see my comment above :)
15:20:58 <rdopiera> for example, you have CET and CEST
15:21:52 <rdopiera> and each of them has its own offset, which doesn't change
15:22:42 <e0ne> rdopiera: good point. can we show timezones name in a such way?
15:22:58 <amotoki> a timezone is determined based on a region like US/Pacific and then converted into a timezone like PST and PDT.
15:23:29 <amotoki> I think what users image is a region like US/Pacific rather than PST/PDT.
15:24:42 <amotoki> e0ne: rdopiera: do you say it is better to show both timezones (standard and daylight saving timezones)?
15:25:00 <amotoki> I haven't got your point.
15:25:30 <rdopiera> amotoki: if we let users pick a region, and not a timezone, then it would be probably good to show them all timezones in that region
15:26:07 <rdopiera> otoh, I think that showing only one timezone is a kind of standard
15:26:14 <rdopiera> wait, there is an ISO standard for this
15:27:21 <amotoki> do you mean ISO 3166 and pytz https://pypi.org/project/pytz/ ?
15:27:54 <amotoki> ISO 3166 is about country code, so it might be different.
15:28:53 <e0ne> https://en.wikipedia.org/wiki/ISO_8601 - it proposes to use UTC offsets
15:31:02 <amotoki> yeah, it is what we use now
15:31:23 <amotoki> the question now is which is better standard time or daylight saving time.
15:32:15 <rdopiera> looks like iso wants to use offsets so it's unambiguous
15:32:31 <e0ne> IMO, I prefer DST because it makes a correct time selection easier
15:33:05 <rdopiera> can we check what is the de facto usage on popular websites?
15:33:21 <rdopiera> or, in, say, timezone selection box in Gnome?
15:33:29 <amotoki> rdopiera: good idea
15:34:46 <e0ne> google calendar: (GMT+03:00) Eastern European Time - Kiev
15:35:13 <e0ne> but it doesn't count for DST :(
15:38:17 <amotoki> I am intending to have a conclusion here. Let's add comments on the review https://review.openstack.org/#/c/649379/
15:39:13 <e0ne> amotoki: +1
15:41:45 <e0ne> I would like to briefly discuss https://bugs.launchpad.net/horizon/+bug/1793488
15:41:46 <openstack> Launchpad bug 1793488 in OpenStack Dashboard (Horizon) "Horizon logs a user out when created keypair is over quota" [Medium,In progress] - Assigned to CosteijnK (costeijn-kuhlmann)
15:42:12 <e0ne> the same bug could be valid for other resources
15:42:27 <e0ne> we redirect to the login page on 403
15:42:52 <e0ne> but API guidelines recommends to use 404 code if quota exceeded
15:43:09 <rdopiera> so not our bug?
15:43:23 <e0ne> rdopiera: actually, it's horizon bug
15:43:32 <amotoki> as the current situation, different projects return different error code for over quota.
15:43:38 <e0ne> "403 Quota exceeded" is a recommended response
15:43:51 <rdopiera> that makes things tricky
15:44:02 <amotoki> keystone returns 403, nova returns 413? and neutron returns ???
15:44:16 <amotoki> 404 is not the right value (as it means NotFound)
15:44:36 <e0ne> we need to re-think our logic to process 403 errors
15:45:15 <rdopiera> I think we discussed that once already
15:45:46 <amotoki> 403 is Forbidden. it sounds too much to kick a user out.
15:45:56 <e0ne> rdopiera: do you remember our conclusion?
15:45:58 <rdopiera> I think we decided to display a page with an error, and a link to the login page, instead of redirecting to the login page
15:46:23 <rdopiera> because that will still display the menu, and users can just go back
15:46:38 <rdopiera> no menu on the login screen
15:46:42 <rdopiera> so users feel lost
15:46:44 <e0ne> rdopiera: I remember it
15:46:45 <amotoki> sounds reasonable
15:47:15 <rdopiera> but I may remember wrong
15:47:25 <rdopiera> (that was the option I advocated for)
15:48:07 <e0ne> but it was a different
15:48:10 <e0ne> but it was a different case
15:48:36 <rdopiera> but I think it would work in this case, as long as we display the error message
15:48:39 <e0ne> that solution was implemented if user has no permissions for some panel
15:48:46 <amotoki> IMO it sounds more reasonable to show an error message which suggests to switch users when 403 is returned rather than kicking out the user.
15:48:54 <e0ne> https://github.com/openstack/api-sig/blob/ff8fbbf3a9c2b8f6f96b6df0ddeb3865b8177274/guidelines/http/response-codes.rst#failure-code-clarifications
15:48:57 <e0ne> #link https://github.com/openstack/api-sig/blob/ff8fbbf3a9c2b8f6f96b6df0ddeb3865b8177274/guidelines/http/response-codes.rst#failure-code-clarifications
15:49:07 <e0ne> If the request results in the OpenStack user exceeding his or her quota, the return code should be 403 Forbidden.
15:49:43 <e0ne> I prefer to not show login screen or link to login if quota exceeded
15:49:49 <e0ne> it's really bad UX
15:50:18 <amotoki> +1
15:51:19 <e0ne> that's why I propose to review our logic for 403 errors
15:51:57 <e0ne> it's something we need to thinks, because the fix is not trivial
15:54:53 <rdopiera> is there a way we can know it's quota and not something else?
15:55:18 <e0ne> rdopiera: AFAIR, the only way to do it is to check error message:(
15:56:12 <e0ne> at least, python-novaclient doesn't raise any specific exception for keypair quotas
15:59:10 <amotoki> in case of neutronclient, OverQuota exception is returned
15:59:21 <e0ne> amotoki: it's good:)
15:59:30 <amotoki> as the response message contains the root cause like {"NeutronError": {"message": "Quota exceeded for resources: ['router'].", "type": "OverQuota", "detail": ""}}
15:59:32 <e0ne> we're reaching time limit
15:59:43 <amotoki> but 409 is returned....
15:59:52 <e0ne> we can continue our discussion in #openstack-horrizon channel
16:00:02 <amotoki> o/
16:00:02 <e0ne> thanks everybody for the participation
16:00:05 <amotoki> good night
16:00:10 <e0ne> #endmeeting