[tc][requirements][horizon] Broken gates due to the new setuptools and pyScss package
Hi team,
I'm sorry for being too noisy, but I decided to tag TC to get more attention to the current Horizon situation.
We've got a bug reported by Kolla team two days ago [1]. We merged some workaround [2] and [3] yesterday. Thanks a lot to the Requirements team for the really quick merge! I appreciate it.
For now, we've got horizon gates broken because of hose patches fix only devstack but not unit tests jobs.
The root cause of this situation is pyScss package which is not maintained for the last two years. It's not a surprise to me that it doesn't work with the new setuptools. I'm really surprised that we've found this kind of bugs only now.
Since I don't believe we can block new setuptools forever, I decided to fork pyScss [4] and django-pyscss [5] projects. I'm still not sure that I've done everything right with licensing and versioning, but it works now on my environment. Any help on these areas would be much appreciated. I proposed patches to requirements and horizon repos [6] to use new libraries.
The reason I've tagged TC in the mail thread is described below.
Horizon has a lot of too old and unmaintained libraries. I'm pretty sure that this only one of the first issues with outdated dependencies which blocks horizon and other gates. I do understand why we've got this situation. Unfortunately, we don't have any full-time horizon developers in the community. Horizon is mostly in maintenance phrase but not in active development.
I would like to get more attention on this issue because we have to update all dependencies not because they are new, have new features and/or security fixes. We have to take care of our dependencies asap to avoid usage of unmaintained libraries to have the whole OpenStack and Horizon healthy.
P.S. I'm sorry if this message is too rude or emotional, I really don't want to make it such one.
[1] https://bugs.launchpad.net/kolla/+bug/1866961 [2] https://review.opendev.org/#/c/711930/ [3] https://review.opendev.org/#/c/712777/ [4] https://github.com/e0ne/pyScss/ [5] https://github.com/e0ne/django-pyscss [6] https://review.opendev.org/#/q/status:open+topic:fix-pyscss
Regards, Ivan Kolodyazhny, http://blog.e0ne.info/
On Fri, 2020-03-13 at 18:29 +0200, Ivan Kolodyazhny wrote:
Hi team,
I'm sorry for being too noisy, but I decided to tag TC to get more attention to the current Horizon situation.
Don't be sorry, it's good that you raise this point!
We've got a bug reported by Kolla team two days ago [1]. We merged some workaround [2] and [3] yesterday. Thanks a lot to the Requirements team for the really quick merge! I appreciate it.
For now, we've got horizon gates broken because of hose patches fix only devstack but not unit tests jobs.
The root cause of this situation is pyScss package which is not maintained for the last two years. It's not a surprise to me that it doesn't work with the new setuptools. I'm really surprised that we've found this kind of bugs only now.
I suppose that we can't easily get rid of the dependency...
Since I don't believe we can block new setuptools forever, I decided to fork pyScss [4] and django-pyscss [5] projects. I'm still not sure that I've done everything right with licensing and versioning, but it works now on my environment. Any help on these areas would be much appreciated. I proposed patches to requirements and horizon repos [6] to use new libraries.
I checked your repos, they are BSD and MIT licensed. Which means: - Horizon didn't do anything wrong with using them in the first place - Your fork can be used to use them - We could make "your forks" projects on opendev.
I suppose you're not only calling to say that you're now maintainer, but instead want to raise the fact that you're (now) the only maintainer, and we need more folks to step up and help maintain...
The reason I've tagged TC in the mail thread is described below.
Horizon has a lot of too old and unmaintained libraries. I'm pretty sure that this only one of the first issues with outdated dependencies which blocks horizon and other gates.
Is there a path forward to remove the usage of those dependencies, or to change things? If we have a plan, it's (relatively) less hard to point people to work on said plan to get help.
I do understand why we've got this situation. Unfortunately, we don't have any full-time horizon developers in the community. Horizon is mostly in maintenance phrase but not in active development.
Sadly, it can be said of multiple projects. I am definitely hoping that Horizon will get the attention it deserves. Having a plan of "renovation"/"renewal" of horizon might help, as said above.
I would like to get more attention on this issue because we have to update all dependencies not because they are new, have new features and/or security fixes. We have to take care of our dependencies asap to avoid usage of unmaintained libraries to have the whole OpenStack and Horizon healthy.
Agreed. Do you have other dependencies that are at risk here for horizon? Did you audit this recently?
P.S. I'm sorry if this message is too rude or emotional, I really don't want to make it such one.
It's not rude or emotional. You're raising a good point.
[1] https://bugs.launchpad.net/kolla/+bug/1866961 [2] https://review.opendev.org/#/c/711930/ [3] https://review.opendev.org/#/c/712777/ [4] https://github.com/e0ne/pyScss/ [5] https://github.com/e0ne/django-pyscss [6] https://review.opendev.org/#/q/status:open+topic:fix-pyscss
Regards, Ivan Kolodyazhny, http://blog.e0ne.info/
I think it might be worth splitting this email in multiple topics: - Should we move pyScss and django-pyscss into opendev? (Do you want to do it, or are you fine with your current fork right now?) - How can we clean up the dependencies in horizon? - Should Horizon be listed in the business opportunities, to have someone to step up? - Should the TC audit all the official projects to avoid usage of unmaintained libraries?
Regards, JP
Hi, I would like to just add my cent to the question of ownership of these forked repos: I am on the side to have opendev ownership over them as that give long(er) term stability, even now when we have serious shortages in design. But consider the situation when e0ne leave the community, we have to do the fork again and move these repos under opendev umbrella.
Regards Lajos
Jean-Philippe Evrard jean-philippe@evrard.me ezt írta (időpont: 2020. márc. 16., H, 9:54):
On Fri, 2020-03-13 at 18:29 +0200, Ivan Kolodyazhny wrote:
Hi team,
I'm sorry for being too noisy, but I decided to tag TC to get more attention to the current Horizon situation.
Don't be sorry, it's good that you raise this point!
We've got a bug reported by Kolla team two days ago [1]. We merged some workaround [2] and [3] yesterday. Thanks a lot to the Requirements team for the really quick merge! I appreciate it.
For now, we've got horizon gates broken because of hose patches fix only devstack but not unit tests jobs.
The root cause of this situation is pyScss package which is not maintained for the last two years. It's not a surprise to me that it doesn't work with the new setuptools. I'm really surprised that we've found this kind of bugs only now.
I suppose that we can't easily get rid of the dependency...
Since I don't believe we can block new setuptools forever, I decided to fork pyScss [4] and django-pyscss [5] projects. I'm still not sure that I've done everything right with licensing and versioning, but it works now on my environment. Any help on these areas would be much appreciated. I proposed patches to requirements and horizon repos [6] to use new libraries.
I checked your repos, they are BSD and MIT licensed. Which means:
- Horizon didn't do anything wrong with using them in the first place
- Your fork can be used to use them
- We could make "your forks" projects on opendev.
I suppose you're not only calling to say that you're now maintainer, but instead want to raise the fact that you're (now) the only maintainer, and we need more folks to step up and help maintain...
The reason I've tagged TC in the mail thread is described below.
Horizon has a lot of too old and unmaintained libraries. I'm pretty sure that this only one of the first issues with outdated dependencies which blocks horizon and other gates.
Is there a path forward to remove the usage of those dependencies, or to change things? If we have a plan, it's (relatively) less hard to point people to work on said plan to get help.
I do understand why we've got this situation. Unfortunately, we don't have any full-time horizon developers in the community. Horizon is mostly in maintenance phrase but not in active development.
Sadly, it can be said of multiple projects. I am definitely hoping that Horizon will get the attention it deserves. Having a plan of "renovation"/"renewal" of horizon might help, as said above.
I would like to get more attention on this issue because we have to update all dependencies not because they are new, have new features and/or security fixes. We have to take care of our dependencies asap to avoid usage of unmaintained libraries to have the whole OpenStack and Horizon healthy.
Agreed. Do you have other dependencies that are at risk here for horizon? Did you audit this recently?
P.S. I'm sorry if this message is too rude or emotional, I really don't want to make it such one.
It's not rude or emotional. You're raising a good point.
[1] https://bugs.launchpad.net/kolla/+bug/1866961 [2] https://review.opendev.org/#/c/711930/ [3] https://review.opendev.org/#/c/712777/ [4] https://github.com/e0ne/pyScss/ [5] https://github.com/e0ne/django-pyscss [6] https://review.opendev.org/#/q/status:open+topic:fix-pyscss
Regards, Ivan Kolodyazhny, http://blog.e0ne.info/
I think it might be worth splitting this email in multiple topics:
- Should we move pyScss and django-pyscss into opendev? (Do you want to
do it, or are you fine with your current fork right now?)
- How can we clean up the dependencies in horizon?
- Should Horizon be listed in the business opportunities, to have
someone to step up?
- Should the TC audit all the official projects to avoid usage of
unmaintained libraries?
Regards, JP
Would a more sustainable workaround of switching the pyscss code to something that uses libsass-python:
https://pypi.org/project/django-libsass/
That seems like an alternative and it means maintaining _far_ less code..
Hi,
I agree with JP that this thread covers multiple topics. I would like to use this thread to focus on the original topic of the horizon gate breakage and cover other topic on further discussions in separate threads.
TLDR; the workaround to fork pyScss and django-pyscss is a good compromise as a short-term solution. it allows us to explore alternatives without blocking other patches.
On Mon, Mar 16, 2020 at 9:27 PM Mohammed Naser mnaser@vexxhost.com wrote:
Would a more sustainable workaround of switching the pyscss code to something that uses libsass-python:
https://pypi.org/project/django-libsass/
That seems like an alternative and it means maintaining _far_ less code..
Using python-libsass sounds reasonable as libsass is a mature C/C++ SASS engine and python-libsass provides the python bindings for it.
I see two libsass support for Django: django-libsass (mnaser mentioned above) and django-sass-processor. I am not sure which is better at the moment.
[1] https://pypi.org/project/django-libsass/ [2] https://pypi.org/project/django-sass-processor/
On the other hand, they are not drop-in-replacement, so the migration may take time. We have the gate breakage right now, so I think the workaround to fork pyScss and django-pyscss is a good compromise as a short-term solution. it allows us to explore alternatives without blocking other patches.
On Mon, Mar 16, 2020 at 6:27 PM Lajos Katona katonalala@gmail.com wrote:
Hi, I would like to just add my cent to the question of ownership of these forked repos: I am on the side to have opendev ownership over them as that give long(er) term stability, even now when we have serious shortages in design. But consider the situation when e0ne leave the community, we have to do the fork again and move these repos under opendev umbrella.
I discussed it with e0ne when he forked these repositories. We don't want to depend on them. We are forking these repos but it is just to catch up the recent changes in setuptools and to give us time to explore alternatives. We don't plan to maintain features in pyscss itself in the forked repository. This is a short-time workaround and IMHO it is not a good idea to create and retire repositories under OpenStack governance in a short term. If we decide to continue to use these libraries, then it is time to host these forked repositories in OpenStack world.
Thanks, Akihiro
Hi,
Thanks for the clear way forward Akihiro, I hope that this helps us.
Lajos
Akihiro Motoki amotoki@gmail.com ezt írta (időpont: 2020. márc. 17., K, 5:31):
Hi,
I agree with JP that this thread covers multiple topics. I would like to use this thread to focus on the original topic of the horizon gate breakage and cover other topic on further discussions in separate threads.
TLDR; the workaround to fork pyScss and django-pyscss is a good compromise as a short-term solution. it allows us to explore alternatives without blocking other patches.
On Mon, Mar 16, 2020 at 9:27 PM Mohammed Naser mnaser@vexxhost.com wrote:
Would a more sustainable workaround of switching the pyscss code to something that uses libsass-python:
https://pypi.org/project/django-libsass/
That seems like an alternative and it means maintaining _far_ less code..
Using python-libsass sounds reasonable as libsass is a mature C/C++ SASS engine and python-libsass provides the python bindings for it.
I see two libsass support for Django: django-libsass (mnaser mentioned above) and django-sass-processor. I am not sure which is better at the moment.
[1] https://pypi.org/project/django-libsass/ [2] https://pypi.org/project/django-sass-processor/
On the other hand, they are not drop-in-replacement, so the migration may take time. We have the gate breakage right now, so I think the workaround to fork pyScss and django-pyscss is a good compromise as a short-term solution. it allows us to explore alternatives without blocking other patches.
On Mon, Mar 16, 2020 at 6:27 PM Lajos Katona katonalala@gmail.com wrote:
Hi, I would like to just add my cent to the question of ownership of these
forked repos:
I am on the side to have opendev ownership over them as that give
long(er) term stability,
even now when we have serious shortages in design. But consider the
situation when
e0ne leave the community, we have to do the fork again and move these
repos under
opendev umbrella.
I discussed it with e0ne when he forked these repositories. We don't want to depend on them. We are forking these repos but it is just to catch up the recent changes in setuptools and to give us time to explore alternatives. We don't plan to maintain features in pyscss itself in the forked repository. This is a short-time workaround and IMHO it is not a good idea to create and retire repositories under OpenStack governance in a short term. If we decide to continue to use these libraries, then it is time to host these forked repositories in OpenStack world.
Thanks, Akihiro
participants (5)
-
Akihiro Motoki
-
Ivan Kolodyazhny
-
Jean-Philippe Evrard
-
Lajos Katona
-
Mohammed Naser