Re: [openstack-dev] BM provisioning through Horizon/CLI?
On Wed, Sep 10, 2014 at 05:53:57PM +, Lokare, Bageshree wrote: Hello OpenStack Team, I have a use case where I want to host/manage a mix environment with VM's and baremetal servers through Overcloud (Horizon/CLI). To be specific, I am looking for an ability to create a new server on baremetal machine (instead of Vm) through Horizon and manage the instance life-cycle through Overcloud agents. I am wondering can we do that with current Juno release? Any pointers on this implementation or proposed/prospective Blueprints would be really helpful. Very short answer: you can not. We're dreaming of that, but it's not developed that far (and might not be ready in Kilo). Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] devstack - horizon dashboard issues
On 21/09/14 22:55, Alex Leonhardt wrote:
Hi guys,
trying to get a devstack up and running, on a VM, but I keep getting this:
Error during template rendering
In
template
|/opt/stack/horizon/openstack_dashboard/templates/context_selection/_project_list.html|,
error at line *7*
Reverse for ''switch_tenants'' with arguments
'(u'ca0fd29936a649e59850d7bb8c17e44c',)' and keyword arguments
'{}' not found.
I'd say: please file a bug, if not already happened, and I couldn't find
it quickly.
Matthias
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
On 12/10/2013 09:24 PM, Lyle, David wrote: I would like to nominate Tatiana Mazur to Horizon Core. Tatiana has been a significant code contributor in the last two releases, understands the code base well and has been doing a significant number of reviews for the last to milestones. Additionally, I'd like to remove some inactive members of Horizon-core who have been inactive since the early Grizzly release at the latest. Devin Carlen Jake Dahn Jesse Andrews Joe Heck John Postlethwait Paul McMillan Todd Willey Tres Henry paul-tashima sleepsonthefloor +1 and +1. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Less compiler dependency
On 12/10/2013 06:06 PM, Thomas Goirand wrote: On 12/10/2013 11:41 PM, Jiri Tomasek wrote: On 12/09/2013 12:47 PM, Jaromir Coufal wrote: So I would like to ask everybody, if we can reconsider this dependency and find some other alternative. I know we moved from nodejs, because it is packaging nightmare. But honestly, better to invest more into packaging than being blocked months waiting for features we need to get in. I don't agree, because ... I'll be doing the work! :) More seriously, we are much better off NodeJS, and keep everything in Python. This is awesome, thank you! I totally agree, we're much better in supporting python packages. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Less compiler dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2013 07:04 PM, Jordan OMara wrote: I'm a bit newer to this conversation than some, but I'm not sure what exactly the NodeJS packaging nightmare is? Isn't it already packaged for many major distributions? I might speak for Fedora here. We had a long history in getting Node.js in. We have strict policies, what may be included and what is prohibited. - - bundling other libraries is forbidden - - static linking is forbidden For example node.js used to bundle httplib, libssl, and a few others as well. For a long time, it was nearly impossible to build it using dynamic linking. It introduces its own packaging system, thus doesn't update packages via the distribution repositories. Releases are quite often, even major releases. Introducing major releases of a software in a release cycle of a distribution is not wanted at all. More details are in the original package review https://bugzilla.redhat.com/show_bug.cgi?id=815018 Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSp4plAAoJEOnz8qQwcaIWFjQH/jFqEqTye52wRUXXxFmm2PUx TzptBQr96At1JBUFyIAmOIZhvQKD15EGBeuEExxI6A7l+eFeKanvLkWhdyBgaXxj G41mUz7RkGuFseyklped/gpfDrGY8h2xAwFwyo/eQoxz7hbmDIZNukXvc7LrS+t6 Irf4eVpv3XzP2mkhW7faLJWvYN4p+iy+vIhwpq7IZC5b9wnASXkasGRWZuq73wpQ kB5qfOyLiI/SMlhCpaWWsvjf2UXNzl8os0c1bGSagwJRkwoG3kUcZ2f7XtBzKs4m n+rakAdxUKCu76r/8QNAQACmDDNiLNLzJxdN8NPaC1nz8MRFFbM5HA1XSJOUM7I= =KjEZ -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Gating-Failures] Docs creation is failing
On 12/11/2013 08:22 AM, Gary Kotton wrote: Hi, An example for this is: http://logs.openstack.org/94/59994/10/check/gate-nova-docs/b0f3910/console.html Any ideas? Thanks Gary There is a thread about this: http://lists.openstack.org/pipermail/openstack-dev/2013-December/021863.html Best regards, Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/13/2013 03:08 PM, Ladislav Smola wrote: Horizoners, As discussed in TripleO and Horizon meetings, we are proposing to move Tuskar UI under the Horizon umbrella. Since we are building our UI solution on top of Horizon, we think this is a good fit. It will allow us to get feedback and reviews from the appropriate group of developers. I don't think, we really disagree here. My main concern would be more: what do we get, if we make up another project under the umbrella of horizon? I mean, what does that mean at all? My proposal would be, to send patches directly to horizon. As discussed in last weeks horizon meeting, tuskar UI would become integrated in Horizon, but disabled by default. This would enable a faster integration in Horizon and would reduce the overhead of creating a separate repositoy, installation instructions, packaging etc. etc. From the horizon side: we would get some new contributors (and hopefully reviewers), which is very much appreciated. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/16/2013 04:22 PM, Jiri Tomasek wrote: Thanks for pointing this out, In Horizon you can easily decide which dashboards to show, so the Infrastructure management Horizon instance can have Project and Admin dashboards disabled. I think there has been discussed that some panels of Admin dashboard should be required for infrastructure management. We can solve this by adding those selected Admin panels also into Infrastructure dashboard. Jirka Oh, I would expect a new role for an infrastructure admin; that role shouldn't necessarily see running instances or tenants etc. at all. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Horizon] [Tuskar] [UI] Horizon and Tuskar-UI merge
On 12/17/2013 09:04 AM, Thomas Goirand wrote: I think the disabled by default approach is the wrong one. Instead, we should have some users with enough credentials that will have the feature, and others will not. Also, Horizon is a web interface. Most of its switches could be made directly in the web interface, with the values stored in a db. That'd be so much nicer than stored in localsettings.py which starts, as time passes, to become overly complicated and ugly (it should, by the way, be a configuration file, not a python script: you can't expect administrators to understand python, but you do expect them to understand how to write in a .ini file). Also, it seems we have a consensus, when is it expected to happen? For Icehouse b2 maybe? Just my 2 cents, The issue is, that you can not do anything with it, when it's not configured. The other thing: When you're up to try it, you need quite a few machines (to install OpenStack on them) etc. Thus I think, disabled by default is the best way to not to confuse people, since you now need to know, what you're doing. We might/should rethink this decision in the future. The other suggestion (totally unrelated to Tuskar) you had was: to store config data in a database instead of a (python) config file. Currently, Horizon does not require a database, and I'd love to keep it that way. There are currently two configs to be changed once, when configuring the Dashboard: ALLOWED_HOSTS and OPENSTACK_HOST. The first is to configure the host to run on, the other points to keystone. This gets you up and running. We're inheriting config file handling from Django, and this consists on parsing python files. But, if you look at https://github.com/openstack/horizon/tree/master/openstack_dashboard/local/enabled you'll see a more .ini-file approach, probably more like you were thinking. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Tuskar-UI codebase merge
On 12/18/2013 10:33 PM, Gabriel Hurley wrote: Adding developers to Horizon Core just for the purpose of reviewing an incubated umbrella project is not the right way to do things at all. If my proposal of two separate groups having the +2 power in Gerrit isn't technically feasible then a new group should be created for management of umbrella projects. Yes, I totally agree. Having two separate projects with separate cores should be possible under the umbrella of a program. Tuskar differs somewhat from other projects to be included in horizon, because other projects contributed a view on their specific feature. Tuskar provides an additional dashboard and is talking with several apis below. It's a something like a separate dashboard to be merged here. When having both under the horizon program umbrella, my concern is, that both projects wouldn't be coupled so tight, as I would like it. Esp. I'd love to see an automatic merge of horizon commits to a (combined) tuskar and horizon repository, thus making sure, tuskar will work in a fresh (updated) horizon environment. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Support for Django 1.6
On 12/19/2013 04:45 PM, Thomas Goirand wrote: Hi, Sid has Django 1.6. Is it planned to add support for it? I currently don't know what to do with the Horizon package, as it's currently broken... :( Thomas Yes, there are two patches available, one for horizon[1] and one for django_openstack_auth[2] If both are in, we can start gating on django-1.6 as well. [1] https://review.openstack.org/#/c/58947/ [2] https://review.openstack.org/#/c/58561/ Matthias ___ 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
On 12/30/2013 08:31 AM, Thomas Goirand wrote: 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...)? AFAIK, horizon is the only project under the OpneStack umbrella using django. In horizons requirements.txt, django-bootstrap-form is missing. Djangp-bootstrap-form was added to global requirements by[1], but is seems it's not used at all, so I propose to remove it. Matthias [1] https://github.com/openstack/requirements/commit/46a6f06326895b7293cfc0714acce25e1e3d6159 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Novnc switch to sockjs-client instead of websockify
On 01/01/2014 07:33 AM, Thomas Goirand wrote: Hi, I was wondering if it would be possible for NoVNC to switch from websockify to sockjs-client, which is available here: https://github.com/sockjs/sockjs-client This has the advantage of not using flash at all (pure javascript), and continuing to work on all browsers, with a much cleaner licensing. Looks good to me and good catch here! That would be an awesome improvement. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript checkstyle improvement
On 12/27/2013 03:52 PM, Maxime Vidori wrote: Hi all, I send this mail to talk about Javascript coding style improvement, like python has pep8, it could be interesting to have some rules for javascript too. JSHint provides some rules to perform this and I think it could be a great idea to discuss about which rules could be integrated into Horizon. According to http://www.jshint.com/docs/options/ here is a list of the rules which seems interesting: - bitwise - curly - eqeqeq - forin - latedef - noempty - undef - unused with vars - trailing Here is a second list of options which can be integrated but need some discussion before: - camelcase - quotmark I already made a first patch for the indentation: https://review.openstack.org/#/c/64272/ Thank you for driving this further! I see pros and cons here. First of all, I really like style improvements and unification of code and style. But: We're bundling foreign code (which is bad in general); now we need to change/format that code too, to match our style conventions? That would even generate a fork, like here[1], where the changes were just cosmetics. A patch like[2] this one shouldn't pass any more, although it's code like distributed by upstream. From a users standpoint there is nothing wrong with [2]. It would be ideal to remove bundled code at all and to add an external dependency. Matthias [1] https://review.openstack.org/#/c/64272/5/horizon/static/horizon/js/angular/controllers/dummy.js [2] https://review.openstack.org/#/c/64760/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript checkstyle improvement
On 01/03/2014 09:37 AM, Radomir Dopieralski wrote: [snip] This is actually not a problem at all, because the way jshint works now, we have to explicitly list the files to be checked against those rules. That means, that we can only check our own code, and not the included libraries. Of course, the reviewers have to pay attention to make sure that all the non-library code is added to the list, but we don't really get new files that often. Yeah, jshint needs to be switched on explicitly for each file. That tends to be forgotten on new files, which is not ideal either. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Meeting time congestion
On 01/13/2014 09:33 PM, Lyle, David wrote: With all the warranted meeting time shuffling that has been happening recently, and the addition of so many projects and sub-teams, the meeting calendar for #openstack-meeting and #openstack-meeting-alt [1] is relatively full. So recently, when trying to move the Horizon meeting time, the poll determined slot is unavailable. Should we run logged meetings from individual team rooms like #openstack-horizon? The advantage is it's available. The downside is that less people from other team linger in #openstack-horizon than #openstack-meeting. Should another meeting room be added? This solution only scales so far. Yes, if we have anything in masses, then it should be meeting rooms on IRC. The only issue I could see here is: if folks want to participate, and meetings times overlap, they will have divide their attention. I'd vote for adding another meeting room! Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Live migration
On Mon, Feb 24, 2014 at 06:08:56PM -0800, Dmitry Borodaenko wrote: Dear Horizon developers, I think that the blueprint to add live migrations support to Horizon[0] was incorrectly labeled as a duplicate of the earlier migrate-instance blueprint[1]. [0] https://blueprints.launchpad.net/horizon/+spec/live-migration [1] https://blueprints.launchpad.net/horizon/+spec/migrate-instance I think, your [0] is a duplicate of [2], which was impleented during icehouse. Matthias [2] https://blueprints.launchpad.net/horizon/+spec/live-migration-support -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Mar 05, 2014 at 10:36:22PM +, Lyle, David wrote: I'd like to nominate Radomir Dopieralski to Horizon Core. I find his reviews very insightful and more importantly have come to rely on their quality. He has contributed to several areas in Horizon and he understands the code base well. Radomir is also very active in tuskar-ui both contributing and reviewing. +1 from me, I fully support this. Radomir has done a impressive job and his reviews and contributions have been good since he started. Matthias - -- Matthias Runge mru...@redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTGXu6AAoJEOnz8qQwcaIWoesH/0pP7daAV2xqynR4zmkQ5QnU 7xcXKWQES/3C0+4YPF4GROvqyRsRtviOnPSkKDDE7W1+6lrZ3/Zc5axqrN5SWkjf V1lmNzriHgAOqo9CyXT0JtrrzkILcQ9sFyuGYaHg1iEpa8D6oXC2bwOOWkwGXBXZ 0lr74B76z46XxR6iHx9WSja02SvySZshIlnf9bJQZtBMDcf1zQq0tPEPLSvkPfeN fNLVWj2+PCS4Z6ww8/a4D09fnxf31a2ziG0Anl8aiSj6KuQSlG+FOGv1WfcgLySB Pz1MsFvj5J7pF2AYcD2uXGQaWL3DSY6XnFDPcYJ+5KwdjMySJVQiXXG1jTo0wZE= =aUPs -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] horizon PyPi distribution missing
On Thu, Mar 13, 2014 at 01:10:06PM +0400, Timur Sufiev wrote: Recently I've discovered (and it was really surprising for me) that horizon package isn't published on PyPi (see http://paste.openstack.org/show/73348/). The reason why I needed to install horizon this way is that it is desirable for muranodashboard unittests to have horizon in the test environment (and it currently seems not possible). I'd expect this to change, when horizon and OpenStack Dashboard are finally separated. I agree, it makes sense to have something comparable to the package now called horizon on PyPi. https://blueprints.launchpad.net/horizon/+spec/separate-horizon-from-dashboard -- Matthias Runge mru...@redhat.com ___ 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)
On Fri, Mar 14, 2014 at 01:03:26PM +0100, Sascha Peilicke wrote:
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.
An additional note:
I was very astonished to see that now included in Fedora; it looks like
it was sufficient to remove the pre-compiled blob
%install
%{__python2} setup.py install --skip-build --root %{buildroot}
rm -f
%{buildroot}%{python2_sitelib}/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so
rm -f
%{buildroot}%{python2_sitelib}/selenium/webdriver/firefox/x86/x_ignore_nofocus.so
%if %{with python3}
pushd %{py3dir}
%{__python3} setup.py install --skip-build --root %{buildroot}
popd
rm -f
%{buildroot}%{python3_sitelib}/selenium/webdriver/firefox/amd64/x_ignore_nofocus.so
rm -f
%{buildroot}%{python3_sitelib}/selenium/webdriver/firefox/x86/x_ignore_nofocus.so
%endif
(the review request is here: [1])
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1070125
Matthias
--
Matthias Runge mru...@redhat.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Cannot login to dashboard
On Mon, Mar 31, 2014 at 08:07:12AM +0400, Andrew Chul wrote: Well, I've used this quickstart guide http://docs.openstack.org/developer/horizon/quickstart.html Is it necessary to set up DevStack anyway? No, absolutely not. You can use your OpenStack installation, check out horizon from github and use the django devserver for development. You need to copy openstack_dashboard/local/local_settings.py.example to openstack_dashboard/local/local_settings.py and may need to modify it. Esp. you need to modify the OPENSTACK_HOST setting to point to your keystone host. Using the developement server, you'll directly see, what error happened. Often, it helps to set DEBUG = True (in settings.py or in local_settings.py). HTH, Matthias -- Matthias Runge mru...@redhat.com ___ 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 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. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/10/2013 11:45 PM, Dolph Mathews wrote: On Fri, Nov 8, 2013 at 2:38 AM, Matthias Runge mru...@redhat.com mailto:mru...@redhat.com wrote: Those are my primary targets I'd like to see addressed in Horizon during the cycle. Another thing I'd like to see addressed is the lack of listening to a notification service. That's probably an integration point with Marconi, and it might be possible, this won't make it until Icehouse. This bit caught me off guard - what's the use case here? Is there a link to a blueprint? Thanks! E.g when launching an instance, currently, Horizon is repeatedly pulling nova for a status. The same is true for cinder, when building images etc. There is at least one blueprint for this: https://blueprints.launchpad.net/horizon/+spec/realtime-communication but it doesn't use Marconi, but an own solution. Since we'll have marconi available sooner or later, it makes sense to have it there. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/10/2013 11:53 PM, John Dickinson wrote: A random off-the-top-of-my-head use case would be to subscribe to events from creating or changing objects in a particular Swift account or container. This would allow much more efficient listings in Horizon for active containers (and may also be consumed by other listeners too). --John yupp. There are many many usecases for this, and we'd get rid of pulling services for status. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Request for review
On 11/09/2013 11:45 AM, Michael Bright wrote: Could someone review this please, it's a small patch but has taken a while ... https://review.openstack.org/#/c/51263/ It would be very helpful, if you'd mention the project (in this case nova), in the subject line. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon PTL candidacy
On 11/12/2013 12:09 PM, Eoghan Glynn wrote: Sounds reasonable, but just one caveat ... Notifications can either be disabled in the service config (e.g. by setting the notifier_strategy to noop in the glance config) or mis-configured (e.g. by not overriding control_exchange name in the cinder code) such that the notifications are not seen by the consumer. We have a similar potential problem with ceilometer, and no good way currently of detecting the non-flow of notifications, i.e. the old story that the absence of evidence evidence of absence. I'm not sure whether if it would be workable for horizon to detect whether notifications are flowing for each service by probing in some way (e.g. by setting unsetting a random property on an image and then ensuring that the corresponding image.update events are seen). If the absence of notifications were easily reliably detectable, then obviously horizon could simply fallback to polling. Anyhoo, just some food for thought. Thank you for your input here. That is true, we'd rely on an additional service, whether marconi or some oslo service doesn't matter in first place here. The service may not be accessible or even not reliable; we might miss messages, and simply trusting in getting messages in the right order etc. is probably not a stable approach here. A fallback to pulling again is definitely an option. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] PTL election
On 11/19/2013 11:02 PM, Thierry Carrez wrote: The poll is now closed, and the winner is David Lyle ! David, well done and honestly deserved! Matthias ___ 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 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. 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
Re: [openstack-dev] [horizon] Javascript development improvement
On 11/22/2013 11:10 AM, Maxime Vidori wrote: I will start reading documentation in order to integrate node in development, we also want to integrate its testing into the existing ones. I think a blueprint will be necessary. Since it was such a pain to get rid of nodejs, I'd love to see other options here. Matthias ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2013 02:19 PM, Sascha Peilicke wrote: 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 :-) AFAIK it is packaged already. I was not speaking about lesscpy (which might raised your attention here), but about less compiler in general (or other tools, probably useful for maintainers/customizers tasks). Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSj2qnAAoJEOnz8qQwcaIWeZcH/jC7RUTUPD+fa9lG92YmYuoU XiG9xivEVtOrhHlqigb43A6rGVkq7IPEVCnf3nMCwxtVHcoLdy3Pq8QPqFEI9LNv GrjfoKoFy8R71AuAWVblTWgMxJ/4ffHDny4na4FDiqn02vMCucYvsPAKsNU6m3fU SaFC1pH0f7/LeVpa13IJuM7XlEKpbPNwKObFfxalIen9ISP+9iQeWlczAr96Z198 tjdPg+2CeXM4Dh+jklYjOQHB5ITxFI3U4ehXCDB+aJS5HnGulL4gF1120zsBScG7 fsTI67n+r0mhMo9rIQdVVJFmK/wpHXzKQi8bsBJctk+hJ1UG9sHNjRJVmmq9SWY= =7B9B -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
On 11/27/2013 06:46 PM, Alan Pevec wrote: 2013/11/27 Sean Dague s...@dague.net: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. Right, hence glance was added https://review.openstack.org/55998 to unblock the previous gate failure. Issue now is that stable/grizzly Tempest uses clients from git trunk, which is not going to work since trunk will add more and more incompatible dependencies, even if backward compatbility is preserved against the old service APIs! Solutions could be that Tempest installs clients into separate venv to avoid dependecy conflicts or establish stable/* branches for clients[1] which are created around OpenStack release time. I'd like to propose to switch testing for stable branches: We should switch to install environments for stable releases through other methods, such as packages. There are quite a few provisioning methods out there right now. The benefit would be, we'd have a very reproducible way to build identical environments for each run; the cost would be, that we'd need to create a test environment for each project: install everything but the project to test via packages. When choosing packages to install: which one do we want to take? Just a single source or take for each (major) distribution, thus multiplying effort here? Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Quick Survey: Horizon Mid-Cycle Meetup
On Wed, Jun 18, 2014 at 10:55:59AM +0200, Jaromir Coufal wrote: My quick questions are: * Who would be interested (and able) to get to the meeting? * What topics do we want to discuss? https://etherpad.openstack.org/p/horizon-juno-meetup Thanks for bringing this up! Do we really have items to discuss, where it needs a meeting in person? Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
On Fri, Jun 20, 2014 at 09:17:41PM +, Lyle, David wrote: I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core. Zhenguo has been a prolific reviewer for the past two releases providing high quality reviews. And providing a significant number of patches over the past three releases. Ana has been a significant reviewer in the Icehouse and Juno release cycles. She has also contributed several patches in this timeframe to both Horizon and tuskar-ui. Please feel free to respond in public or private your support or any concerns. Thank you! +1 for both! Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] request to tag novaclient 2.18.0
On 11/07/14 02:04, Michael Still wrote: Sorry for the delay here. This email got lost in my inbox while I was travelling. This release is now tagged. Additionally, I have created a milestone for this release in launchpad, which is the keystone process for client releases. This means that users of launchpad can now see what release a given bug was fixed in, and improves our general launchpad bug hygiene. However, because we haven't done this before, this first release is a bit bigger than it should me. I'm having some pain marking the milestone as released in launchpad, but I am arguing with launchpad about that now. Michael Cough, this broke horizon stable and master; heat stable is affected as well. For Horizon, I filed bug https://bugs.launchpad.net/horizon/+bug/1340596 Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Overrides to register/deregister panels and Menu Placements
On 14/07/14 08:48, Rahul Sharma wrote: Can someone please help me with the API’s required to add a menu item and add my panels under those. Also I am pasting snippet of my code, please let me know if there is a better way to fix this. Please note that at this moment I cannot modify base Horizon code. I am based of Havana. Snippet for Menu/Panel registrations: Please migrate ASAP to master branch. New features and bug fixes are introduced on master only; if applicable, it's possible to backport fixes to older branches. During Icehouse development cycle, Horizon got the ability to work with additional python modules, which get pulled in via that plugin mechanism. Further details can be found in openstack_dashboard/enabled/.. Esp. there is already the router dashboard as example. Best, Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] help
On 31/07/14 12:39, shailendra acharya wrote: plz give responce i m stuck On Thu, Jul 31, 2014 at 3:59 PM, shailendra acharya acharyashailend...@gmail.com mailto:acharyashailend...@gmail.com wrote: Please keep in mind, this list is a development list, not intended for end user questions. The correct one would be: openst...@lists.openstack.org available via: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack You might be asked such questions like: which guide did you follow or which installation method did you chose. You don't need to resend your mail every 10 mins. Thanks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS
On 06/08/14 14:01, Timur Sufiev wrote: Hi! Here is the link: http://koji.fedoraproject.org/koji/rpminfo?rpmID=5239113 The question is whether the python-pillow package really needed for proper compiling css from scss in Horizon or is it an optional requirement which can be safely dropped? The problem with python-pillow is that it pulls a lot of unneeded deps (like tk, qt, etc...) which is better avoided. If you're looking at the spec[1], you'd see it's a test requirement, not a runtime requirement. Matthias [1] http://pkgs.fedoraproject.org/cgit/python-django-pyscss.git/tree/python-django-pyscss.spec ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Package python-django-pyscss dependencies on CentOS
On 07/08/14 11:11, Timur Sufiev wrote: Thanks, now it is clear that this requirement can be safely dropped. As I said, it's required during build time, if you execute the tests during build. It's not a runtime dependency; the page you were referring to is from the build system. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Static file handling -- followup
On Tue, May 20, 2014 at 05:18:18PM +0200, Radomir Dopieralski wrote: Hello, this is a followup on the design session we had at the meeting about the handling of static files. You can see the etherpad from that session here: https://etherpad.openstack.org/p/juno-summit-horizon-static-files The JavaScript libraries unbundling: I'm packaging all the missing libraries, except for Angular.js, as XStatic packages: https://pypi.python.org/pypi/XStatic-D3 https://pypi.python.org/pypi/XStatic-Hogan https://pypi.python.org/pypi/XStatic-JSEncrypt https://pypi.python.org/pypi/XStatic-QUnit https://pypi.python.org/pypi/XStatic-Rickshaw https://pypi.python.org/pypi/XStatic-Spin There is also a patch for unbundling JQuery: https://review.openstack.org/#/c/82516/ And the corresponding global requirements for it: https://review.openstack.org/#/c/94337/ Awesome, thank you! Looking at the change, that includes a not so ancient version of jquery, but IMHO it's better to upgrade that to a more up-to-date version as step -1? That might be solved by adding jquery-migrate as well; the sanest solution would be to fix our JavaScript code. The style files compilation: We are going to go with PySCSS compiler, plus django-pyscss. The proof-of-concept patch has been rebased and updated, and is waiting for your reviews: https://review.openstack.org/#/c/90371/ It is also waiting for adding the needed libraries to the global requirements: https://review.openstack.org/#/c/94376/ Karma added as well. Thank you for driving this effort! It's really worth it. -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Selenium test fixes
On Wed, May 28, 2014 at 03:45:18PM +1000, Kieran Spear wrote: No failures in the last 24 hours. \o/ Thank you for looking into this (and apparently fixing it)! -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon][infra] Plan for the splitting of Horizon into two repositories
On Sat, May 31, 2014 at 09:13:35PM +, Jeremy Stanley wrote: I'll admit that my Web development expertise is probably almost 20 years stale at this point, so forgive me if this is a silly question: what is the reasoning against working with the upstreams who do not yet distribute needed Javascript library packages to help them participate in the distribution channels you need? This strikes me as similar to forking a Python library which doesn't publish to PyPI, just so you can publish it to PyPI. When some of these dependencies begin to publish xstatic packages themselves, do the equivalent repositories in Gerrit get decommissioned at that point? we need those libraries installable or provided as a python package. Using xstatic solves this for us in a very nice way. I must admit, I'd prefer those (javascript) libraries installable as (rpm) packages, but that makes it even more complicated e.g gate. It seems, many folks here try to avoid distro packages at all. -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Use of AngularJS
On Tue, Jun 03, 2014 at 07:49:04AM +0200, Radomir Dopieralski wrote: On 06/02/2014 05:13 PM, Adam Nelson wrote: I think that you would use the PyPI version anyway: https://pypi.python.org/pypi/django-angular/0.7.2 That's how most of the other Python dependencies work, even in the distribution packages. That is not true. As all components of OpenStack, Horizon has to be packaged at the end of the cycle, with all of its dependencies. I already packaged python-django-angular for Fedora (and EPEL), it's just waiting for review [1]. From a distro standpoint, every dependency needs to be packaged, and this is not limited to Horizon dependencies as well. On the other side, we don't break each time, when someone releases a new setuptools or keystoneclient to pypi. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1099473 -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Use of AngularJS
On Tue, Jun 03, 2014 at 05:14:16PM +, Musso, Veronica A wrote: Great, thanks Matthias! Then, if django-angular is approved for Fedora, do we need to wait for Ubuntu packages? Or can it be used? Thanks! Veronica I can not speak for other distributions. My 2ct here: you'd need a package, when a release is being made. If your favourite distro provides e.g packages for each snapshot, you'd need a package around June 12th. This is for django-angular not different to any other dependency. So: I'd say: we don't need to wait here with a implementation for any distribution. -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] request to review bug 1301359
On Wed, Jun 04, 2014 at 04:13:33PM +0530, Harshada Kakad wrote: HI Matthias Runge, Which feature in trove are you talking about? And even which capabilities are missing which will make the patch fail? I believe the patch has nothing to do with https://review.openstack.org/#/c/83503/ If your patch relies on a not approved feature of a client, and we'd do a full integration testing with Horizon, your patch would fail, because the underlying client does not have the required feature. Does that make sense? -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [I18N] compiling translation message catalogs
On 06/10/14 13:35, Ihar Hrachyshka wrote: I was pointed (kudos to Alan Pevec) to the following update for RDO spec file [1] that makes it regenerate MO files from source for Juno. So for RDO, it's already handled the way we will probably go forward. [1]: http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/commit/?id=e756a1d0e401707d6d386516eef5c2af8ed5e138 obviously, I'm for (a). When distros need to patch translation messages for whatever reason, they need to regenerate mo files anyways. In most distributions, use of pre-compiled binaries is forbidden by policy. When seeing it very strict, that might apply to message object files as well. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Separate horizon and openstack_dashboard
Hi, tl;dr: how to progreed in separating horizon and openstack_dashboard About a year ago now we agreed, it makes sense to separate horizon and openstack_dashboard. Thanks to Radomirs work in unbundling JavaScript libraries, we're finally there. It was decided to rename horizon to horizon_lib[1], and to rename openstack_dashboard to horizon. Now following[2]: The split: == code freeze -- no patches merged, except for the ones mentioned here, - rename horizon to horizon_lib, fix all corresponding imports, - rename openstack_dashboard to horizon, fix all corresponding imports, - clone the horizon repository using git-filter to skip the dashboard files, create an external repository on github for that, - add new project to openstack-infra/config called horizon_lib, with the new repo as the upstream, setup CI for the new project, - verify that the new repository works correctly, - remove the horizon_lib files from the old repository in one big commit, end of code freeze I tried that in [3], [4]. I renamed openstack_dashboard to openstack_horizon, rather than horizon to be sure, I really catched all imports etc., and to make sure, it's clear, what component is meant. During this process, the name horizon is a bit ambiguous. It was a somehow larger rework, just search and replace didn't do the job here, and I'm quite confident to have left one or the other thing untouched. There were quite a few additional code changes necessary, mostly due flake8 tests (renamed names are longer, breaking line length, horizon_lib and horizon are now separate, imports must be separated) So, how do we proceed from here? - how do we block the gate - how to create a new repo - how to set up ci for the new project? - how to integrate new horizon_lib and horizon (or openstack-horizon) to devstack Matthias [1] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037996.html [2] https://etherpad.openstack.org/p/horizon-split-plan [3] https://github.com/mrunge/openstack_horizon [4] https://github.com/mrunge/horizon_lib ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
On 01/11/14 14:13, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. Unfortunately, this is at the same time as Ceilometer, Glance, Heat, Horizon, Keystone, Neutron, Nova, TripleO, Ironic contributors meetup. I could imagine, some folks, (like me) are wearing more than one hat and will have to decide. Could we discuss the time? There might be time slots better suited for this. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On Thu, Oct 30, 2014 at 01:13:48PM +0100, Matthias Runge wrote: Hi, tl;dr: how to progreed in separating horizon and openstack_dashboard About a year ago now we agreed, it makes sense to separate horizon and openstack_dashboard. At the past summit, we discussed this again. Currently, our repo contains two directories: horizon and openstack_dashboard, they both will need new names. We discussed a renaming in the past; the former consensus was: rename horizon to horizon_lib and rename openstack_dashboard to horizon. IMHO that doesn't make any sense and will confuse people a lot. I wouldn't object to rename horizon to horizon_lib, although any other name, e.g django-horizon should be fine as well. openstack_dashboard is our official name; people from outside refer to the Dashboard as Horizon, why not rename to openstack_horizon here? Thoughts? Opinions? Suggestions? -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On 10/11/14 14:20, Tzu-Mainn Chen wrote: How about 'horizon_dashboard'? I think pairing that with 'horizon_lib' would make the purpose of each very clear. Wouldn't that imply, there exists an openstack_dashboard as well? Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
On 10/11/14 20:27, Samuel Merritt wrote: Swift has an elegant* solution** to this problem that makes PBR into a build-time-only dependency. Take a look at the top-level __init__.py in the Swift source tree: https://github.com/openstack/swift/blob/709187b54ff2e9b81ac53977d4283523ce16af38/swift/__init__.py For Horizon, there is a patch: https://review.openstack.org/#/c/92814/ to go the same route as swift. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] proposal: alternating weekly meeting time
On 11/11/14 08:09, Richard Jones wrote: Hi all, At the summit meetup last week I proposed that the Horizon weekly meeting time alternate between the current time and something more suitable for those of us closer to UTC+10. I'd like to get an indication of the interest in this, and I'll look into getting a second meeting time booked for alternating weeks based on your feedback. As a starting point, I'd like to suggest the times alternate between UTC and 1600 (the current time). Sadly, both times don't work for me. I would propose something like 8 UTC, which should work for most folks located in EU and east, or 18 UTC. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 11/11/14 10:53, Jiri Tomasek wrote: Hey, Thanks for writing this up! The Storyboard project has successfully integrated these tools into the OpenStack CI environment. OpenStack CI and distributors are different, because OpenStack CI does not distribute software. Using javascript tooling (yeoman, grunt, bower, etc.) has this issue of being dependent on nodejs which if I recall correctly is causing problems for packagers as some versions of these tools require different nodejs versions - please Mathias correct me if I am wrong. I know this discussion has been here before, but using these tools is necessary for effective development. So we need to resolve the problem asap. Storyboard does not have this issue as it is infra thing. As far as I know, those tools don't require different nodejs versions. But: we can not have different node.js versions installed at the same time. I assume, this is true for all distributions. Creating and maintaining parallel installable versions just sucks and causes many issues. In the past, customers wanted the complete tool-chain to modify their version of dashboard. I understand, this is not an issue, for all companies not distributing software, but directly providing services based on that software. I will have to go through all dependencies and do a review, if those are acceptable for inclusion e.g in Fedora. The same is true for Thomas Goirand for inclusion in Debian. Petr Belanyi has added optional jshint install for js linting into Horizon and it installs nodejs as it depends on it. Could this approach work for our need of js tooling too? [1] Sigh, this nonsense doesn't go away? This is the third time the same issue comes up. jshint is NOT free software. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 12/11/14 08:40, Richard Jones wrote: I believe the nodeenv method of installing node solves this, as it's entirely local to the development environment. See below, this touches package build as well. I will have to go through all dependencies and do a review, if those are acceptable for inclusion e.g in Fedora. The same is true for Thomas Goirand for inclusion in Debian. Petr Belanyi has added optional jshint install for js linting into Horizon and it installs nodejs as it depends on it. Could this approach work for our need of js tooling too? [1] Sigh, this nonsense doesn't go away? This is the third time the same issue comes up. jshint is NOT free software. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 They're trying to resolve that https://github.com/jshint/jshint/issues/1234 But regardless, jshint doesn't have to be installed from a Linux repository; it's usually installed using npm alongside the other node tools. Thanks for the pointer, this is good news! Regarding package managers, my POV is completely different. From a distributor perspective, where customers expect everything provided from a single source, I'm not using npm, pip etc. I'm packaging that stuff properly before using it. There are companies out there, where security policy does not allow to install software from a third party repository. pypi etc. are considered as a third party here in this context. I would prefer to have the complete tool chain available as (RPM) packages. I am executing unit tests etc. during package build. Our builders don't have access to the internet, downloading any other stuff from the internet is no option. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 11/11/14 08:02, Richard Jones wrote: There were some discussions around tooling. We're using xstatic to manage 3rd party components, but there's a lot missing from that environment. I hesitate to add supporting xstatic components on to the already large pile of work we have to do, so would recommend we switch to managing those components with bower instead. For reference the list of 3rd party components I used in angboard* (which is really only a teensy fraction of the total application we'd end up with, so this components list is probably reduced): json3 es5-shim angular angular-route angular-cookies angular-animate angular-sanitize angular-smart-table angular-local-storage angular-bootstrap angular-translate font-awesome boot underscore ng-websocket Just looking at PyPI, it looks like only a few of those are in xstatic, and those are out of date. Richard, thank you for writing this up! bower is (not yet) available e.g in Fedora, Debian, Ubuntu. I'm quite a bit skeptical why the need for 3 additional package managers (npm, grunt, bower) for simply installing javascript files. Looking at es5-shim, it pulls in additional 28 dependent packages, json3 has 12 dependencies (including a circular dependency, one circular depencency in dependencies), Not counting dependencies in dependent packages, I can only suspect, this will bring us at least 100 new packages required. Once this is finalized, we'll need people to walk through all deps and put packages up for review, to have those available when kilo is ready. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 12/11/14 09:28, Matthias Runge wrote: Looking at es5-shim, it pulls in additional 28 dependent packages, json3 has 12 dependencies (including a circular dependency, one circular depencency in dependencies), Please scratch that. I'll need to look at that a bit deeper (after another coffee) Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On Wed, Nov 12, 2014 at 08:31:08AM -0500, Monty Taylor wrote: jshint is NOT free software. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 Reasonable people disagree on this point. I, for one, am one of them. In my opnion: A usage clause in a license header is bonghits and unenforcable, as copyright terms cover the legality of copying things, not how you use them. For those terms to be enforcable, it would need to be a EULA, which jshint does not have. However, other people disagree with me, which is their prerogative. I'm mainly suggesting that it's probably not nonsense, it's a disagreement, and it's also probably not going to go away, since jshint is far and away the most common javascript linting tool in existence. Maybe some of the people who are vehemently opposed to the clause in the license header should figure out an alternative. Nice try ;-) Then I'd propose to use (any commercial software within OpenStack like Oracle or IBM DB2) and now it's your turn to come up with an acceptable alternative ;-) You're suggesting to use non-free software in an Open Source project. I see your point here, and that may be acceptable e.g for creating graphics (a one time job). IMHO we should try to get a full free software toolchain. We don't need to discuss, wether we need a tool like a javascript linter. But: As someone providing a public cloud you're in a clearly different position than e.g Red Hat is. We're distributing software and providing service for it. Nobody will know, if you're using software, which you aren't allowed to distribute. The situation for us is different. Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On Wed, Nov 12, 2014 at 08:35:18AM -0500, Monty Taylor wrote:
Just for the record, I believe that we should chose the tools that make
sense for making our software, as long as it's not physically impossible
for them to be packaged. This means we should absolutely not use things
that require multiple versions of node to be needed. The nodejs that's
in trusty is new enough to work with all of the modern javascript tool
chain things needed for this, so other than the various javascript tools
and libraries not being packaged in the distros yet, it should be fine.
Agreed. We're in the position to describe or define, what we'd like to
use or to see in the future. That may require us to create required
tools.
You're not concerned about node.js? Most probably, since you're not
distributing it. Looking at the changelog, I'm a bit worried[1]:
- 2014.10.20: openssl (addressing multiple CVEs)
- 2014.09.16: v8: fix a crash introduced by previous release
- 2014.08.19: v8: backport CVE-2013-6668 (they shouldn't bundle v8 at
all)
- 2014.06.05: openssl: to 1.0.1h (CVE-2014-0224)
- 2013.12.18: v8: backport fix for CVE-2013-{6639|6640}
etc., etc. This leads immediately to two questions: Why is openssl
bundled there? Why is v8 bundled there? It's not about flaws in
implementation of software, it's more about bad design.
Since we don't require node.js on the server (yet), but only for
the development process: did anyone look at node's competitors? Like
CommonJS, Rhino, or SpiderMonkey?
[1] http://nodejs.org/changelog.html
--
Matthias Runge mru...@redhat.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 12/11/14 18:23, Jiri Tomasek wrote: I see relation between Nodejs and js libs/tools and Angular app defining it's dependencies using NPM and Bower quite similar as Ruby, Rubygems and Rails application defining it's dependencies in Gemfile.lock. Rubygems are being packaged in distros, so why shouldn't node packages? Some of them are already packaged by distros, and we have even guidelines to do that: https://fedoraproject.org/wiki/Packaging:Node.js But then you'll be using yum/dnf/whatever instead of npm to install it. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 13/11/14 21:11, Matthew Farina wrote: I would like to take a moment to point out that developing system software is different from developing web applications. The way systems software is developed and often deployed is different from web applications. Horizon as it sits today appears to be web application development by systems software developers. This raises the barrier to entry for web application developers. The approach being proposed moves horizon into the realm of web application technologies that web application people use today. The debate as I'm reading it is about taking web application development processes and turning them into systems development processes which are often foreign to web application developers. How is this going to work out? How will web app people be willing to get involved? Why should this be treated the same? Most of OpenStack is a systems problem. This piece is a little different. To make it successful should it get some wiggle room to work well in the space it's in? Note, I'm not saying it should be insecure or anything like that. There are just different approaches. Basically, you're saying, we should lower standards to attract more people? I disagree in your request, to handle horizon different from the rest of OpenStack: why? And it worked quite well in the past. This IMHO that's just wrong. When new folks show up: great! Everybody's welcome. We might need to educate people here. There are so many patterns used, and they have been proven wrong in the past. Technically, it's possible to have several copies of the same library installed. But because it's possible, that doesn't mean, you should do that. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 13/11/14 19:11, Donald Stufft wrote: As far as I’m aware npm supports TLS the same as pip does. That secures the transport between the end users and the repository so you can be assured that there is no man in the middle. Security wise npm (and pip) are about ~95% (mad up numbers, but you can get the gist) of the effectiveness as the OS package managers. Oh, e.g rpm allows packages to be cryptographically signed, and depending on your systems config, that is enforced. This is quite different from just tls'ing a connection. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 14/11/14 16:21, Adam Young wrote: Example: I don't need Grunt to run a web server. I need Apache for that. Grunt does not need to be in the distro, mod_wsgi does. I will need every tool required to run e.g. unit tests or selenium tests to be packaged. Why? Because our builders don't have access to the internet and I want to be sure, the packaged version of horizon still passes tests. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 17/11/14 02:07, Richard Jones wrote: Except that selenium is non-free: it's in the non-free repository of Debian, because it contains a pre-built .xpi plugin for firefox, which itself contains pre-built .so and .dll files. Hasn't this issue already been addressed? Horizon currently uses Selenium-based integration tests. For Fedora, we found, that simply removing bundled .dll and .xpi files still leaves selenium intact. But I agree, I would like not to have that stuff bundled at all. Tests in Horizon are: unit tests and selenium tests, both executed at the gate; selenium tests are just mocked, vs. integration tests require a cloud environment set up. This is not executed at the gate right now. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On 30/10/14 13:13, Matthias Runge wrote: Hi, tl;dr: how to progreed in separating horizon and openstack_dashboard Options so far: horizon_lib/openstack_horizon horizon_lib/horizon_dashboard horizon_lib/horizon horizon/openstack_dashboard did I miss something? If not, I'll create a poll. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On 17/11/14 13:28, Yves-Gwenaël Bourhis wrote: Le 11/11/2014 09:30, Jiri Tomasek a écrit : From what was discussed on contributors meetup, keeping the names 'horizon' for the lib (framework) and 'openstack_dashboard' for dashboard seemed most convenient. And I happen to aggree with that. +1 We also discussed the fact that we could keep the names to the modules, but rename only the packages. pip install horizon_lib - installs the horizon module pip install horizon - installs openstack_dashboard. This would allow using the new names for the packages without braking the existing code depending on the libraries which import them. There is already horizon on pypi[1] IMHO this will lead only to more confusion. Matthias [1] https://pypi.python.org/pypi/horizon/2012.2 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote: I guess I got the message that turning bower packages into system packages was something that the Linux packagers were not keen on. Did I get the message wrong there? If so, *and* we can get the bower stuff through #infra and global-requirements then yes, we should totally try to avoid adding the xstatic layer :) For me, it's more work to turn packages into bower, or to translate bower packages to system packages. But that is purely because we don't have bower packaged currently in Fedora. I would vote for the cleaner way (whatever that is). XStatic is obviously not the cleanest way, but a good compromise in most situations. Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 19/11/14 05:25, Richard Jones wrote: I've just had a long discussion with #infra folk about the global-requirements thing, which deviated (quite naturally) into a discussion about packaging (and their thoughts were in line with where Radomir and I are heading). In their view, bower components don't need to be in global-requirements: - there are no other projects that use bower components, so we don't need to ensure cross-project compatibility - we can vet new versions of bower components as part of standard Horizon change review That sounds good to me! Thanks for doing this! Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 19/11/14 17:52, Fox, Kevin M wrote: Perhaps they are there to support older browsers? Probable. Windows dlls are quite uncommon in a Linux distribution. It's a bit unlikely to have an older browser installed in a centrally managed distribution like Fedora. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Separate horizon and openstack_dashboard
On 17/11/14 14:43, Yves-Gwenaël Bourhis wrote: Le 17/11/2014 14:19, Matthias Runge a écrit : There is already horizon on pypi[1] IMHO this will lead only to more confusion. Matthias [1] https://pypi.python.org/pypi/horizon/2012.2 Well the current horizon on Pypi is The OpenStack Dashboard + horizon(_lib) included If the future horizon on pypi is openstack_dashboard alone, it would still pull horizon_lib as a dependency, so it would not brake the existing. That would break expectations. When installing a software package named python-foo, I would expect a python package named foo in there, not a package named bar. Dependencies between packages are best defined in distribution packages. They solve dependencies since ages. For Fedora, there is a policy for package naming. I'd assume the same to be true for Debian. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Patching Horizon Code when installed using apt-get install
On 25/06/13 10:52, Rahul Sharma wrote: Hi All, I have setup multi-node openstack setup using grizzly release and ubuntu 12.04 distribution. Since there is no support for individual user to change his/her password, someone has provided a patch for the same. Ref:- https://review.openstack.org/#/c/23901/31 For me, it looks like you were hit by another issue, probably totally unrelated with your patch. https://bugs.launchpad.net/horizon/+bug/1125622 Sadly, there is currently no solution for this, e.g I can not reproduce that issue at all. Matthias ___ 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 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? How did Horizon went into Debian packages at all, since the situation in this front is unchanged for at least a year (just curious). Matthias ___ 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 04/07/13 15:55, Daniel P. Berrange wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636677 the package ships some files which are not yet built from source. Whether this is still accurate or not, is another matter, since that bz is 2 years old... I remember that I filed a bug, because selenium shipped a binary web driver adapter for firefox. E.g there are prebuilt files checked into seleniums svn: http://selenium.googlecode.com/svn/tags/selenium-2.28.0/cpp/prebuilt/ which are/were required to build the whole thing. That was the point where I stopped packaging it for Fedora. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Ceilometer visualization in Horizon
On 09/07/13 09:22, Christian Berendt wrote: I gave http://www.chartjs.org/ a try and it's working fine. But I'm not sure about the license (MIT license). Is it possible to add Chart.js to the horizon repository? Or are there any other suggestions? d3 is already included in horizon. At the last summit, we agreed to use just a single graphing lib. This being said, I strongly suggest to try it. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon - Mockup tool
On 29/08/13 22:31, Endre Karlson wrote: Does anyone know what too is used to do mockups ? I'd suggest pencil to you. http://pencil.evolus.vn/ Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When will we stop adding new Python modules to requirements
On 16/09/13 17:36, Michael Basnight wrote: Not to forget python-troveclient, which is currently a hard requirement for Horizon. During the review for python-troveclient, it was discovered, troveclient still references reddwarfclient (in docs/source). Are you saying it references another codebase? Or just that when we renamed it we forgot to update a reference or two? If its the latter, is it relevant to this requirements issue? Also, I will gladly fix it and release it if its making anyone's life hell :) In my understanding, this is just due forgotten references during the rename, it's not relevant to the requirements issue. Currently, just the docs refer to reddwarf, resulting in build issues when building docs. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When will we stop adding new Python modules to requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/09/13 17:51, Michael Basnight wrote: Currently, just the docs refer to reddwarf, resulting in build issues when building docs. Whew! Ill fix it anyway. Thx fro pointing it out. Awesome, Michael. Very much appreciated! Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSNyxJAAoJEOnz8qQwcaIWN/cH/1iS6vqNzp/Wh/G5EQc8lYfX el+dozlaSIyECrtPWJyHMTpjW5/LGTJthn2f/MyFNSMamkY78CYeORRD2isU+TUR MMh2y/r7TbtgXMEVEwSjNgPp/uMz4pB+/gRjM305sMSuaPbCo3PU+0G/DpYAtgk1 GIxsUXeMlU/0iJajKemv/d1/LRRZSa2XFLqYTAiGYpfabfvJwffTxF0KvcRu3kcZ e4c6ylVA98qhmtqhhfuKdclTQxeaiJPDn0kya+Mw4XAJK+r3u4TdsioYmaEw6PGk o2qw4wobl4BRK+NqlaqA6E0dAPBa2rXOQBaRtDf5YFSjs0xBK7i7wQ//7ubdChs= =o1uM -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Jenkins} Gating broken
On 24/09/13 11:10, Gary Kotton wrote: This just seems to affect Nova. Thanks Gary From: Administrator gkot...@vmware.com mailto:gkot...@vmware.com Reply-To: OpenStack Development Mailing List Sadly not. Horizon seems to be broken for the same reason. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [stable] Exception proposals for 2014.2.1
On 03/12/14 20:22, Alan Pevec wrote: Horizon standing-after-freeze translation update, coming on Dec 3 This is now posted https://review.openstack.org/138798 David, Matthias, I'd appreciate one of you to have a quick look before approving. Cheers, Alan Alan, thanks for the heads-up here. Approved. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 22/01/15 09:48, Radomir Dopieralski wrote: All of the XStatic packages had to be packaged for the respective distributions in order to package Horizon. That was a lot of work, but it has been done my the packagers of the distributions. As far as I understand, most of those XStatic packages are just dummies, pointing to the actual system-wide JavaScript packages -- XStatic has such a capability. So while we are indeed maintaining some of the XStatic packages for our own convenience, the packages that contain actual code in the distributions are maintained by those distributions' packagers. Yupp, poniting to system packages is something, which makes the XStatic approach way more acceptable. But, if you don't have them (yet), xstatic packages will bundle js libs for you. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 21/01/15 09:59, Martin Geisler wrote: This seems to imply that users will download at least one .js file per dependency. Not necessarily. We still use django-compressor, which copies all javascript into fewer files. E.g. here in my untweaked juno environment, I just get 3 instead of 10-15 following your logic above. (at least one js file per xstatic package). That's probably acceptable for an application like Horizon which users will be using again and again, but for most web applications, you don't want your users to download 10-20 small .js files, instead you want them to download one minified and compressed file with all the JavaScript code needed. see above :D I'm just mentioning this since it's one way that web apps differ from how normal Linux apps are typically deployed. Basically, web apps prefer static compilation and discourages dynamic linking. I'm not sure, I can really follow you here. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Weekly status report (Thu, Jan 22)
Hello, a bit early, but here's my status report for the past week RED: - none AMBER: - still preparing my workshop for devconf in Brno - prepared a patch to add OVA format to horizon https://review.openstack.org/150751 - continued JavaScript fun - cleaned up blueprints upstream - bugzilla housekeeping GREEN: - lots of reviews upstream - Feature for Fedora 22 was approved: https://fedoraproject.org/wiki/Changes/Django18 - debugged Ciscos Dashboard unavailable issue - changed Django package due to several guideline changes (bash completion change, python-sphinx-latex was added and broke python-django builds) - packaged and got python-oslo-concurrency approved Will be traveling tomorrow to FOSDEM. See you there and/or have a great weekend, Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Weekly status report (Thu, Jan 22)
On 29/01/15 13:20, Matthias Runge wrote: Hello, a bit early, but here's my status report for the past week Yupp, please ignore the noise here. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On Thu, Jan 22, 2015 at 09:18:46PM +, Jeremy Stanley wrote: On 2015-01-22 16:06:55 -0500 (-0500), Matthew Farina wrote: [...] When there is an update to our requirements, such as the recent version increment in the version of angular used, a new package version doesn't automatically show up as evident from that list. How would that process be kicked off so we don't end up with a missing dependency? Does that have to wait for a release cycle? I don't want to speak for the distro package maintainers, but from what I've seen they generally wait until close enough to an integrated release that they can be pretty sure the requirements are close to frozen, so as not to waste effort packaging things which will end up not being used. Yes, exactly. I for myself am using horizonfrom a github checkout, providing all dependencies as RPM packages. That being said, I'm updating/packaging requirements, whenever they'll show up for me. There is no automatic process. I assume (perhaps incorrectly?) that we do use those in CI jobs, so that we can download the things a given project needs in an automated fashion--for us handling pip requirements lists is a solved problem (well, for some definitions of solved at least). It would be totally awesome to switch from pip install to using distribution packages for testing purposes. At least for dependencies. This appears to affect the testing setup as well. When we start to use a new version of a JavaScript dependency no package will exist for it. I believe this would mean the testing environment needs to use the development setup, in the proposal, of bower. IIRC, bower goes out to the Internet and there isn't a mirror of packages (just a mirror of the registry). That means we'll loose the ability to run testing installs from local mirrors for these dependencies. I imagine a solution has been thought of for this. Can you share any details? Uh, we have seen so many timeouts and failing tests, because some mirror was not answering fast enough etc. I don't think, adding another external service will improve the situation here. -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 23/01/15 10:31, Jeremy Stanley wrote: On 2015-01-23 10:11:46 +0100 (+0100), Matthias Runge wrote: [...] It would be totally awesome to switch from pip install to using distribution packages for testing purposes. At least for dependencies. [...] While it seems nice on the surface, the unfortunate truth is that neither the infra team nor the various package maintainers has the excess of manpower needed to be able to near-instantly package new requirements and new versions of requirements for the platforms on which we run our CI jobs. I fear that the turn-around on getting new requirements into projects would go from being on the order of hours or days to weeks or even months. We could work around that by generating our own system packages for multiple platforms rather than relying on actual distro packages, Oh, I still would try to get that enabled from a distro perspective. But that's something, a distro CI could provide feedback here. I think providing/updating distro packages is quite comparable to updating pypi packages. Maintaining an additional set of packages is just wrong IMO. Nevertheless, that might be required for a transitional phase. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon switching to the normal .ini format
On 05/01/15 19:27, Matthew Farina wrote: Switching to an ini format would likely be painful to impossible. Horizon is built on django which is where the settings.py format comes from. It's part of a django app. For more info see the django docs. The settings information is at https://docs.djangoproject.com/en/1.6/topics/settings/ Sorry, I fail to see, how this should be impossible, esp. if you look at the linked patch; the rest of the stack uses such an .ini format, too. Matthias On Thu, Dec 25, 2014 at 1:25 PM, Timur Sufiev tsuf...@mirantis.com mailto:tsuf...@mirantis.com wrote: Thomas, I could only point you to the Radomir's patch https://review.openstack.org/#/c/100521/ It's still a work in progress, so you may ask him for more details. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 13/01/15 16:31, Jeremy Stanley wrote: On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote: [...] Why were the libraries ripped from the Horizon codebase in the first place? It seems to me they belong with the code using it. I disagree. If those libraries aren't developed as part of Horizon then they should not be copied into and distributed as part of its source tree. That's code duplication, plain and simple. I'm in favor of cleaning out all the vendoring of third-party libraries in OpenStack projects, but agree that it would be nice to find a cross-platform/portable mechanism for handling them. Yes! Keeping libraries separate, makes maintaining stuff so much easier. You don't need to persuade me here. I completely agree. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] static files handling, bower/
On 12/01/15 21:53, Drew Fisher wrote: I know I'm very very late to this thread but can I ask why Bower? Bower has a hard requirement on Node.js which was removed as a dependency in Havana. Why are we reintroducing this requirement? For Solaris, a requirement on Node.js is especially problematic as there is no official SPARC port and I'm not aware of anybody else working on one. I agree that XStatic isn't really the best solution here but are there any other solutions that don't involve Node.js? The same is true for ARM based machines, as node.js is AFAIK x86 only. But, as far as I understand, node.js will become a development requirement (and most probably a requirement for testing), but not for deployment. Bower is just another package manager, comparable to npm, pip etc. if you use that aside your systems package manager. The idea is, to use something like dpkg or rpm to provide dependencies for installation. During development and testing, it's proposed to rely on bower to install dependencies. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] packaging problem production build question
On 08/01/15 23:46, Matthew Farina wrote: Thanks for humoring me as I ask these questions. I'm just trying to connect the dots. How would system packages work in practice? For example, when it comes to ubuntu lucid (10.04 LTS) there is no system package meeting the jQuery requirement and for precise (12.04 LTS) you need precise-backports. This is for the most popular JavaScript library. There is only an angular package for trusty (14.04 LTS) and the version is older than the horizon minimum. private-bower would be a nice way to have a private registry. But, bower packages aren't packages in the same sense as system or pypi packages. If I understand it correctly, when bower downloads something it doesn't get it from the registry (bower.io http://bower.io or private-bower). Instead it goes to the source (e.g., Github) to download the code. private-bower isn't a package mirror but instead a private registry (of location). How could private-bower be used to negate network effects if you still need to go out to the Internet to get the packages? For a deployment, you want updates, often installed automatically. Your repository providing your horizon package needs to provide required dependencies as well. I wouldn't recommend to use bower. In some environments, it's not allowed to use third party repositories at all. A test environment should match a possible production environment, where it can. This one is quite easy. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stable] Proposing to add Lin-Hua Cheng to horizon-stable-maint
Hello, I'd like to propose to add Lin-Hua Cheng to horizon-stable-maint. Lin has been a Horizon Core for a long time and has expressed interest in helping out with horizon stable reviews. I think, he'll make a great addition! Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra][horizon] Need help at debugging requirements issue
Hello, I was trying to raise the cap for Django in[1]. It looks quite simple, current requirements is Django=1.4.2,1.7 and I simply removed the upper boundary: Django=1.4.2 with the result, django-nose is not installed any more. (That's a rest dependency for horizon), it's listed in the same global-requirements file: django-nose (no version requirement). Sadly, I can not figure out, why that happens and how to fix that. In local tests, this just works. Any hints please? Thanks, Matthias [1] https://review.openstack.org/#/c/155353/ -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][horizon] Need help at debugging requirements issue
On 19/03/15 15:52, Ihar Hrachyshka wrote: [1] https://review.openstack.org/#/c/155353/ Hi, it all comes to the fact that DEVSTACK_GATE_INSTALL_TESTONLY=1 is not specified in the requirements integration job. I think you need to set it at [1]. In that case, your test requirements will also be installed during the job. Thanks Ihar, the issue is, the only change was, to remove the upper boundary from Django=1.4.2,1.7 And removing 1.7 from that line resulted in not installing django-nose any more. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] HTTPD Config
On Fri, Mar 06, 2015 at 11:08:44AM -0500, Adam Young wrote: No matter what we do in devstack, this is something, horizon and keystone devs need to fix first. E.g. in Horizon, we still discover hard coded URLs here and there. To catch that kind of things, I had a patch up for review, to easily configure moving Horizon from using http server root to something different. Link? https://review.openstack.org/#/c/86880/ Obviously, that needs a bit work now. -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Do No Evil
On 09/03/15 15:54, Doug Hellmann wrote: Not everyone realizes that many of the distros run our tests against the packages they build, too. So our tool choices trickle downstream beyond our machines and our CI environment. In this case, because the tool is a linter, it seems like the distros wouldn't care about running it. But if it was some sort of test runner or other tool that might be used for functional tests, then they may well consider running it a requirement to validate the packages they create. For Fedora, we're also running horizons unit tests during package build. I would assume the same is true for other distros as well. Because our build system is not allowed to pull anything from the internet, we rely exclusively on already available software packages. Due to the license (good not evil), we can not have jslint as package. For the given reason, pulling it from the net during build doesn't work either. Another warning: users expect development as essential and to be available, because they might require them to CUSTOMIZE horizon. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
Hello, I'm requesting an exception to bump Django to Django-1.7.x (or better). Rationale: Django-1.8 is expected to be released during the next days. Once it's released, Django-1.6.x will become unsupported by its upstream. Unfortunately that's the latest version we're gating against and that's the version frozen for kilo, or in other words: When Kilo is released, it relies on a version, not supported any more. Review is at https://review.openstack.org/#/c/155353/ -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
On Thu, Mar 26, 2015 at 06:02:41AM -0400, Sean Dague wrote: Yes, just approved. Thank you, much appreciated! -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] HTTPD Config
On 05/03/15 19:49, Adam Young wrote: I'd like to drop port 5000 all-together, as we are using a port assigned to a different service. 35357 is also problematic as it is in the middle of the Ephemeral range. Since we are talking about running everything in one web server anywya, using port 80/443 for all web stuff is the right approach. I have thought about this as well. The issue here is, URLs for keystone and horizon will probably clash. (is https://server/api/... a keystone or a call for horizon). No matter what we do in devstack, this is something, horizon and keystone devs need to fix first. E.g. in Horizon, we still discover hard coded URLs here and there. To catch that kind of things, I had a patch up for review, to easily configure moving Horizon from using http server root to something different. I would expect the same thing for keystone, too. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
On 25/03/15 11:34, Sean Dague wrote: Could you make this one Depends on https://review.openstack.org/#/c/167515/ so that we check that all Django 1.7 related issues are fixed ? I don't think it was ever sufficiently explained why horizon now needs django nose to compile it's message catalog (which is where it is failing) when moving to 1.7. http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098 We're getting nearer here, thank you! --compilemessages is called with test settings, which is wrong imo. The question is, why it has not hit us earlier. In any case, django_nose is not a runtime dep. I can see, why this is run at the gate as part of tests, though. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [depfreeze][horizon] Update to Django-1.7.x
On Wed, Mar 25, 2015 at 12:00:11PM +0100, Matthias Runge wrote: On 25/03/15 11:34, Sean Dague wrote: Could you make this one Depends on https://review.openstack.org/#/c/167515/ so that we check that all Django 1.7 related issues are fixed ? I don't think it was ever sufficiently explained why horizon now needs django nose to compile it's message catalog (which is where it is failing) when moving to 1.7. http://logs.openstack.org/53/155353/7/check/check-tempest-dsvm-full/961c75f/logs/devstacklog.txt.gz#_2015-03-20_19_25_51_098 We're getting nearer here, thank you! --compilemessages is called with test settings, which is wrong imo. Now that this has been been fixed, can we proceed now? Matthias -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Core Reviewer Update
On 29/04/15 00:57, David Lyle wrote: Thank you all for your contributions and welcome to the team! David Yes! Thanks a lot. You'll all make a great addition to the team. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 05/05/15 05:29, Robert Collins wrote: Probably, but it's legally wrong (ie: worst case, you can be sued) to leave a package which is in direct violation of the license of things it contains. So,we shouldn't use angular at all then, because as a js framework its distributed to users when they use the website, but the license file isn't included in that distribution. Would be good to get a legal position on this. If we're not allowed to use angular (and anybody else), I wonder how anyone could use it (following above logic) Angular.js is licensed under MIT License [1],[2]: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. question is, if our use of angular is a substantial portion if this software. Matthias [1] https://angularjs.org/ [2] https://github.com/angular/angular.js/blob/master/LICENSE __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [PKG-Openstack-devel][horizon][xstatic] XStatic-Angular-Bootstrap in violation of the MIT/Expat license (forwarded from: python-xstatic-angular-bootstrap_0.11.0.2-1_amd64.changes R
On 05/05/15 04:31, Ian Cordasco wrote: Even so, Horizon is deployed in many places, and given the reliability of system packages, it’s increasingly deployed from source. Ok, I'll bite. You surely have a source for your statement, or even better, a proof? This is wrong in so many ways. It's the same truth as someone could claim: neutron doesn't work, so don't use it. (just took neutron as example) If there is something wrong with system packages, please file bugs. Every distribution has a bug tracker. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
