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