I want to clarify this. Jshint is not a requirement. It is not in
requirements.txt or test-requirements.txt nor is it a hard system
requirement.
Jshint is treated as an optional tool that can either be installed via tox
in the jshint testenv which uses npm to pull it down, or by manual
install.
Adding support for incubated projects in Horizon is blocked mainly for
dependency issues. The way Horizon utilizes the python-*clients we force a
requirement on distros to now include that version of the client even
though it is not officially part of OpenStack's integrated release.
Additionally,
Horizon has been actively moving away from having 3rd party JavaScript
libraries bundled in the Horizon repo. Most have been removed barring one
or two exceptions. Moving forward new JavaScript libraries dependencies
should either use existing xstatic packages or need a new one created for
the
It came to my attention today that I've only communicated this in Horizon
team meetings.
Due to the high number of blueprints already targeting Juno-3 and the
resource contention of reviewers, I have set the Horizon Feature Proposal
Deadline at August 14 (August 12 actually, but since I didn't
On 8/6/14, 1:41 PM, Timur Sufiev tsuf...@mirantis.com wrote:
Hi, folks!
Two months ago there was an announcement in ML about gathering the
requirements for cross-project UI library for
Heat/Mistral/Murano/Solum [1]. The positive feedback in related
googledoc [2] and some IRC chats and emails
Django 1.7 drops support for python 2.6 [1], so until OpenStack drops
support for 2.6 which is slated for Kilo, Horizon is unfortunately capped
at 1.7.
David
[1]
https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibility
On 7/23/14, 4:56 AM, Thomas Goirand z...@debian.org
On 7/23/14, 7:51 AM, Steve Baker sba...@redhat.com wrote:
On 18/07/14 08:35, Matt Riedemann wrote:
On 7/17/2014 5:48 PM, Steve Baker wrote:
On 18/07/14 00:44, Joe Gordon wrote:
On Wed, Jul 16, 2014 at 11:28 PM, Steve Baker sba...@redhat.com
mailto:sba...@redhat.com wrote:
On
Welcome Zhenguo and Ana to Horizon core.
David
On 6/20/14, 3:17 PM, Lyle, David david.l...@hp.com 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
I released django_openstack_auth 1.1.6 on Friday to fix the login issue
with PKIZ. Part of that release contained a pep8 cleanup that broke
Horizon, ultimately because we were doing something stupid in Horizon. We
added a fix to Horizon to correct the issue on trunk
On 6/20/14, 6:24 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
On 20/06/14 13:56, Jaromir Coufal wrote:
On 2014/19/06 09:58, Matthias Runge wrote:
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
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
I have no problem with this proposal.
David
On 6/4/14, 6:41 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
Hello,
I'd like to start a discussion about the use of mocking libraries in
Horizon's tests, in particular, mox and mock.
As you may know, Mox is the library that has been used so
I think this falls inline with other items we are working toward in
Horizon, namely more pluggable components on panels.
I think creating a directory in openstack_dashboard for these reusable
components makes a lot of sense. And usage should eventually moved to
there.
I would suggest something as
We are in the process of removing the redundancy between Project and Admin
by using RBAC to allow sharing of one code base for multiple roles. This
is a WIP.
David
On 5/28/14, 1:53 PM, Tzu-Mainn Chen tzuma...@redhat.com wrote:
Hi Doug,
Thanks for the response! I agree with you in the cases
The idea here is to decouple 3rd party static files from being embedded in
the Horizon repo. There are several reasons for this move. With embedded
3rd party static files upgrading the static files is cumbersome, versions
can be difficult to track and updates can be difficult to synchronize.
This
I would like to announce my candidacy for Horizon PTL.
I've been working on and contributing to Horizon for the last three releases
and had the pleasure to serve as the PTL for the Icehouse cycle.
In the Icehouse cycle, we started a number of changes that I would like to see
completed in the
This is easy to accomplish by creating a custom template for a cell. In your
table, instead of providing a data field for the column, provide a method name,
have that method load a custom HTML template.
Here is an example of this without an image of this method:
The results are unanimous. Congratulations Radomir and welcome to the Horizon
Core team.
Thanks for all of your efforts.
David
-Original Message-
From: Lyle, David
Sent: Wednesday, March 05, 2014 3:36 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon
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
With meeting logging now available in #openstack-meeting-3, the official
Horizon meeting time is now Tuesdays at 1600 UTC in #openstack-meeting-3.
Looking forward to seeing all Horizon folks there.
David
___
OpenStack-dev mailing list
I would just like to echo what Julie stated.
The Horizon project strives to be accessible, so raising concrete issues is
extremely helpful. Please file the appropriate bugs and blueprints.
That said, there are pages that will not be accessible by nature (topologies)
and are currently marked
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
-Original Message-
From: Tzu-Mainn Chen [mailto:tzuma...@redhat.com]
Sent: Saturday, January 11, 2014 2:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Tuskar-UI navigation
Thanks! Just wanted to check before we went deeper into
So after a lot of consideration, my opinion is the two code bases should stay
in separate repos under the Horizon Program, for a few reasons:
-Adding a large chunk of code for an incubated project is likely going to cause
the Horizon delivery some grief due to dependencies and packaging issues
Thanks Liz for setting up the poll.
I'm not sure we're locked to Tuesday as the meeting day either.
On Tuesdays, 20:00 UTC (TC meeting) and 21:00 UTC (Project) are meetings I
don't want to schedule over.
Those times are more attractive on other days.
-David
-Original Message-
The simplest solution is already built into the Horizon framework. Any panel
or dashboard can be disabled by a check to determine if a service is available
in the service catalog. Since there is an inherent above/under cloud
separation here, the Tuskar service should not be available above
+1 on moving the domain admin role rules to the default policy.json
-David Lyle
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, December 11, 2013 9:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] domain admin
-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com]
Sent: Wednesday, December 11, 2013 10:28 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Horizon] Nominations to Horizon Core
On 12/11/2013 03:51 PM, Russell Bryant wrote:
On
So again, nothing prevents a non-core security reviewer from reviewing
blueprints and doing code reviews. Believe me any security minded input is
always welcome and weighed carefully.
Although the principle of having a minimum number of security reviewers in core
is certainly a fair point of
This topic has been available on ux-askbot and ux Google+ forum before that for
months. Based on that alone, I don’t believe the vote was limited. All input
was taken and considered. In the end, there are strong opinions on both sides.
What the final outcome was… We’ll implement the
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
The set domain context functionality is for operators (admins) to refine the
context that they are working in/viewing. Admins can limit the scope of
identity visibility to one domain, rather than having to sort through the
exhaustive lists of projects, users, and groups.
If you are adding
On 5 December 2013 12:10, Robert Collins robe...@robertcollins.net wrote:
-snip-
That said, perhaps we should review these projects.
Tuskar as an API to drive deployment and ops clearly belongs in
TripleO - though we need to keep pushing features out of it into more
generalised tools
We have been having this discussion here on the mailing list [1][2] and also in
the Horizon team meetings [3].
The overall consensus has been that we are going to move forward with a
JavaScript requirement.
Most of the pushback to support non-JavaScript is based on web-accessibility
standards
On Wednesday, November 20, 2013 3:12 PM
Dolph Mathews dolph.math...@gmail.com wrote:
On Wed, Nov 20, 2013 at 1:06 PM, Dmitri Zimin(e) | StackStorm
d...@stackstorm.com wrote:
Thanks Terry for highlighting this:
Yes, tenant isolation is the must. It's not reflected in the prototype - it
From a purely UI perspective, the limit/offset is a lot more useful. Then we
can show links to previous page, next page and display the current page number.
Past mailing list conversations have indicated that limit/offset can be less
efficient on the server side. The marker/limit approach
I think there is certainly interest. I do think it will need to be highly
configurable to be useful. The problem, as Dolph points out, is that each
deployment has its own workflow.
Points of configuration:
-Does the local keystone deployment policy support self-registration? The
default
You'll want to add the OPENSTACK_SSL_CACERT setting in your local_settings.py
and have the value be the path of your CA cert file.
I thought it was documented, but looking now, I don't see it.
I would like to announce my candidacy for the Horizon PTL.
I have been developing, extending and contributing to Horizon through the
Grizzly and Havana releases serving as a core team member in the Havana cycle.
And most recently in Icehouse, being interim PTL.
At the Havana OpenStack Summit,
This is a topic near to my heart. I think it's a logical move to have a
separate dashboard for identity. At the summit, we have a session planned on
discussing the overall Information Architecture of Horizon
http://icehousedesignsummit.sched.org/event/3b3b3430fe23da9ffed6a15eda50fd25
One
-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Wednesday, October 30, 2013 8:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Revisiting current column number limit in code
On 30/10/13 07:22 -0400, Sean
Right now, master in Horizon is still working toward Havana-rc1. We are still
likely more than a week away from master moving to Icehouse-1. As this is the
case, reverting a highly desired Havana change to address a blueprint for
Icehouse that can be addressed properly upstream in lesscpy
Adam Young ayo...@redhat.com wrote:
Looks like this has grown into a full discussion. Opening up to the dev
mailing list.
On 09/16/2013 10:43 AM, Lyle, David (Cloud Services) wrote:
I did run into a couple of fundamental limitations with the policy API as
implemented in Keystone.
1
Hi Sean,
A couple weeks ago after a really *fun* night we started down this
road of uncapping all the python clients to ensure that we're actually
testing the git clients in the gate. We're close, but we need the help
of the horizon and ceilometerclient teams to get us there:
1) we need
It is not entirely clear to me what your desired behavior is, but I won't let
that stop me from hazarding a guess.
Horizon now supports keystone API versions 2.0 and 3. By default, if the
keystoneclient that is installed supports v3, then that is what Horizon will
use. However, you can
45 matches
Mail list logo
