Re: [openstack-dev] [Horizon] pre-running lesscpy
On Thursday 27 March 2014 16:32:37 Christian Berendt wrote: Hi. Is it possible to pre-run lesscpy? When accessing Horizon in my devstack environment the first time lesscpy is always running several seconds in the background. I've started to investigate Cython for lesscpy. That should speed things up. 0.10.1 is slightly faster already, but it was deferred to Juno (See https://review.openstack.org/#/c/70619/) Tried to run python manage.py compress (setting COMPRESS_OFFLINE=True in the settings.py), but afterwards lesscpy is still running in the background when accessing Horizon the first time. This is odd. I'll have a look... -- Viele Grüße, Sascha Peilicke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [depfreeze][horizon] Exception for lesscpy=0.10.1
Hi, there's been a review up for some time [0] that wants to raise the version of lesscpy to 0.10.1. It's specific to horizon and contains some important fixes that we'll likely want to include. So I'd like to ask for an exception for this one. [0] https://review.openstack.org/#/c/70619/ -- Viele Grüße, Sascha Peilicke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [depfreeze][horizon] Exception for lesscpy=0.10.1
On Wednesday 26 March 2014 13:49:48 Julie Pichon wrote: On 26/03/14 12:14, Sascha Peilicke wrote: Hi, there's been a review up for some time [0] that wants to raise the version of lesscpy to 0.10.1. It's specific to horizon and contains some important fixes that we'll likely want to include. So I'd like to ask for an exception for this one. [0] https://review.openstack.org/#/c/70619/ The review comments indicate this is needed for Bootstrap 3, which was deferred to Juno. Is it needed for something else in Icehouse? Is something broken without it? If not, it seems to me it's probably ok to merge only at the beginning of Juno. Otherwise, apparently I've been running with 0.10.1 in some of my VMs for a few weeks and didn't notice any problems, FWIW. It also has the advantage of being a proper release as opposed to beta. Would work for me too, let's defer it then. -- Viele Grüße, Sascha Peilicke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Selenium (which is non-free) is back again in Horizon (Icehouse Beta 3)
Am 14. März 2014 12:32:41 schrieb Thomas Goirand z...@debian.org: Hi, A few months ago, I raised the fact that Selenium *CANNOT* be a hard test-requirements.txt build-dependency of Horizon, because it is non-free (because of binaries like the browser plug-ins not being build-able from source). So it was removed. Now, on the new Icehouse beta 3, it's back again, and I get some unit tests errors (see below). Guys, could we stop having this kind of regressions, and make Selenium tests not mandatory? They aren't runnable in Debian. Identical situation with openSUSE. And I guess Fedora is no different. Cheers, Thomas Goirand (zigo) == ERROR: Failure: ImportError (No module named selenium) -- File openstack_dashboard/test/integration_tests/helpers.py, line 17, in module import selenium ImportError: No module named selenium == ERROR: Failure: ImportError (No module named selenium.webdriver.common.keys) File openstack_dashboard/test/integration_tests/tests/test_login.py, line 15, in module import selenium.webdriver.common.keys as keys ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Viele Grüße, Sascha Peilicke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] django-bootstrap-form django 1.4 / 1.5
Am 30.12.2013 08:31, schrieb Thomas Goirand: Hi, Currently, in the global-requirements.txt, we have: Django=1.4,1.6 django-bootstrap-form However, django-bootstrap-form fail in both Django 1.4 and Django 1.6. What's the way forward? Would it be possible that someone makes a patch for django-bootstrap-form, so that it could work with Django 1.4 1.5 (which would be the best way forward for me...)? Isn't that project dead? I've been using crispy_forms with great success. It provides integration for both bootstrap 2 and 3 and works with Django-1.6. I could have a look into the issue... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On Friday 22 November 2013 13:13:29 Matthias Runge wrote: On 11/21/2013 01:55 PM, Jiri Tomasek wrote: Hi, Regarding less, I don't really care what compiler we use as long as it works. And if we need to provide uncompiled less for production, then let's use Lesscpy. There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. I asked chuck months ago to package it :-) This would imply nodejs in a production environment, when going back to less. Just naming the n word here, makes people bite, for whatever reason ;-) Matthias [1] https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] BootstrapV3 and lessc
On Monday 04 November 2013 10:52:21 Maxime Vidori wrote: Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. Well, not really. As long as COMPRESS_OFFLINE isn't set in your local_settings.py, django_compressor will check if it has compiled CSS files in it's cache and generate them if not. So for a horizon deployment that is setup with the defaults, the very first HTTP request will just trigger the LESS compiler... Regardless of that, nodejs is a huge dependency of which not that many people have long experience with. While I know that nodejs is the new fancy of web development, things where radically different less than 2 years ago. It will the same in 2 years from now. That's why distros want to avoid it if they can. You simply don't know how reliable upstream is. What happens if they need to fix a security issue in that crappy old release that happens to be shipped in, say, openSUSE-12.2. On the other hand. using a pure-Python implementation has countless advantages in our context. It can be handled inside pip requirements files, whereas you need to interact with the underlying distro to get nodejs installed. Also, we where able to drop a pile of bit-rotting Javascript files that we had to copy from nodejs' codebase just because no distro provided less.js so far. When node was removed it was compiling the less template at runtime, this is useful in development but not in production. Maybe it is possible to perform a dist task which will compile the less template for the package target. We discussed this on IRC and I'd say compiling static assets (such as CSS) during sdist / bdist can't really hurt. If we keep lesscpy we will have to maintain it every time less pre processor will upgrade, it is a lot of work in addition for few benefits. Currently, a review is waiting for the integration of bootstrap https://review.openstack.org/#/c/49710/ using lessc (node compiler). Where do you get these numbers? So far, fixing up Lesscpy wasn't such a big task. For bootstrap3 support, the only thing missing was variable support in CSS media queries. I already added some quick hacks to unblock people for the time being (See [0]). LESS the language doesn't change that much, it's CSS3 that adds a ton of new features. I need your reviews on this topic because a lot of work is currently done for the ui of Horizon and the integration of Bootstrap v3 is a huge bottleneck for further development. [0] https://github.com/robotis/Lesscpy/issues/22 -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] BootstrapV3 and lessc
On Monday 04 November 2013 13:49:20 Matthias Runge wrote: On 11/04/2013 11:41 AM, Sascha Peilicke wrote: On Monday 04 November 2013 10:52:21 Maxime Vidori wrote: Hi, I talked with Jiri Tomasek who is currently in charge of the integration of Bootstrap V3 into Horizon. The integration is currently stuck and was waiting for almost two month that lesscpy could parse the Bootstrap v3 less template. I know that Nodejs was removed because of some dependencies issues in production environment, but we do not need Node in production environment. We didn't had nodejs for a long time in fedora, because it used to bundle a lot of code from other projects. The other issue is, that is a quite fast moving project. When you want a stable platform, you probably don't want to update every two to four weeks to a newer minor-version, and probably want to avoid new major versions at all. So, it ended up in: we compiled LESS code offline and combined that with the package. That is not ideal at all for folks changing the style to give their dashboard another look. I assume, that's a pretty common situation. Just to give people an impression, this is a RPM spec file stripped of everything except the nodejs / offline compression parts: http://paste.opensuse.org/view/raw/8915603 (as seen in [0]) Of course you can bet that your usual consultancy-based PoC deployment won't care about such details o:-) Regardless of that, nodejs is a huge dependency of which not that many people have long experience with. While I know that nodejs is the new fancy of web development, things where radically different less than 2 years ago. It will the same in 2 years from now. That's why distros want to avoid it if they can. You simply don't know how reliable upstream is. What happens if they need to fix a security issue in that crappy old release that happens to be shipped in, say, openSUSE-12.2. Exactly, just compare the binary size with the size of less sourcecode in horizon sourcecode at all. So, that being said, dropping lesscss in favor of re-integrating node.js is a big step backwards. If there's something missing in lesscpy, we should fix that. Matthias [0] https://build.opensuse.org/package/view_file/Cloud:OpenStack:Grizzly/openstack-dashboard/openstack-dashboard.spec?expand=1 -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On 10/01/2013 03:45 PM, Thomas Goirand wrote: Hi, I have just found out that there's already a source package called trove in Debian: http://packages.debian.org/source/sid/trove Lucky, I don't think it will clash with OpenStack trove since it produces libtrove-java* .deb files, though that's quite annoying. The source package for OpenStack Trove will have to be called something like openstack-trove, which isn't nice. Since our ecosystem was already madly in love with codenames when the openSUSE people joined the fun, we went with the openstack-$BLA naming scheme right from the beginning :-) A long history of pain (speak clashes) made us do that for all kinds of things, thus we enforce prefixes like ruby-, python(3)-, go- and java- for whenever it makes sense. BTW. and while you're at it, the same holds true for daemon user names in /etc/passd, we've also had bug reports due to clashes there :-) Also, in PyPi, there is: https://pypi.python.org/pypi/TroveClient which would clash with python-troveclient. This pypi module was uploaded more than a year ago. Since I have already uploaded python-troveclient (currently waiting in the FTP master's NEW queue), OpenStack troveclient will be in Sid, but if some day, someone wants to upload TroveClient from http://dev.yourtrove.com, then we have a problem. So, I am really questioning the choice of Trove as a name for the DBaaS in OpenStack. I think it is a pretty bad move. :( Is it too late to fix this? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Python 3
Am 24. Juli 2013 18:00:30 schrieb Monty Taylor mord...@inaugust.com: On 07/23/2013 03:02 PM, Brian Curtin wrote: On Jul 23, 2013, at 3:51 PM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Tue, Jul 23, 2013 at 4:41 PM, Logan McNaughton lo...@bacoosta.com mailto:lo...@bacoosta.com wrote: I'm sure this has been asked before, but what exactly is the plan for Python 3 support? Is the plan to support 2 and 3 at the same time? I was looking around for a blue print or something but I can't seem to find anything. I suppose a wiki page is due. This was discussed at the last summit: https://etherpad.openstack.org/havana-python3 The plan is to support Python 2.6+ for the 2..x series and Python 3.3+. This effort has begun for libraries (oslo) and clients. Work is appreciated on the primary projects, but will ultimately become stalled if the library work is not first completed. I'd like to add that at some point in the future it is our desire to drop support for 2.6, as supporting 2.7 and 3.3+ is way easier than also supporting 2.6. At the moment, I believe our main factor on that is the current version of RHEL. Fingers crossed for a new one soon... :) Not to forget SLES ;-) We are also just finishing up getting 3.3 enabled build slaves in the CI gate, so as projects get 3.3 compliant, we should be able to start testing that. FWIW, I came across https://wiki.openstack.org/wiki/Python3Deps and updated routes, which currently works with 3.3. One small step, for free! I'm a newcomer to this list, but I'm a CPython core contributor and am working in Developer Relations at Rackspace, so supporting Python 3 is right up my alley. Excellent! Welcome, glad to have you. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 02:34 PM, Sascha Peilicke wrote: On 07/04/2013 12:03 PM, Matthias Runge wrote: On 04/07/13 11:27, Thomas Goirand wrote: Hi, Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? BTW. this is identical for openSUSE. How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). At least here, our horizon test package just doesn't depend on selenium. This could help: https://review.openstack.org/#/c/35649/ -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 03:55 PM, Daniel P. Berrange wrote: On Thu, Jul 04, 2013 at 09:34:01AM -0400, Julie Pichon wrote: Hi Sascha, Sascha Peilicke speili...@suse.com wrote: On 07/04/2013 02:34 PM, Sascha Peilicke wrote: On 07/04/2013 12:03 PM, Matthias Runge wrote: On 04/07/13 11:27, Thomas Goirand wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Thank you for the heads-up. Selenium is used for tests during development, it is not a runtime requirement at all. Would that still make it non-free for Debian? BTW. this is identical for openSUSE. How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). At least here, our horizon test package just doesn't depend on selenium. This could help: https://review.openstack.org/#/c/35649/ Could you explain why Selenium is considered to be non-free? Assuming you're referring to the 'python-selenum' package in Debian, Google throws up this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. This also matches our (as in openSUSE's) definition, python-selenium ships: /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/x86/x_ignore_nofocus.so /usr/lib/python2.7/site-packages/selenium/webdriver/firefox/webdriver.xpi While in theory they could be build from source, it's simply too much effort. Also, it depends on selenium (the Java thing) which to my knowledge isn't part of any OSS distro because building Java packages is the biggest PITA of all. Usually, such packages are available in 3rd-party repos. Still, we have to patch it away. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] python-selenium is non-free, Horizon shouldn't use it
On 07/04/2013 04:06 PM, Thomas Goirand wrote: On 07/04/2013 06:10 PM, Julien Danjou wrote: On Thu, Jul 04 2013, Julie Pichon wrote: Thomas Goirand z...@debian.org wrote: Horizon seems to use python-selenium. The problem is that, in Debian, this package is in the non-free repository. So I strongly suggest to not use it for Havana. That otherwise would put Horizon into the contrib repository of Debian (eg: not officially in Debian), or eventually, remove any possibility to run the unit tests, which isn't nice. Why is Selenium considered non-free? The code is Apache-licensed, including the Python bindings. FWIW only a few of the unit tests use Selenium (and those that do, need to), and they're not run by default unless you set a flag to do so. Yes, that seems like a mistake from the Debian packager as far as I can tell. There's nothing that requires it to be in non-free. (Cc'ing Sascha, the maintainer) Well, see this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 There are files not built from source. Also, when looking at the package, it seems that it isn't maintained as good as it deserves. #700061 was opened in 08 Feb 2013, and there's no answer at all from Sascha to this bug (which is RC). I am sorry, but I'm an openSUSE guy. But I can tell you we had similar bugs :-) https://bugzilla.novell.com/show_bug.cgi?id=755619 That well may have been the reason why this package was removed from testing on the 6th of march (according to the Debian pts). IMO, the maintainer should have at least answered to the bug. Anyway, what isn't explained in #636677, is what is non-free. So I had a look. To me, what is not built from source is what is in py/selenium/webdriver: there is a webdriver.xpi in the firefox folder. Though the maintainer should have write about it, so we don't have to double-guess (it should be clearly documented in debian/copyright). Which part of Selenium is in use in the unit testings of Horizon? Could we imagine that this part of the unit testing be made optional? Like for example, only if python-selenium is installed, or else the tests are gracefully skipped? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
