15:01:58 #startmeeting horizon 15:02:00 Meeting started Wed Mar 18 15:01:58 2020 UTC and is due to finish in 60 minutes. The chair is amotoki. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:03 The meeting name has been set to 'horizon' 15:02:04 hi 15:02:05 hi 15:02:14 o/ 15:02:57 vishal does not join today 15:03:00 I think we can start 15:03:08 #topic notices/annoucements 15:03:25 as usual, Ussuri-3 is the week of Apr 6 15:03:39 it is three weeks away 15:04:05 in addition, victoria PTL nomination will start next week 15:04:33 I am feeling burning out in horizon a bit so I am not sure nominate myself again. 15:04:35 it's 50% 15:04:40 amotoki: are you going to nominate yourself? 15:04:51 :( 15:05:06 btw, TC is talking about getting rid of PTL role 15:05:23 yeah, I see that ML thread 15:05:58 more responsible I try to be, less time i can spend others..... 15:06:28 #link https://review.opendev.org/#/c/712696/ 15:07:21 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-March/thread.html#12950 15:07:40 all feedback should now go to the review e0ne posted 15:08:20 any other thing to be shared? 15:08:37 just a reminder about PTG 15:08:51 #link https://www.openstack.org/events/covid-19-coronavirus-disease-updates 15:09:02 it's supposed to be in Vancouver 15:09:20 but probably we'll virtual PTG this time :( 15:09:32 I think so too 15:09:39 we just discussed it during the cinder meeting 15:11:13 in openstack-discuss ML, there are ongoing discussion on virtual events 15:11:31 I believe we can collect best practices on virtual events :) 15:11:45 okay, moving on 15:11:59 I would like to discuss further steps on pyscss problem first 15:12:14 #topic further steps on pyscss 15:12:36 oh.. good topic 15:12:44 ;) 15:12:47 thanks e0ne for forking pyscss and make the gate healthy again 15:13:06 amotoki: it's only for master 15:13:17 I summarized potential topics on https://etherpad.openstack.org/p/horizon-release-priorities 15:13:25 See around L.23 15:13:31 e0ne: there was a patch for train iirc 15:13:38 #link https://review.opendev.org/#/c/713640/2 15:13:51 the first one is about stable branches 15:14:20 the main problem in stable branches is whether we should change the dependencies. 15:14:39 I would like to see setuptools cap in stable upper-constraints 15:14:47 in distros, I guess they use setuptools <46 and pyscss and django-pyscss works 15:15:10 Changing the requirements is fairly a big impact. 15:15:12 unless you use virtualenv as then you need to remember to downgrade setuptools 15:15:27 hrw: +1 15:15:30 hrw: yes 15:15:37 and move to pyscss2 in stable just means add line to requirements 15:15:49 the problem is that tox tries to install the latest setuptools when creating a vevn 15:15:51 as code is more or less the same 15:15:56 s/vevn/venv/ 15:15:58 hrw: not only. it affects all vendors who do packaging 15:16:22 e0ne: add code to handle both? 15:16:40 it's a good option 15:16:45 as kind of backward compatibility 15:16:53 but I'm not sure how can we do it 15:17:05 try import pyscss2 except ImportError import pyscss? 15:17:23 but I never used pyscss so no idea how it works/gets used 15:17:25 pyscss2 package hase the same python API 15:17:27 hrw: pyscss2 also provides 'pyscss' module too. 15:17:49 right 15:18:25 so basically it does not matter which one distro provides 15:18:40 we can create pyscss2 module and use import-try-except pattern, but I don't like this solution, TBH 15:18:52 e0ne: yeah. ugly 15:19:15 it would be good to discuss this with requirements tesm 15:19:19 *team 15:19:24 how about clarifying problems we see first before discussing pyscss vs pyscss2? 15:19:36 I see two problems in stable/train at least. 15:19:58 the one is ONLY py37 job fails, while py36 job succeeds. 15:20:32 the other is tox -e py36 in local envs usually fails 15:20:41 as tox picks up setuptools 46 15:20:50 do you see something other? 15:21:19 i haven't checked stable/stein cases. 15:22:05 I didn't check why only py37 fails 15:22:17 e0ne: yeah, me neither 15:22:29 that's the point I need to ask the infra team. 15:22:32 https://review.opendev.org/#/c/713678/ - patch to test stable/stein 15:22:48 perhaps py36 job uses setuptools <46 15:23:15 in our downstream CI, we faced this issue for train with py3[6,7] and pep8 jobs :( 15:23:17 I will ask the difference in #-infra channel or ML after the meeting 15:24:18 e0ne: that's a same problem as the second one from mine (tox failure in local envs) 15:25:22 :( 15:26:49 I think we need to clarify the folowing points: 15:26:51 (1) is there a way to pin setuptools <46 with tox 15:27:12 (2) requirements change in stable branches is possible or not. what is the right way? 15:27:35 amotoki: there is no setuptools in the upper-constraints 15:27:55 virtualenv is created before u-c comes 15:28:01 (3) related to (1), what is the magic in the opendev.org env (regarding to py36) 15:28:07 amotoki: I'm going to ask (2) to requirements team 15:28:09 and venv usually includes setuptools 15:28:52 hrw: oh.. thanks for mentioning it! now it's obvious why it's not in u-c 15:29:37 e0ne: yeah, tox creates a virtualenv first and you can see xxx-1.log in tox logs 15:29:42 for example https://zuul.opendev.org/t/openstack/build/79fd8706518844f59bba9dbd03cac9b6/log/tox/py37-0.log 15:29:52 I missed it:( 15:30:05 basically each job with venv needs do "pip install setuptools<46" after creating venv 15:30:17 "/usr/bin/python3 -m virtualenv" fetches setuptools=latest (default) unless setuptools arg is specified. 15:30:36 hrw: yeah, exactly 15:32:09 we can have a dirty workaround which creates a virtualenv with empty requirements with setuptools<46 first and then install requirements 15:32:43 for now we (kolla) pin setuptools to <46 in master and train 15:32:43 it sounds reasonable 15:33:44 ok, sent revert of it in master for review 15:34:56 so perhaps it looks like the first thing is to ask suggestions on the requirements team 15:35:15 +1 15:35:18 and another action item is to try a workaround 15:35:32 e0ne: I can ask it tomorrow, but you can do it 15:35:42 if you start the discussion 15:36:20 I'll ping them now 15:36:27 cool 15:37:28 apart from a thing on stable branches, we need to explore the future direction on scss compiler. 15:37:48 (L.27 on https://etherpad.openstack.org/p/horizon-release-priorities) 15:38:38 an ideal solution, it to switch to some npm-based packages 15:38:55 yeah, like webpack 15:39:12 but it requires a lot of efforts 15:39:43 I don't know current distros like RHOSP handles multiple versions of JS modules. 15:40:00 this is the only reason we use xstatic....... 15:40:27 debian-based distros don't use all xstatic 15:40:50 what approach do they use? 15:41:28 https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=libjs 15:41:53 amotoki: I can't say about all vendors and discros 15:42:05 e0ne: no problem 15:42:15 a single person cannot know all 15:42:23 even fro deb-based somebody could use own xstatic deb packages 15:42:42 rdopiera: are you around? we need some kind of RH support 15:42:49 even with debian-based distros, they use a single version of JS libraries. 15:43:12 npm based approach leads to multiple versions of JS libraries in a single system. 15:43:21 +1 15:43:31 that's very different point from the current approach. 15:43:39 yes, it is 15:44:26 for a short/mid term I think we cannot drop django integration of scss compiler. 15:44:41 +1 15:44:50 it required by bootstrap 15:44:58 there are two scss/sass compilers as far as I checked. 15:45:15 even if we change everything to less, it's pretty late to do it in U 15:45:44 which is required by bootstrap? 15:45:48 scss? 15:46:05 we use scss in xstatic-bootstrap 15:46:13 got it. 15:46:52 we forked pyscss but my understanding is we don't want to maintain scss compiler. 15:46:55 #linke https://review.opendev.org/#/c/710865/ 15:47:11 #link https://review.opendev.org/#/c/710865/ 15:48:12 libsass (C/C++ lib) and python-libsass looks maintained well, so I am exploring a possibility to migrate to one of them. 15:48:22 amotoki: I'm going to maintain forked packages at least I'll be involved in openstack development and it'll be used by horizon 15:48:40 e0ne: including scss compiler features? 15:49:08 amotoki: it's a good question 15:49:17 at least we blocked pyScss 1.3.5 in global-requirements 15:49:24 due to horizon requirements 15:49:37 yes. horizon can't work with the latest pyScss :( 15:49:53 it fails to compile scss 15:50:01 I added some links to the etherpad for my memory 15:51:11 IMHO, the very short term solution is to make horizon work with pyscss2 and we can explore alternatives during it. 15:51:52 amotoki: +1 15:52:11 thanks 15:52:43 I don't want to go to the route same as for mox3 and nose-htmloutput..... i.e. to maintain our own forks.. 15:53:27 amotoki, hrw:https://github.com/Kronuz/pyScss/pull/386#issuecomment-600710059 15:54:03 wow! 15:54:07 sounds a good news :) 15:54:18 e0ne: apply for it as you use it 15:54:40 I just fixed setuptools/CI and have no idea what the project is 15:55:42 hrw: :) 15:55:55 I am mastering drive-by-coding 15:55:56 e0ne: hrw: it would be better to clarify our positions that we just try to work it in the latest python world even if you will be part of the maintainers. 15:56:05 or that 15:56:11 amotoki: so probably we'll just release a new pyScss and fix horizon to work with it 15:56:39 yeah 15:58:11 commented 15:58:37 we still have a problem with the latest pyscss, so if we can succeed to handle our SCSS with python-libsass it would be a good alternative. 15:59:16 amotoki: +1 15:59:18 so I will still continue to explore another way too. 15:59:26 thanks 15:59:35 anything maintained will be better 15:59:43 +1000 15:59:57 hrw: +2 16:00:17 okay, we are time to finish the meeting. one hour passed. 16:00:31 it was a good discussion 16:00:38 thanks for joining 16:00:41 #endmeeting