| opendevreview | Merged openstack/horizon stable/train: Fix for "Resize instance" button https://review.opendev.org/c/openstack/horizon/+/838533 | 08:46 |
|---|---|---|
| opendevreview | Merged openstack/horizon stable/train: Change to a proper policy for Resume operation https://review.opendev.org/c/openstack/horizon/+/836782 | 11:23 |
| vishalmanchanda | #startmeeting horizon | 15:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'horizon' | 15:00 |
| tobias-urdin | o/ | 15:00 |
| vishalmanchanda | Hello everyone | 15:01 |
| tmazur | o/ | 15:01 |
| rdopiera | hey | 15:01 |
| vishalmanchanda | ok let's start the meeting | 15:02 |
| vishalmanchanda | agenda of meeting can be found here https://etherpad.opendev.org/p/horizon-release-priorities#L37 | 15:02 |
| vishalmanchanda | I have no announcement for this week, if anyone want to make any announcement, please go ahead. | 15:03 |
| vishalmanchanda | looks like nothing to announce, moving to next topic | 15:04 |
| vishalmanchanda | #topic Release priorities | 15:04 |
| vishalmanchanda | I am waiting for reviews on deprecation and nodejs template patch. | 15:05 |
| vishalmanchanda | https://review.opendev.org/c/openstack/horizon/+/838333 | 15:05 |
| vishalmanchanda | https://review.opendev.org/c/openstack/horizon/+/831929 | 15:06 |
| amotoki | vishalmanchanda: regarding nodejs job template patch, do we want to keep nodejs14 template along with nodejs16 template? | 15:07 |
| vishalmanchanda | amotoki: no. | 15:07 |
| vishalmanchanda | amotoki: I will drop it once, we add nodejs template in horizon plugins. | 15:07 |
| amotoki | vishalmanchanda: I see both nodejs14 and 16 jobs defined for horizon. It leads to two extra jobs. | 15:07 |
| 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:09 |
| amotoki | vishalmanchanda: what I mean is L.5 in https://review.opendev.org/c/openstack/horizon/+/831929/3/.zuul.d/project.yaml | 15:10 |
| amotoki | vishalmanchanda: it is not related to horizon plugins. | 15:10 |
| vishalmanchanda | amotoki: ok I will remove that in next P.S. | 15:11 |
| vishalmanchanda | Small update on Xstatic packages, I started investigating XStatic-jQuery(3.5.1.1) issue with horizon. | 15:13 |
| amotoki | vishalmanchanda: how about jquery-migrate? IIUC jquery-migrate helps us prepare the upgrade from jquery 1/2 to jquery 3. | 15:15 |
| amotoki | vishalmanchanda: of course you can tackle jquery 3 directly but perhaps suggestions from jquery-migrate would be helpful. | 15:16 |
| vishalmanchanda | amotoki: ok, in that case I will look at jquery-migrate issue first then move to jquery issues. | 15:17 |
| rdopiera | iirc I already upgraded jquery-migrate | 15:17 |
| vishalmanchanda | rdopiera: but some warning need to fixed, if I remember correctly. | 15:17 |
| rdopiera | eventually | 15:18 |
| 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 |
| vishalmanchanda | yes | 15:18 |
| vishalmanchanda | ok nothing more update from my side for release priories topic. | 15:19 |
| amotoki | perhaps we need to check if there is no warning from the current version of jquery-migrate. | 15:19 |
| amotoki | it might cause the job failure with the latest xstatic-jquery-migrate. | 15:19 |
| vishalmanchanda | current version you mean we should check with jquery-migrate= 3.4.0 ? | 15:22 |
| amotoki | vishalmanchanda: I mean xstatic-jquery-migrate 1.2.1.2 | 15:23 |
| amotoki | vishalmanchanda: I said not jquery-migrate but "xstatic-"jquery-migrate | 15:24 |
| vishalmanchanda | amotoki: ok. | 15:24 |
| amotoki | vishalmanchanda: I am afraid we haven't prepared well for jquery-migrate>=3 | 15:24 |
| vishalmanchanda | amotoki: ok let's investigate and see. | 15:27 |
| amotoki | vishalmanchanda: thanks | 15:27 |
| vishalmanchanda | np. | 15:27 |
| vishalmanchanda | Does want to share any other updates on release priorities topic? | 15:28 |
| rdopiera | nothing from me, still stuck on that scss patch | 15:28 |
| tmazur | I've started to work on angularjs update | 15:28 |
| tmazur | But still stuck in the very beginning | 15:29 |
| vishalmanchanda | rdopiera: tmazur ok. | 15:29 |
| vishalmanchanda | moving to next topic. | 15:30 |
| vishalmanchanda | #topic Bug deputy report | 15:30 |
| vishalmanchanda | We have one new bug reported this week. | 15:30 |
| vishalmanchanda | #link https://bugs.launchpad.net/horizon/+bug/1970619 | 15:31 |
| vishalmanchanda | It is related to microversion, please take a look. | 15:31 |
| vishalmanchanda | I will also take a look soon and add my thoughts in the bug summary. | 15:33 |
| 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:34 |
| 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:35 |
| vishalmanchanda | ack. | 15:37 |
| rdopiera | I think any version bumping should happen explicitly and be followed by testing | 15:37 |
| amotoki | rdopiera: +1 | 15:37 |
| rdopiera | I'm not even sure if the policy of using the latest microversion when microversion is specified is good | 15:37 |
| vishalmanchanda | yeah last time I bump some microversion it leads to resize instance feature stops working. | 15:38 |
| vishalmanchanda | moving to the next topic | 15:39 |
| amotoki | perhaps it is better to narrow the range of possible API versions. it would help us understand what will happen | 15:39 |
| amotoki | go ahead | 15:40 |
| vishalmanchanda | amotoki: +1, on narrowing the rage of api version. | 15:41 |
| vishalmanchanda | #topic On-Demand Agenda | 15:41 |
| vishalmanchanda | https://review.opendev.org/q/topic:horizon-keystoneauth-original_ip | 15:41 |
| vishalmanchanda | tobias-urdin: that's you, please go ahead. | 15:42 |
| tobias-urdin | I can give some context | 15:42 |
| tobias-urdin | so I'm working from a security/compliance angle | 15:42 |
| 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:42 |
| tobias-urdin | that will send the RFC 7239 "Forwarder" header (keystoneauth1 will set it) when talking to Keystone | 15:43 |
| tobias-urdin | this makes it possible to log every single client IP making a request, even for proxied auth requests, like from Horizon | 15:43 |
| 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 |
| 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:44 |
| 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 |
| 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:45 |
| amotoki | I have questions | 15:46 |
| tobias-urdin | TLDR; Horizon should pass real client IP to original_ip parameter for keystoneauth1.Session | 15:46 |
| tobias-urdin | amotoki: sure | 15:47 |
| 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:47 |
| amotoki | actually horizon issues a token and a user does not. | 15:48 |
| amotoki | I would like to say "After this patch it looks like a request comes from ...." | 15:49 |
| amotoki | another question is whether we would like to do the similar thing for API requests to other services like nova. | 15:49 |
| 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:50 |
| tobias-urdin | except for correlationing dates and possible request IDs in log files | 15:51 |
| tobias-urdin | what we are doing is reading that header: | 15:51 |
| 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 |
| amotoki | tobias-urdin: I see. sounds reasonable. | 15:51 |
| tobias-urdin | and logging the authentication (for compliance purposes here) request as being made by 100.64.10.1 | 15:51 |
| 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:52 |
| 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 |
| 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:54 |
| amotoki | tobias-urdin: thanks. it is interesting | 15:55 |
| vishalmanchanda | tobias-urdin: thanks for bringing it here. | 15:55 |
| tobias-urdin | no worries, thanks for your time and sorry for the wall of text :) | 15:56 |
| vishalmanchanda | reviewers please take a look at patches and add your thoughts. | 15:56 |
| vishalmanchanda | Does anyone wants to discuss any other topic? | 15:57 |
| vishalmanchanda | amotoki: in case you missed, I am waiting for your reply on patch https://review.opendev.org/c/openstack/horizon/+/830936 | 15:58 |
| amotoki | vishalmanchanda: thanks for reminding it. I did not notice it. thanks | 15:59 |
| vishalmanchanda | If nothing more to discuss, let's end this meeting. | 15:59 |
| vishalmanchanda | Thanks everyone for joining and your contributions! | 16:00 |
| opendevreview | Tobias Urdin proposed openstack/horizon master: Pass client IP to keystoneauth1 session https://review.opendev.org/c/openstack/horizon/+/839161 | 16:00 |
| vishalmanchanda | See you next week. | 16:00 |
| vishalmanchanda | #endmeeting | 16:00 |
| opendevmeet | Meeting ended Wed Apr 27 16:00:29 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-04-27-15.00.html | 16:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-04-27-15.00.txt | 16:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/horizon/2022/horizon.2022-04-27-15.00.log.html | 16:00 |
| amotoki | o/ | 16:01 |
| tobias-urdin | thanks! | 16:03 |
| opendevreview | Akihiro Motoki proposed openstack/horizon master: Add UT coverage for attach_interface by port https://review.opendev.org/c/openstack/horizon/+/830936 | 23:20 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!