Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Ioram Schechtman Sette i...@cin.ufpe.br
Date: 02/05/2015 03:15AM
Subject: Re: [openstack-dev] [horizon][keystone]
Hi Thai,
I agree with Anton that the names are not intuitive for users.
I would use something like
(not for usage questions)
openstack-dev@lists.openstack.org
Date: 02/05/2015 06:14 AM
Subject: Re: [openstack-dev] [horizon][keystone]
Hi Thai,
I agree with Anton that the names are not intuitive for users.
I would use something like:
- Local authentication (for local credentials)
- ?? (I also have
to see it.-Ioram Schechtman Sette i...@cin.ufpe.br wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Ioram Schechtman Sette i...@cin.ufpe.brDate: 02/05/2015 03:15AMSubject: Re: [openstack-dev] [horizon][keystone]Hi Th
.
Aaron D. Sahlin
IBMUSM07(asahlin)
Dept. X2WA
Phone 507-253-7349 Tie 553-7349
From: Matthew Farina m...@mattfarina.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 02/05/2015 11:29 AM
Subject:Re: [openstack-dev] [horizon
Marek,Yep, that makes a lot of sense. Can definitely add that.-Marek Denis marek.de...@cern.ch wrote: -To: openstack-dev@lists.openstack.orgFrom: Marek Denis marek.de...@cern.chDate: 02/05/2015 01:35PMSubject: Re: [openstack-dev] [horizon][keystone]
Thai,
We
I'd like to step back for a moment as to the purpose of different kinds of
documentation. Sphinx is great and it provides some forms of documentation.
But, why do we document methods, classes, or functions in python? Should we
drop that and rely on Sphinx? I don't think anyone would argue for
On 2015-02-05 09:20:35 -0800 (-0800), Matthew Farina wrote:
[...]
But, why do we document methods, classes, or functions in python?
Should we drop that and rely on Sphinx? I don't think anyone would
argue for that.
[...]
Particularly since Sphinx collects the method/class/function
docstrings
Hello Horizon Cores,
In K-2, Heat is enabled with new REST API to report the running heat-engine
status, This is in-line with how nova reports nova-compute running status.
To report this feature in horizon under 'System information panel', a new
blueprint is created at
/2015 06:04:36 AM:
From: Ioram Schechtman Sette i...@cin.ufpe.br
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date: 02/05/2015 06:14 AM
Subject: Re: [openstack-dev] [horizon][keystone]
Hi Thai,
I agree with Anton that the names
On 02/05/2015 10:27 AM, Anton Zemlyanov wrote:
JSDoc (ngdoc) is good thing. It allows to describe files, functions and
it's parameters, constructors, classes in case of ES6.
As does Sphinx.
The problem is it tends to diverge with reality. The code is being fixed
and evolved, but comments are
Hi,
I guess Credentials is login and password. I have no idea what is
Default Protocol or Discovery Service.
The proposed UI is rather embarrassing.
Anton
On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote:
Hi all,
I have been helping with the websso effort and wanted to
Ah, I had forgotten about the python module documentation. Sorry about that
and thanks for pointing it out.
Can we have that system parse and use JSDoc? I'd like it to be useful to
both JS devs and the doc generation toolchain.
On Thu, Feb 5, 2015 at 9:42 AM, Jeremy Stanley fu...@yuggoth.org
On Thu Feb 05 2015 at 12:07:01 AM Radomir Dopieralski
openst...@sheep.art.pl wrote:
Plus, the documentation generator that we are using already, Sphinx,
supports JavaScript perfectly fine, so I see no reason to add another tool.
Try to empathize with us a little here. What you're asking is
On 2015-02-05 10:19:39 -0800 (-0800), Matthew Farina wrote:
[...]
Can we have that system parse and use JSDoc? I'd like it to be
useful to both JS devs and the doc generation toolchain.
A quick Web search turned up
https://github.com/debrouwere/jsdoc-for-sphinx and
)
openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
Date: 02/04/2015 05:42AM
Subject: [openstack-dev] [horizon] JavaScript docs?
In python we have a style to document methods, classes, and so forth. But,
I don't see any guidance on how JavaScript should be documented
04/2015 05:42AMSubject: [openstack-dev] [horizon] _javascript_ docs?In python we have a style to document methods, classes, and so forth. But, I don't see any guidance on how _javascript_ should be documented. I was looking for something like jsdoc or ngdoc (an extension of jsdoc). Is there any guida
Hi all,I have been helping with the websso effort and wanted to get some feedback.Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service.If user selects credentials, it works exactly the same way it works today.If user selects
: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
Date: 02/04/2015 05:42AM
Subject: [openstack-dev] [horizon] JavaScript docs?
In python we have a style to document methods, classes, and so forth
, February 4, 2015 4:00:17 PM
Subject: Re: [openstack-dev] [horizon] JavaScript docs?
On 02/04/2015 12:48 PM, Michael Krotscheck wrote:
I agree. StoryBoard's storyboard-webclient project has a lot of existing
code already that's pretty well documented, but without knowing what
In python we have a style to document methods, classes, and so forth. But,
I don't see any guidance on how JavaScript should be documented. I was
looking for something like jsdoc or ngdoc (an extension of jsdoc). Is there
any guidance on how JavaScript should be documented?
For anyone who doesn't
On 2015-01-23 12:02:19 +0100 (+0100), Matthias Runge wrote:
[...]
I think providing/updating distro packages is quite comparable to
updating pypi packages.
[...]
Within an order of magnitude anyway. The difference is that most
Python module upstream authors do their own packaging for PyPI (for
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
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
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
I see that https://bugs.launchpad.net/horizon/+bug/1403129 is marked a wish
list. But it affects Glance and hence associated component with it
significantly.
The defect directly influence consumption of Horizon for Glance, especially
concurrency. If user wants to upload 3 images of large size
Radomir Dopieralski openst...@sheep.art.pl writes:
On 22/01/15 11:27, Martin Geisler wrote:
Maybe this is a dumb question, but if there already is a system
package for, say, Angular, why is the XStatic packge needed then?
Could the system package for Horizon not just point directly to where
On 22/01/15 11:27, Martin Geisler wrote:
Maybe this is a dumb question, but if there already is a system package
for, say, Angular, why is the XStatic packge needed then? Could the
system package for Horizon not just point directly to where the Angular
package has put its files?
Yes, that is
On 21/01/15 19:04, Matthew Farina wrote:
Radomir, thanks for adding some clarity. I do have follow-on questions.
In your example the packages are managed by xstatic. The proposal for
horizon, as I understand it, is to move away from xstatic packages and
instead use bower for development and
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
Matthias Runge mru...@redhat.com writes:
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
On 2015-01-22 11:53:10 -0500 (-0500), Matthew Farina wrote:
Has anyone done an inventory of xstatic packages that are
available as system packages? I ask because I started asking these
questions after doing a cursory inventory and finding few xstatic
packages as system packages.
[...]
Radomir and Matthias,
Has anyone done an inventory of xstatic packages that are available as
system packages? I ask because I started asking these questions after doing
a cursory inventory and finding few xstatic packages as system packages. It
appeared to me that the common case was the one
On Fri Jan 23 2015 at 4:28:59 AM Matthew Farina m...@mattfarina.com wrote:
I would like to add one more nuance to this discussion that I don't
remember seeing.
JavaScript libraries run in web browser in their JavaScript engines (like
v8) rather than on the server. A version of a JS library
I would like to add one more nuance to this discussion that I don't
remember seeing.
JavaScript libraries run in web browser in their JavaScript engines (like
v8) rather than on the server. A version of a JS library may be fine on a
system, without any security issues, but contain browser issues.
Jeremy, thanks for sharing this. I do have a couple more questions and
comments based on this.
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
Richard,
I'm quite familiar with node.js and browser development. I think some of
the issue here may be a lack of detailed explanations and assumptions. By
asking questions here I, and some others, have been learning details that
we didn't know before. And, we're getting to follow from the intent
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
Radomir, thanks for adding some clarity. I do have follow-on questions.
In your example the packages are managed by xstatic. The proposal for
horizon, as I understand it, is to move away from xstatic packages and
instead use bower for development and system packages (for example, debian,
rpm, and
Martin,
django_compressor does handles creating aggregated and compressed files for
you. This isn't quite the same as C programs because it's not just due to
file size. For example, if you have 2 files many browsers will make two
separate connections to get each file. That mean negotiating a
Matthias Runge mru...@redhat.com writes:
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
On 20/01/15 20:58, Matthew Farina wrote:
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked through the Debian
and Ubuntu
On 21/01/15 09:21, david.co...@oracle.com wrote:
As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch
Radomir Dopieralski openst...@sheep.art.pl writes:
On 21/01/15 09:21, david.co...@oracle.com wrote:
As for our work and updates, using system-wide packages is an
excellent solution in this regard, as we get maintenance and updates
for free. For instance, if there is a security issue in one of
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
As for our work and updates, using system-wide packages is an excellent
solution in this regard, as we get maintenance and updates for free. For
instance, if there is a security issue in one of the JavaScript
libraries, we don't need to patch Horizon -- the patch that is prepared
for that
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked through the Debian and
Ubuntu packages I couldn't find the libraries horizon is
On Wed Jan 21 2015 at 7:00:12 AM Matthew Farina m...@mattfarina.com wrote:
Radomir, maybe you can help me better understand where this would go. I
have a few questions.
First, can you point me to a time when horizon used system packages
successfully for JavaScript libraries? When I looked
On 16/01/15 18:55, Matthew Farina wrote:
Doug, there still is one open question. Distributing JavaScript
libraries via system packages is unusual. Because of that, most of the
JavaScript libraries used by horizon don't have existing packages. Who
will create and maintain the packages for these
On Jan 15, 2015, at 7:27 PM, Michael Krotscheck krotsch...@gmail.com wrote:
I think Oracle's got enough money to support Node.js on SPARC.
How is money relevant here?
Well, normally the argument I've received is We don't have the
time/resources/insert-other-fiscally-motivated-reason
On 1/16/15 9:08 AM, Doug Hellmann wrote:
We are, and as this conversation has veered off in a destructive
direction, I think we should back up and look at the compromise Radomir
posted [1] to see if that solves the original technical problem we all have.
Does having the requirements
Does having the requirements specified in a JSON file, without requiring a
specific build tool to install the files, solve the packaging, testing, and
deployment issue on platforms where node.js isn’t supported natively right
now?
We only support what we test. Unless I missed something,
On Jan 16, 2015, at 11:33 AM, Drew Fisher drew.fis...@oracle.com wrote:
On 1/16/15 9:08 AM, Doug Hellmann wrote:
We are, and as this conversation has veered off in a destructive
direction, I think we should back up and look at the compromise Radomir
posted [1] to see if that solves the
Doug, there still is one open question. Distributing JavaScript libraries
via system packages is unusual. Because of that, most of the JavaScript
libraries used by horizon don't have existing packages. Who will create and
maintain the packages for these JavaScript libraries for production? For
On Jan 16, 2015, at 12:55 PM, Matthew Farina m...@mattfarina.com wrote:
Doug, there still is one open question. Distributing JavaScript libraries via
system packages is unusual. Because of that, most of the JavaScript libraries
used by horizon don't have existing packages. Who will create
/contributing.rst and submit a patch.
-Matthew Farina m...@mattfarina.com wrote: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
Date: 01/14/2015 12:20PM
Subject: Re: [openstack-dev] [horizon
I think Oracle's got enough money to support Node.js on SPARC.
How is money relevant here?
Well, normally the argument I've received is We don't have the
time/resources/insert-other-fiscally-motivated-reason to support/work on
node. Ergo, money. But then, given Oracle's conduct around the
Dear all,
I had raised a blueprint on Horizon for adding Version Information on the
System Info Page. Its been a while and it is still in new state.
https://blueprints.launchpad.net/horizon/+spec/version-info-on-system-info-page
Please provide your thoughts on this and also if it can be
All we need is to have someone spend some time to make it possible to have
a common meta files(configs, package descriptions, etc.) so that they can
be interchangeable and used by both Bower and pip, e.g. some tool to sync
changes made in one config and adding it to another. Then - whoever prefers
Ops, sent the prev mail before finishing it...
1. Development - all we need is versions of uncompressed js and css files.
We can use bower or pip requirements to get specific versions.
2. Testing - we need to do first some 'uglify'-ing tasks, using pyscss or
grunt and to run tests on that. Is is
On 14/01/15 23:05, david.co...@oracle.com wrote:
I'm not particularly well-versed in the Horizon build process so
perhaps I'm way off base. But given that a distribution's Horizon build
package embeds various JavaScript libraries to be used by the browser,
how those libraries are obtained
On 1/14/15 11:49 AM, Michael Krotscheck wrote:
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
I think Oracle's got enough money to support Node.js on SPARC.
How
too much.
-Matthew Farina m...@mattfarina.com wrote: -
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
From: Matthew Farina m...@mattfarina.com
Date: 01/14/2015 07:04AM
Subject: [openstack-dev] [horizon] function expressions vs
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
I think Oracle's got enough money to support Node.js on SPARC.
I think Solaris is no longer relevant
I won't stoop to comment on
w Farina m...@mattfarina.comDate: 01/14/2015 12:20PMSubject: Re: [openstack-dev] [horizon] function expressions vs function declarations in _javascript_Thai, I'm still poking around at _javascript_ things and did a little testing on function declarations vs function expressions. Seems Firefox is faster wit
I won't stop to comment on this statement other than to say Javascript is
quite relevant to Oracle, Oracle's customers, and Oracle's partners.
Your argument is a boondoggle. Refusing to use node because your favorite
platform doesn't support it is not the fault of node.js, it's the fault of
the
On 1/14/15 6:25 AM, Anton Zemlyanov wrote:
Solaris is supported by node.js:
x86 is certainly supported. Always has been. That's not the issue in
question. My point was that SPARC is not supported.
Solaris 32-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
JavaScript has multiple ways to deal with functions. There are function
declarations and function expressions (and named function expressions).
In looking at some reviews and the current code I found some
inconsistencies which leads me to ask, is there any guidance for handling
this in Horizon? I
On 2015-01-14 17:25:46 +0400 (+0400), Anton Zemlyanov wrote:
Solaris is supported by node.js:
Solaris 32-bit Binary: http://nodejs.org/dist/v0.10.35/
node-v0.10.35-sunos-x86.tar.gz
Solaris 64-bit Binary: http://nodejs.org/dist/v0.10.35/
node-v0.10.35-sunos-x64.tar.gz
I believe the point
On 01/14/2015 09:14 AM, Matthew Farina wrote:
I think we're discussing two different situations with slightly different
requirements.
First, there is development and test. I believe the stated goal is to have
node.js here. Would an environment not supporting node.js be needed for
I think we're discussing two different situations with slightly different
requirements.
First, there is development and test. I believe the stated goal is to have
node.js here. Would an environment not supporting node.js be needed for
development or testing? Note, the JavaScript under test and to
not really something I'm going to mull over too much.-Matthew Farina m...@mattfarina.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Matthew Farina m...@mattfarina.comDate: 01/14/2015 07:04AMSubject: [openstack-dev
Solaris is supported by node.js:
Solaris 32-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x86.tar.gz
Solaris 64-bit Binary:
http://nodejs.org/dist/v0.10.35/node-v0.10.35-sunos-x64.tar.gz
I think Solaris is no longer relevant
On Tue, Jan 13, 2015 at 7:13 PM, Drew Fisher
On 13/01/15 16:13, Drew Fisher wrote:
On 1/13/15 7:59 AM, Jeremy Stanley wrote:
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
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
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
deployment.
[...]
A requirement for testing _is_ a requirement for deployment. If it's
not
On 1/13/15 7:59 AM, Jeremy Stanley wrote:
On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
But, as far as I understand, node.js will become a development
requirement (and most probably a requirement for testing), but not for
deployment.
[...]
A requirement for testing
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
On 12/18/14 6:58 AM, Radomir Dopieralski wrote:
Hello,
revisiting the package management for the Horizon's static files again,
I would like to propose a particular solution. Hopefully it will allow
us to both simplify the whole setup, and use the popular tools for the
job, without losing
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
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
-Original Message-
From: Jeremy Stanley [mailto:fu...@yuggoth.org]
Sent: 08 January 2015 22:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [horizon] packaging problem production
build question
On 2015-01-08 15:11:24 -0700 (-0700
Bower is not for use in production environments. There will continue to be
two environment setup procedures, as there are today. For production,
deploy Horizon and its dependencies via system packages. For development
and testing leverage bower to pull the javascript resources, much as pip is
used
On 2015-01-08 15:11:24 -0700 (-0700), David Lyle wrote:
[...]
For those running CI environments, remote access will likely be
required for bower to work. Although, it seems something like
private-bower [1] could be utilized to leverage a local mirror
where access or network performance are
Thanks, Radomir. How much detail from this discussion should be captured in
the blueprint? I'm afraid I'm more familiar with the Python PEP process.
On Thu Jan 08 2015 at 11:38:57 PM Radomir Dopieralski
openst...@sheep.art.pl wrote:
On 06/01/15 01:53, Richard Jones wrote:
I think the only
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
On 06/01/15 01:53, Richard Jones wrote:
I think the only outstanding question is how developers and
non-packagers populate the bower_components directory - that is, how is
bower expected to be available for them?
I think following the Storyboard approach is a good idea: isolate a
I've been going over the packaging problem in an effort to see how we can
move to something better. Given the current proposal around bower I'm still
left with a production deployment question.
For a build environment sitting in isolation, unable to download from the
Internet including Github,
On 06/01/15 18:39, Lin Hua Cheng wrote:
Radomir,
The current version of Angular were using in Horizon still does not have
cookie and mock
packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data
We still need to do it the long way:
1. Update the
On 25/11/14 13:55, Julie Pichon wrote:
Hi folks,
You may have noticed a new job in the check queue for Horizon patches,
gate-horizon-dsvm-integration. This job runs the integration tests suite
from our repository. [1]
The job is marked as non-voting but *it is meant to pass.* The plan is
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
On 06/01/15 01:39, Tripp, Travis S wrote:
What Radomir proposes looks like it would greatly ease the process I am still
going through to get the latest angular available to Horizon for current
development. At the time of writing this, I’m still trying to get the
updated library through. I
Radomir,
The current version of Angular were using in Horizon still does not have
cookie and mock packages:
https://github.com/stackforge/xstatic-angular/tree/1.2.1.1/xstatic/pkg/angular/data
We still need to do it the long way:
1. Update the Angular version in global-requirements
2. Wait
Thanks, Radomir.
I originally started a patch on Horizon and was going to do that, but was
guided to update global requirements first.
I¹ll go ahead and redo that patch on Horizon.
-Travis
On 1/6/15, 2:00 AM, Radomir Dopieralski openst...@sheep.art.pl wrote:
On 06/01/15 01:39, Tripp, Travis S
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
This is a good proposal, though I'm unclear on how the
static_settings.py file is
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 05/01/15 00:35, Richard Jones wrote:
On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote:
On 20/12/14 21:25, Richard Jones wrote:
-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon
@lists.openstack.org
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack
-d...@lists.openstack.org
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
openst
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/
On
So just to be clear, as developers we:
1. have a bower.json listing the bower component to use,
2. use bower to fetch and install those to the bower_components directory
at the top level of the Horizon repos checkout, and
3. manually edit static_settings.py when we add a new bower component to
Hi,
There's been talks about Horizon switching to the normal .ini format
that all other projects have been using so far. It would really be
awesome if this could happen. Though I don't see the light at the end of
the tunnel. Quite the opposite way: the settings.py is every day
becoming more
1101 - 1200 of 1967 matches
Mail list logo
