15:00:35 <vishalmanchanda> #startmeeting horizon
15:00:35 <opendevmeet> Meeting started Wed Apr 27 15:00:35 2022 UTC and is due to finish in 60 minutes.  The chair is vishalmanchanda. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:35 <opendevmeet> The meeting name has been set to 'horizon'
15:00:49 <tobias-urdin> o/
15:01:09 <vishalmanchanda> Hello everyone
15:01:11 <tmazur> o/
15:01:45 <rdopiera> hey
15:02:25 <vishalmanchanda> ok let's start the meeting
15:02:39 <vishalmanchanda> agenda of meeting can be found here https://etherpad.opendev.org/p/horizon-release-priorities#L37
15:03:29 <vishalmanchanda> I have no announcement for this week, if anyone want to make any announcement, please go ahead.
15:04:40 <vishalmanchanda> looks like nothing to announce, moving to next topic
15:04:52 <vishalmanchanda> #topic Release priorities
15:05:40 <vishalmanchanda> I am waiting for reviews on deprecation and nodejs template patch.
15:05:52 <vishalmanchanda> https://review.opendev.org/c/openstack/horizon/+/838333
15:06:00 <vishalmanchanda> https://review.opendev.org/c/openstack/horizon/+/831929
15:07:05 <amotoki> vishalmanchanda: regarding nodejs job template patch, do we want to keep nodejs14 template along with nodejs16 template?
15:07:23 <vishalmanchanda> amotoki: no.
15:07:57 <vishalmanchanda> amotoki: I will drop it once, we add nodejs template in horizon plugins.
15:07:58 <amotoki> vishalmanchanda: I see both nodejs14 and 16 jobs defined for horizon. It leads to two extra jobs.
15:09:36 <vishalmanchanda> amotoki: yes, will remove nodejs14 job once https://review.opendev.org/c/openstack/horizon/+/831929/3/.zuul.d/nodejs-jobs.yaml#81 merged and horizon plugins use that template.
15:10:36 <amotoki> vishalmanchanda: what I mean is L.5 in https://review.opendev.org/c/openstack/horizon/+/831929/3/.zuul.d/project.yaml
15:10:51 <amotoki> vishalmanchanda: it is not related to horizon plugins.
15:11:51 <vishalmanchanda> amotoki: ok I will remove that in next P.S.
15:13:28 <vishalmanchanda> Small update on Xstatic packages, I started investigating XStatic-jQuery(3.5.1.1) issue with horizon.
15:15:32 <amotoki> vishalmanchanda: how about jquery-migrate? IIUC jquery-migrate helps us prepare the upgrade from jquery 1/2 to jquery 3.
15:16:04 <amotoki> vishalmanchanda: of course you can tackle jquery 3 directly but perhaps suggestions from jquery-migrate would be helpful.
15:17:17 <vishalmanchanda> amotoki: ok, in that case I will look at  jquery-migrate issue first then move to jquery issues.
15:17:22 <rdopiera> iirc I already upgraded jquery-migrate
15:17:52 <vishalmanchanda> rdopiera: but some warning need to fixed, if I remember correctly.
15:18:01 <rdopiera> eventually
15:18:05 <amotoki> rdopiera: yes, we published jquery-migrate a while ago, but horizon integration job started to fail, so we block the latest version
15:18:17 <vishalmanchanda> yes
15:19:14 <vishalmanchanda> ok nothing more update from my side for release priories topic.
15:19:23 <amotoki> perhaps we need to check if there is no warning from the current version of jquery-migrate.
15:19:45 <amotoki> it might cause the job failure with the latest xstatic-jquery-migrate.
15:22:39 <vishalmanchanda> current version you mean we should check with jquery-migrate= 3.4.0 ?
15:23:50 <amotoki> vishalmanchanda: I mean xstatic-jquery-migrate 1.2.1.2
15:24:18 <amotoki> vishalmanchanda: I said not jquery-migrate but "xstatic-"jquery-migrate
15:24:39 <vishalmanchanda> amotoki: ok.
15:24:59 <amotoki> vishalmanchanda: I am afraid we haven't prepared well for jquery-migrate>=3
15:27:02 <vishalmanchanda> amotoki: ok let's investigate and see.
15:27:40 <amotoki> vishalmanchanda: thanks
15:27:51 <vishalmanchanda> np.
15:28:03 <vishalmanchanda> Does want to share any other updates on release priorities topic?
15:28:28 <rdopiera> nothing from me, still stuck on that scss patch
15:28:59 <tmazur> I've started to work on angularjs update
15:29:30 <tmazur> But still stuck in the very beginning
15:29:52 <vishalmanchanda> rdopiera: tmazur ok.
15:30:00 <vishalmanchanda> moving to next topic.
15:30:19 <vishalmanchanda> #topic Bug deputy report
15:30:52 <vishalmanchanda> We have one new bug reported this week.
15:31:10 <vishalmanchanda> #link https://bugs.launchpad.net/horizon/+bug/1970619
15:31:31 <vishalmanchanda> It is related to microversion, please take a look.
15:33:56 <vishalmanchanda> I will also take a look soon and add my thoughts in the bug summary.
15:34:15 <amotoki> In my understanding, we intentionally use a specific API version to avoid breakage. New features do not come automatically (with the latest version)
15:35:23 <amotoki> On the other hand, it might be a good time to revisit this policy. For example, we can bump the lowest version periodically, but it is a different topic.
15:37:05 <vishalmanchanda> ack.
15:37:10 <rdopiera> I think any version bumping should happen explicitly and be followed by testing
15:37:38 <amotoki> rdopiera: +1
15:37:45 <rdopiera> I'm not even sure if the policy of using the latest microversion when microversion is specified is good
15:38:11 <vishalmanchanda> yeah last time I bump some microversion it leads to resize instance feature stops working.
15:39:37 <vishalmanchanda> moving to the next topic
15:39:39 <amotoki> perhaps it is better to narrow the range of possible API versions. it would help us understand what will happen
15:40:31 <amotoki> go ahead
15:41:01 <vishalmanchanda> amotoki: +1, on narrowing the rage of api version.
15:41:15 <vishalmanchanda> #topic On-Demand Agenda
15:41:48 <vishalmanchanda> https://review.opendev.org/q/topic:horizon-keystoneauth-original_ip
15:42:02 <vishalmanchanda> tobias-urdin: that's you, please go ahead.
15:42:06 <tobias-urdin> I can give some context
15:42:29 <tobias-urdin> so I'm working from a security/compliance angle
15:42:57 <tobias-urdin> we wan't to make sure every request to Keystone is identifiable on who made the request, and thankfully keystoneauth1 has support for this by just setting original_ip parameter when creating a Session object
15:43:26 <tobias-urdin> that will send the RFC 7239 "Forwarder" header (keystoneauth1 will set it) when talking to Keystone
15:43:46 <tobias-urdin> this makes it possible to log every single client IP making a request, even for proxied auth requests, like from Horizon
15:44:26 <tobias-urdin> so I have two patches up now, one is simply changing an existing place we already set original_ip to use get_client_ip so it honors secure auth headers from config, like X-Forwarded-For if that is used when Horizon is behind a load balancer
15:44:57 <tobias-urdin> the other simply updates all Session objects to pass original_ip with the IP of the client from the request (again by using get_client_ip)
15:45:19 <tobias-urdin> IIRC there are 1-2 places more that should be updates, but we are currently running those two patches in production by the request of a customer
15:45:58 <tobias-urdin> so please give feedback on what you think and I'll look through for more places to update, the second patch https://review.opendev.org/c/openstack/horizon/+/839161 has more details and example in commit msg
15:46:42 <amotoki> I have questions
15:46:54 <tobias-urdin> TLDR; Horizon should pass real client IP to original_ip parameter for keystoneauth1.Session
15:47:40 <tobias-urdin> amotoki: sure
15:47:41 <amotoki> in case of horiizon, tokens are issued by horizon. This means a request comes from a client directly from keystone log. Is it what we want?
15:48:05 <amotoki> actually horizon issues a token and a user does not.
15:49:03 <amotoki> I would like to say "After this patch it looks like a request comes from ...."
15:49:58 <amotoki> another question is whether we would like to do the similar thing for API requests to other services like nova.
15:50:20 <tobias-urdin> Token is issued by Horizon yes, in the sense that is proxies the credentials from let's say the login form, but there is no way to trace the login back to the client who performed it.
15:51:10 <tobias-urdin> except for correlationing dates and possible request IDs in log files
15:51:26 <tobias-urdin> what we are doing is reading that header:
15:51:28 <tobias-urdin> Forwarded: for=100.64.10.1;by=openstack_auth keystoneauth1/4.4.0 python-requests/2.25.1 CPython/3.6.8
15:51:49 <amotoki> tobias-urdin: I see. sounds reasonable.
15:51:54 <tobias-urdin> and logging the authentication (for compliance purposes here) request as being made by 100.64.10.1
15:52:44 <tobias-urdin> the request itself is still being seen as coming from the Horizon application itself ofcourse, this makes it possible for us to log both and is already present in keystoneauth1 which was very nice
15:54:03 <tobias-urdin> it's pretty lightweight IMO since it's essentially just another HTTP header that Horizon (through it's usage of keystoneauth1) just sends to Keystone
15:54:21 <tobias-urdin> but yeah, let me know what you think on the patches and I'll proceed from there, just wanted to bring it up :)
15:55:02 <amotoki> tobias-urdin: thanks. it is interesting
15:55:31 <vishalmanchanda> tobias-urdin: thanks for bringing it here.
15:56:02 <tobias-urdin> no worries, thanks for your time and sorry for the wall of text :)
15:56:07 <vishalmanchanda> reviewers please take a look at patches and add your thoughts.
15:57:09 <vishalmanchanda> Does anyone wants to discuss any other topic?
15:58:09 <vishalmanchanda> amotoki: in case you missed, I am waiting for your reply on patch https://review.opendev.org/c/openstack/horizon/+/830936
15:59:19 <amotoki> vishalmanchanda: thanks for reminding it. I did not notice it. thanks
15:59:39 <vishalmanchanda> If nothing more to discuss, let's end this meeting.
16:00:12 <vishalmanchanda> Thanks everyone for joining and your contributions!
16:00:14 <opendevreview> Tobias Urdin proposed openstack/horizon master: Pass client IP to keystoneauth1 session  https://review.opendev.org/c/openstack/horizon/+/839161
16:00:18 <vishalmanchanda> See you next week.
16:00:29 <vishalmanchanda> #endmeeting