settingsLogin | Registersettings

[openstack-dev] [horizon] static files handling, bower/

0 votes

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 too much of benefits of our current process.

The changes we would need to make are as follows:

  • get rid of XStatic entirely;
  • add to the repository a configuration file for Bower, with all the
    required bower packages listed and their versions specified;

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?

Thanks.

-Drew

asked Jan 12, 2015 in openstack-dev by Drew_Fisher (600 points)   1 3
retagged Jan 28, 2015 by admin

44 Responses

0 votes

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

responded Jan 13, 2015 by Matthias_Runge (6,700 points)   1 2 3
0 votes

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 tested, it's broken. If you're deploying software on a platform
where it can't be tested then you're simply hoping that it's not
broken, and that is almost certainly a false hope.
--
Jeremy Stanley

responded Jan 13, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

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 is a requirement for deployment. If it's
not tested, it's broken. If you're deploying software on a platform
where it can't be tested then you're simply hoping that it's not
broken, and that is almost certainly a false hope.

Exactly. We have to test this code base extensively before we package
it up for Solaris. Under no circumstances do we just blindly repackage
the releases and push them out to customers. Node.js is a total
incompatibility for Solaris. If upstream moves to using Bower we'll be
forced to look for alternatives at managing the JavaScript libraries.

Why were the libraries ripped from the Horizon codebase in the first
place? It seems to me they belong with the code using it.

-Drew

responded Jan 13, 2015 by Drew_Fisher (600 points)   1 3
0 votes

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.
--
Jeremy Stanley

responded Jan 13, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

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

responded Jan 13, 2015 by Matthias_Runge (6,700 points)   1 2 3
0 votes

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
deployment.
[...]

A requirement for testing is a requirement for deployment. If it's
not tested, it's broken. If you're deploying software on a platform
where it can't be tested then you're simply hoping that it's not
broken, and that is almost certainly a false hope.

Exactly. We have to test this code base extensively before we package
it up for Solaris. Under no circumstances do we just blindly repackage
the releases and push them out to customers. Node.js is a total
incompatibility for Solaris. If upstream moves to using Bower we'll be
forced to look for alternatives at managing the JavaScript libraries.

I have some bad news for you. Horizon already uses node.js for running
jshint on its JavaScript files on the gate. Simply because there is no
other alternative. You are welcome to work on and propose a better solution.

--
Radomir Dopieralski

responded Jan 14, 2015 by Radomir_Dopieralski (3,720 points)   2 3
0 votes

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 <drew.fisher at oracle.com> 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
deployment.
[...]

A requirement for testing is a requirement for deployment. If it's
not tested, it's broken. If you're deploying software on a platform
where it can't be tested then you're simply hoping that it's not
broken, and that is almost certainly a false hope.

Exactly. We have to test this code base extensively before we package
it up for Solaris. Under no circumstances do we just blindly repackage
the releases and push them out to customers. Node.js is a total
incompatibility for Solaris. If upstream moves to using Bower we'll be
forced to look for alternatives at managing the JavaScript libraries.

Why were the libraries ripped from the Horizon codebase in the first
place? It seems to me they belong with the code using it.

-Drew


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 14, 2015 by Anton_Zemlyanov (680 points)   1
0 votes

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 made was that without SPARC (probably only the
64-bit variant these days but still) support, that's not enough.
Solaris targets more than just Intel's processors. (So does Linux
for that matter!)

I think Solaris is no longer relevant

The Solaris developer community probably disagrees with you on this
point. ;)
--
Jeremy Stanley

responded Jan 14, 2015 by Jeremy_Stanley (56,700 points)   3 5 7
0 votes

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
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

I won't stoop to comment on this statement other than to say Solaris is
quite relevant to Oracle, Oracle's customers and Oracle's partners.

-Drew

responded Jan 14, 2015 by Drew_Fisher (600 points)   1 3
0 votes

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 be executed
by users is in browser rather than server side. The important execution
environment is in their browser.

The second environment is production. In that case the system packages
would be used. What's still unclear is who creates and maintains those
packages since many of them don't exist today.

On Wed, Jan 14, 2015 at 10:14 AM, Drew Fisher <drew.fisher at oracle.com>
wrote:

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
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

I won't stoop to comment on this statement other than to say Solaris is
quite relevant to Oracle, Oracle's customers and Oracle's partners.

-Drew


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 14, 2015 by Matthew_Farina (2,160 points)   1 4
...