15:00:59 <amotoki> #startmeeting horizon
15:01:02 <openstack> Meeting started Wed Feb 19 15:00:59 2020 UTC and is due to finish in 60 minutes.  The chair is amotoki. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:06 <openstack> The meeting name has been set to 'horizon'
15:01:09 <amotoki> hi all
15:01:47 <vishalmanchanda> hi
15:02:25 <e0ne> hi
15:04:42 <amotoki> okay, let's start
15:04:50 <amotoki> #topic notices/annoucements
15:05:14 <amotoki> first one is:
15:05:40 <rdopiera> o/
15:05:56 <amotoki> I would like to ask you whether we need a PTG space in Vancouver in June
15:06:31 <amotoki> OSF sent a mail to ask your project will gather at vancouver.
15:06:53 <amotoki> and I need to feedback by Mar 2.
15:07:56 <amotoki> do you expect to be there?
15:08:41 <amotoki> I know It is not easy to say yes/no with confidence. it is same to me too.
15:09:11 <rdopiera> I did apply, but it will be a while before I know, and I don't put much hope in it.
15:09:56 <rdopiera> Especially since all the Americans who didn't go to Shanghai will go now.
15:10:35 <amotoki> yeah, it may lead to a budget topic
15:11:50 <amotoki> the third option is to asnwer we are still considering it. we are a small team and will need a half day at most, so this might be an option.
15:12:11 <amotoki> e0ne: vishalmanchanda: what about you?
15:13:44 <vishalmanchanda> amotoki: I am not sure. It's depend on my company.
15:14:25 <vishalmanchanda> Although I wanted to join and meet you all guys again:)
15:14:38 <amotoki> vishalmanchanda: hehe :)
15:15:19 <amotoki> okay, let me share info if you have an update.
15:15:43 <amotoki> I plan to answer to OSF just before the deadline.
15:16:11 <amotoki> second one is Rocky will enter into EM phase this week or next week.
15:16:48 <amotoki> EM (extended maintenance) means we no longer cut a release while we accept backports.
15:18:08 <amotoki> after the last rocky stable release, what we merged is only "Ensure python versions" https://opendev.org/openstack/horizon/commit/5b8f7548c54187e8c5cf4c1a5d22db13d44c24dc
15:18:23 <amotoki> so I don't think we need another release.
15:19:17 <vishalmanchanda> +1.
15:20:47 <amotoki> moving on
15:20:52 <amotoki> #topic General Priorities
15:21:53 <amotoki> looking at IRC logs just before the meeting, it looks like we have topic on the error message refactoring.
15:22:03 <amotoki> can we start with this?
15:22:40 <amotoki> ^ vishalmanchanda and rdopiera
15:23:46 <vishalmanchanda> yeah rdopiera  left some comment on my patch https://review.opendev.org/#/c/708069/1
15:24:22 <vishalmanchanda> How can we use handle () method for error messages refactoring.
15:24:48 <rdopiera> the problem is how to pass the details information using the exsting django mechanisms
15:25:35 <rdopiera> and I can't really see a solution other then just appending it to the message itself, separated with some special character or string we pick, and then split it again before displaying
15:27:19 <rdopiera> it's a bit of a hack, but relatively robust, as we are still just passing text around, and even if that gets displayed or logged somewhere, it will still be understandable (even if a bit verbose)
15:27:38 <amotoki> yeah, it is same as my understanding. I looked into the detail of django messaging framework before the meeting and had the similar feeling
15:28:14 <rdopiera> we *could* use extra_tags, as we don't use them anywhere, but that would bring problems if anything else uses it
15:28:26 <rdopiera> and that's not what they are for
15:29:42 <vishalmanchanda> but as far i checked we are not using extra_tag anywhere.
15:30:26 <amotoki> isn't "extra_tags" converted into CSS classes by default?
15:30:48 <amotoki> I am looking at {{ message.tags }} in https://docs.djangoproject.com/en/3.0/ref/contrib/messages/#displaying-messages
15:30:55 <rdopiera> that's what the example template in django documentation does, but of course our templates could do soemthing else
15:31:28 <rdopiera> it's not what they are for, though, so I would prefer to merge/split the message instead
15:31:49 <e0ne> amotoki: I didn't get approval from PTG trip yet :(
15:32:26 <amotoki> e0ne: thanks for the info. nobody has got approval yet :)
15:33:26 <amotoki> rdopiera: some special delimiter string looks straight-forward. perhaps we need some extra JS to modify an error msg in a browser side.
15:35:29 <amotoki> it would be nice if extra_tags works, but I am not sure how much we need to modify our template.
15:36:56 <e0ne> didn't get full context of conversation yet, but maybe this https://docs.djangoproject.com/en/3.0/ref/templates/api/#django-contrib-messages-context-processors-messages will be useful. we can create own context_processors for templates
15:37:54 <e0ne> or this one https://docs.djangoproject.com/en/3.0/ref/contrib/messages/#creating-custom-message-levels
15:38:47 <rdopiera> appending it to the text of the message has the benefit of being picked up by any logging middleware
15:39:03 <rdopiera> including our operation log middleware
15:42:08 <amotoki> regarding the second one from e0ne, if I understand correctly, it allows us to define a new level of message. If we pass details as separate message from the main ones, defining a new custom level will work.
15:42:53 <amotoki> if we go to the route to include summary and detail in a single msg popup, I am afraid it doesn't work.
15:43:09 <e0ne> amotoki: +1
15:43:12 <amotoki> the django message framework just allows us to pass strings.
15:44:43 <amotoki> what is/are our next step(s) we try?
15:45:44 <amotoki> in the coversation in #-horizon, rdopiera has an idea to use the unicode "…" charcter for the separator.
15:45:48 <rdopiera> I would suggest: 1. make two functions, one for adding and second for extractin the details, use the first one in the handle() method and add the second one everywhere we use get_message (we will need a javascript version)
15:45:57 <amotoki> rdopiera: go ahead
15:46:40 <rdopiera> 2. modify all relevant places that display the messages to separate the details and display them as collapsible
15:47:43 <rdopiera> we might want to escape any existing instances of that separator character, and un-escape them when extracting details, so that it's robust
15:48:18 <amotoki> sounds reasonable to me
15:52:42 <amotoki> e0ne: i have one question on your revert patch on LOCALE_PATHS. is there anything which has changed since then?
15:53:59 <e0ne> amotoki: I didn't dig deep enough. just tested original bug I faced with the lates master without that patch
15:54:49 <rdopiera> the problem with the paths has been fixed on the django side
15:55:08 <amotoki> in Django 2.2?
15:55:25 <rdopiera> the original problem was a mix of several problems, including a bug in django where the gettext functions didn't get the paths properly
15:55:41 <rdopiera> that has been fixed, I don't remember in which version exactly
15:56:20 <amotoki> IIRC it happened in Django 1.11 and/or 2.0 for zh_tw/ch fallback case.
15:58:22 <amotoki> anyway it is a good news as setting LOCALES_PATH is a tricky workaround as it only works for horizon
15:58:38 <e0ne> +1
15:59:32 <amotoki> for other priorities, I succeeded the new policies works with manual loading of python. I am reflecting it into the code now. sorry for late.
16:00:17 <amotoki> we are reaching 1 hour....
16:00:21 <amotoki> thanks for joining
16:00:40 <amotoki> let's contineu the discussion in #-horizon if any
16:00:43 <amotoki> have a great week
16:00:45 <amotoki> #endmeeting