Switching horizon to material theme borks the ui

[mvdkleijn]

Request Method: | GET
-- | --
http://127.0.0.1/project/
1.11.14
SassImportError
Couldn't find anything to import: ../../mixins Extensions: <NamespaceAdapterExtension>, <DjangoExtension>, <CompassExtension> Search path:    on line 21 of horizon/lib/roboto_fontface/css/roboto/sass/roboto-fontface-regular.scss imported from line 21 of horizon/lib/roboto_fontface/css/roboto/sass/roboto-fontface.scss imported from line 16 of themes/material/bootstrap/_styles.scss imported from line 16 of themes/material/_styles.scss imported from line 1 of u'string:c61b5d22d54bf56c:\n    // My Themes\n@import "/themes/material/variables";\n\n// Horizon\n@import "/dashboard/scss/horizon'
/snap/microstack/60/lib/python2.7/site-packages/scss/compiler.py in _at_import, line 861
/snap/microstack/60/bin/uwsgi
2.7.12
['.',  '',  '/snap/microstack/60/usr/lib/python2.7',  '/snap/microstack/60/usr/lib/python2.7/plat-x86_64-linux-gnu',  '/snap/microstack/60/usr/lib/python2.7/lib-tk',  '/snap/microstack/60/usr/lib/python2.7/lib-old',  '/snap/microstack/60/usr/lib/python2.7/lib-dynload',  '/snap/microstack/60/usr/lib/python2.7/dist-packages',  '/snap/microstack/60/lib/python2.7/site-packages',  '/snap/microstack/60/lib/python2.7/site-packages/openstack_dashboard']
Wed, 14 Nov 2018 21:41:54 +0000

[mvdkleijn]

Installed according to readme and successfully logged into horizon by the way. Default theme appeared fine.

[pengale]

Thank you for the bug report!

Work on themes is on our TODO list for the project. I bet it's just a path missing, or path misplaced, when the snap builds.

[pengale]

It looks like the problem is that the mixins dir does exist, but it's in a different branch of the xstatic file hierarchy than the roboto scss file expects it to be.

Either we're building the horizon package incorrectly, or django expects to be able to shuffle those files around at runtime, and isn't able to because the snap live in a read only filesystem.

I've been working on testing the "we're not building something correctly" theory.

At some point, I may just get tempted to smash the mixins directory into the place that the roboto font expects it to be, but I'm worried that there may be other bugs related to this, lurking in the corners.

[pengale]

@mvdkleijn Just a quick note: how certain are we that this is a snap issue, and not an issue with installing from the tarball?

Internally, microstack simply downloads and makes/configures the rocky release tarballs, assuming that we don't have to do things like run django manage.py collectstatic and such manually. Is that a bad assumption on our part?

[pengale]

I think that I've got a better handle on this now.

What's happening is that the snap is simply grabbing the release tarball and running "python setup.py", which leaves us with a horizon server listening at port 80, with the horizon dashboard accessible via nginx's root url (http://localhost). In a more typical deployment, two things are different:

1) There's some massaging of directories so that the uwsgi script uses something like /usr/share/openstack-dashboard, which includes a symlink to the horizin dir in site-packages, as its working directory. local_settings.py, meanwhile, lives in /etc/openstack-dashboard.

2) Horizon typically lives at http:///horizon in the web server's url hierarchy

So either the material theme has a hard coded path involving that /horizon part of the url, or it simply can't find some critical pieces from its working directory. I'm going to work on correcting both issues, and rebuilding the snap with a more typical directory structure.

[pengale]

An update here. It turns out that this is partially my fault (though only partially ;-p )

Early on, I set the STATIC_ROOT in horizon's Django local settings to point at a dir in /var/snap/microstack/common. This is because Django needs to write files to the dir referenced in that setting, and it can't write to anything to the default location, under the read only filesystem mounted at /snap/microstack

Then I moved on and forgot that I had set the STATIC_ROOT.

The default theme works fine (though I don't know whether it's successfully reading the statically cached files -- if it's not, that might contribute to a little bit of annoying interface slowness). The material theme, otoh, seems to make some assumptions about how things are arranged that don't take into account the fact that STATIC_ROOT is a setting that can be changed.

I think that the next steps are to test this outside of microstack. If the material theme breaks whenever STATIC_ROOT is set, then this is an upstream bug. If it doesn't, then that means that microstack has files arranged in an unexpected way, and should be fixed.

For now, I've turned off all but the default theme, to prevent users from breaking their GUI while we resolve the issue.

[mvdkleijn]

Hi @petevg

Thanks for the detailed information and investigation and apologies for not responding sooner, December was a very hectic month for me and I'm only just coming out of it. :smile:

Though I'd love to have multiple themes available, the most important part is indeed that users don't get bricked out of their UI.

For me your solution, however temporary, is fine. I'll leave open this issue in case someone wants / can help with it.

Again, thanks for your help.

[pengale]

We're moving issues to launchpad. Here's where this one lives: https://bugs.launchpad.net/microstack/+bug/1812418

(Thanks @mvdkleijn for the comments and bug reporting.)

[mvdkleijn]

Closing this in favor of the launchpad one.