15:00:16 <vishalmanchanda> #startmeeting horizon
15:00:16 <opendevmeet> Meeting started Wed Sep  1 15:00:16 2021 UTC and is due to finish in 60 minutes.  The chair is vishalmanchanda. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <opendevmeet> The meeting name has been set to 'horizon'
15:00:59 <rdopiera> o/
15:01:18 <tmazur> o/
15:01:28 <vishalmanchanda> hello everyone
15:02:00 <vishalmanchanda> Let's wait for few minutes if more people joins us.
15:04:08 <vishalmanchanda> ok Let's start.
15:04:17 <vishalmanchanda> #topic Notices
15:04:53 <vishalmanchanda> This week is Xena-3 milestone.
15:05:04 <vishalmanchanda> Xena Schedule https://releases.openstack.org/xena/schedule.html
15:05:26 <vishalmanchanda> Also Feature freeze so no feature patch should be merged after September 3rd.
15:05:40 <vishalmanchanda> So reviewer please keep that in mind while reviewing any feature patch.
15:06:25 <vishalmanchanda> I was hoping Qos Policy rule patch merged in xena release but it's look difficult now.
15:06:32 <vishalmanchanda> https://review.opendev.org/c/openstack/horizon/+/805360
15:07:09 <vishalmanchanda> I have pushed the patch to add horizon xena cycle highlight https://review.opendev.org/c/openstack/releases/+/806886
15:07:28 <vishalmanchanda> release team is so fast and patch is already merged:)
15:07:52 <vishalmanchanda> Please let me know if I forgot to add anything that should be good to have in cycle highlights.
15:08:12 <vishalmanchanda> I will update try to update it.
15:08:52 <vishalmanchanda> that's all update from my side for this week.
15:09:02 <vishalmanchanda> #topic open-discussion
15:09:27 <vishalmanchanda> we have many patches with single +2 so please take a took at those patches.
15:10:27 <vishalmanchanda> I will also try to push a patch to update 'policy.yaml' file for different backend services under https://github.com/openstack/horizon/tree/master/openstack_dashboard/conf/default_policies by tomorrow.
15:11:07 <vishalmanchanda> I have no more topic to discuss.
15:11:31 <vishalmanchanda> Please go ahead if anyone have any topic to discuss.
15:12:01 <rdopiera> I would like to talk a bit about integration tests.
15:12:18 <vishalmanchanda> rdopiera: sure, go ahead.
15:12:54 <rdopiera> We started to look into writing additional integration tests for individual features that have been implemented. However, many of those features require a specific setting in the local_settings.py
15:13:17 <rdopiera> I wonder how we could implement that with our current system.
15:13:38 <rdopiera> Obviously, selenium itself can't modify the settings of a running horizon instance.
15:14:44 <vishalmanchanda> Could you give me some specific example for such case.
15:16:28 <rdopiera> One change that we have made was changing the order of fields on the login screen with multidomain support enabled.
15:16:44 <rdopiera> Obviously to test this, we need to enable multidomain support.
15:19:22 <vishalmanchanda> ahh I see, nothing coming to my mind atm.
15:20:24 <vishalmanchanda> Does  anyone have any thoughts in your mind how can we handle it?
15:20:34 <vishalmanchanda> e0ne: ^^around?
15:21:15 <rdopiera> the only thing that I can think of is to have several horizon configurations defined, as required by the tests, and then to tag the tests marking which configuration they expect, then in the job setup one config, run the tests for that config, setup the next, run the tests for it, etc.
15:21:37 <rdopiera> but this wouldn't work for running the tests locally
15:22:39 <amotoki> the integration tests runs as a separate process from the web server, so what we can in my initial thought do is to repeat steps with horizon configuration and then running tests.
15:23:02 <amotoki> rdopiera: you arefaster than me. what doesn't work in your local run?
15:23:51 <rdopiera> well, in a local run you would need to make the config changes yourself manually
15:24:10 <amotoki> ah, I see
15:25:17 <amotoki> our current integration is not so fast and it is run in serial, so adding more tests is not so welcome. perhaps we need to explore how we can make it run in parallel (or run extra tests in a separate job)
15:26:08 <tmazur> Can we have a few jobs to somehow make them "parallel"?
15:26:25 <tmazur> With different configs
15:27:34 <amotoki> sorry, "welcome" was confusing. I mean developers need to wait more and it is not a happy situtation.
15:28:19 <amotoki> tmazur: thoretically we can. perhaps we need some way to split tests into multiple sets (tag?).
15:28:41 <rdopiera> we can mark some of the tests as "blocking" and only run those on the gate
15:28:51 <amotoki> ideally we can run the integration tests in parallel with tox
15:28:55 <rdopiera> and only run the others locally
15:29:07 <vishalmanchanda> rdopiera: +1.
15:30:11 <amotoki> do you mean such "blocking" tests are not run in the CI?
15:30:15 <rdopiera> I think there is also an opportunity to speed up the integration tests considerably -- I noticed that they spend a long time waiting before handling any modal, but I wasn't able to track down where that wait was happening in code exactly
15:30:59 <rdopiera> amotoki: tests that are not blocking wouldn't be run on the gate, but they would still run if you run it manually, or we could even have a job that runs all tests once a week or something
15:33:17 <amotoki> I am not sure we have tests to be marked as "blocking" now.
15:34:29 <amotoki> btw, perhaps "periodic" job allows us to run more jobs. we can check their results via zuul build results.
15:35:12 <rdopiera> test_login and test_create_delete_instance come to mind
15:38:08 <amotoki> test_create_delete_instance is slow but it covers the essential feature. I am not sure it is the thing we can skip in the gate.
15:39:57 <vishalmanchanda> I am agree with amotoki
15:42:06 <rdopiera> amotoki: that is why we want it to be blocking
15:42:14 <rdopiera> amotoki: that is, to run on the gate
15:43:36 <amotoki> I don't know it is the slowest one
15:43:53 <ikanias> radopiera: can we just put tests that need pre-configuration under a separate folder and just run them separately? just so we can distinguish between them and the regular tests
15:44:28 <amotoki> looking at https://zuul.opendev.org/t/openstack/build/54700c9e3d2f4c0fb6180299b7af9410/log/job-output.txt#25385 (one of the recent runs of integration tests)
15:44:49 <amotoki> project test_create_delete_instances took almost 1m30s
15:45:00 <rdopiera> ikanias: that's essentially what I proposed, except we don't have to put them in a different directory, we can just tag them,or even use skipif
15:45:18 <amotoki> I see other tests with around 1m30s or more
15:45:19 <ikanias> rdopiera: i see
15:45:42 <rdopiera> yes, we have some unnecessary waits in there
15:53:05 <vishalmanchanda> Do we have anything else to discuss about this topic?
15:53:53 <tmazur> I have a question about https://review.opendev.org/c/openstack/horizon/+/793970
15:54:23 <tmazur> One integration test is skipped because of this bug
15:54:43 <tmazur> But the fix is not ideal as far as I can tell
15:55:24 <vishalmanchanda> tmazur: ok thanks for letting me know.
15:55:48 <vishalmanchanda> tmazur: I will check it after the meeting and revote.
15:56:19 <tmazur> Thanks vishalmanchanda
15:57:38 <tmazur> And also I kindly ask for some attention here: https://review.opendev.org/c/openstack/horizon/+/800283
15:59:49 <vishalmanchanda> ok let's end the meeting.
16:00:42 <vishalmanchanda> Thank you everyone for joining. See you next week.
16:00:58 <vishalmanchanda> #endmeeting