Gabriel.Hurley at nebula
May 26, 2012, 7:57 PM
Post #9 of 19
(339 views)
Permalink
|
To Adam Young's points: as I noted, that was an off-the-cuff implementation option since you asked, but the subject of how future websocket-related features might or might not be implemented isn't the subject at hand.
In terms of the current discussion (Horizon's use of node.js for the purpose of LESS and possible future options), it sounds like for the Folsom release cycle a reasonable compromise is to move forward with node.js and LESS for development and recommend it for production as long as we can work with downstream distros to make sure they have options in cases where they currently do not support node. These options would include things such as helping them to provide a compiled stylesheet that can be served statically as part of their distro package when they go to ship Folsom.
Any further leveraging of node.js in the Folsom cycle would then be treated similarly: make it customizable/make it configurable/provide a reasonable fallback behavior for distros who don't yet support node.js.
That's the proposal on the table as far as I understand it.
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula.com [at] lists [mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of Adam Young
Sent: Friday, May 25, 2012 5:34 PM
To: openstack [at] lists
Subject: Re: [Openstack] Fwd: Nodejs in horizon
On 05/25/2012 07:15 PM, Gabriel Hurley wrote:
I can't speak for other use cases as I haven't directly investigated them, but to those questions:
Apache was only an example. Any webserver that uses WSGI (whether mod_wsgi or otherwise) doesn't support websockets. As for pushing to get it into the WSGI standard, there's already work in that direction but amending the standard and *then* getting all the implementations to update, etc. is a LONG way off.
If (disclaimer: these are not final details, I'm just blue-sky throwing out possibilities) we were implementing websockets for the dashboard via node.js, we would likely run node.js with socket.io and the "express" web framework so it acts as its own async server on its own port. This is a pretty common setup, very lightweight, and with minimal dependencies. It would run side-by-side with the traditional webserver (Apache/nginx) for wsgi/python. This is down the road for Horizon, though.
This is not a good idea. We already have a proliferation of ports. This is a SELinux Nightmare: some of these are already owned by applications other than ours.
Websockets does not and should not be run on a separate port. All of our applications should be able to run on the standard ports of 80 for HTTP and 443 for HTTPS. For websockets, that is ws on 80 and 443 for wss.
Node.js is a fine architecture, but throwing another server side language into the pot once the application is already built on Python is not a sound decision. Now developers need to think in two languages for server side scripting, and that is not a good idea.
Don't get me wrong, I've done my share of Javascript: prior to Openstack, I spent over a year doing straight Javascript programming for the Web UI for FreeIPA. But that was Client side Javascript, and I for one would like to limit Javascript's role to the web browser where we cannot avoid it.
Like it or lump it, the server side language for Openstack is Python. We already have a framework for Event driven programming there, and we should stick with it. Adding Server side Javascript into the picture needlessly complicates things.
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula.com [at] lists<mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists> [mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of Adam Young
Sent: Friday, May 25, 2012 3:57 PM
To: openstack [at] lists<mailto:openstack [at] lists>
Subject: Re: [Openstack] Fwd: Nodejs in horizon
We are using Eventlet as a Webserver, not apache, and Eventlet does have websocket support.
When using Node.js do we need to run an alternative Server than the Apache HTTPD for Dashboard?
We are looking at Websockets issues for noVNC already. One Potential approach is to use an Apache module for Websockets: I am aware that mod_wsgi will not handle it. Perhaps getting websocket support into mod_wsgi is a better way forward?
On 05/25/2012 01:54 PM, Gabriel Hurley wrote:
To elucidate a few more points from people's responses so far:
* All the python socket.io backends are immature projects, and there's a GAPING flaw with them all: WSGI (the interface between web servers and Python) doesn't support the handshake features that websocket communication requires. The WSGI standard was drafted before websockets was a thing. There's a gevent lib that supports it, but it's also immature and doesn't play nice with Apache, etc. Deployment will get *really* iteresting trying to use socket.io with Python. I've tried. ;-)
* Pypy *is* fast (I know several of the main contributors) but it's as big a decision to use Pypy as it is to use node, but that only affects performance. It doesn't make Django any more suited to real-time communication. Pypy is also a major new dependency that's not packaged and it changes a lot of things. It's also used by several orders of magnitude fewer people than node.js currently, so security there is a whole different concern.
* Tornado and Twisted are both non-blocking web servers in Python, but both projects have serious peculiarities which we could dive into separately. And ultimately they're not tools any of the Horizon contributors I've talked to so far are interested in working with, which in an open source community is pretty much a death knell for that solution.
* John P's point about Javascript already being a core language used in Horizon is well taken. I get the "server-side javascript is different" mindset, but language-bashing for the sake of "I don't like javascript" is no more helpful than Python people bashing Ruby. The fact is that Javascript as a language is extremely similar to Python in its syntax and construction (I often write my JS to PEP8 standards), and though it's not as readable as Python (what is?), there's no reason JS code is inherently bad. Bad programmers write bad code. Bad frameworks encourage bad code. Node.js suffers from neither.
* I'm 100% in favor of code-bundling only being a short-term solution. When a reasonable number of distros package things like LESS, dropping our bundled version in favor of a properly-versioned package would be awesome. The fewer things to maintain the better.
All the best,
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula.com [at] lists<mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists> [mailto:openstack-bounces+gabriel.hurley=nebula.com [at] lists] On Behalf Of John Postlethwait
Sent: Friday, May 25, 2012 9:23 AM
To: Simon G.; Jay Pipes
Cc: openstack [at] lists<mailto:openstack [at] lists>
Subject: Re: [Openstack] Fwd: Nodejs in horizon
Hi Everyone,
Sorry if I've missed anything below, this thread has become rather fragmented and messy (at least in my email clients) but I will try to address the main points I have seen so far:
* Just so that everyone is aware, the lessc parser that is bundled in Horizon, while executable, is NOT a binary. It is, in fact, just a 140 line JS file, you can see the code here: https://review.openstack.org/#/c/7367/4/bin/less/lessc
* The reason I have bundled it within the Horizon code, as Gabriel mentioned, is to assuage any version mismatches or install issues with LESS itself that may arise from having yet another dependency on top of NodeJS that needs manual steps to install. Also, the LESS package that exists for Ubuntu is a year out of date, and other distributions do not even have packages for it. I would love if we could rely on the OS' packages to assuage this dependency, but we cannot, so this is the simplest and best-working solution I could think of. It will be no more difficult to maintain than jQuery, or Bootstrap, in the Horizon code-base...
* As for distribution support, Node can be installed on just about anything, see here: https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
* As to the concerns about "it not being Python" or "JavaScript has been abused." Well, all I can say to that is no, it is not Python, and yes, some developers write terrible and abusive code with JavaScript. I'm sure I could find horrid/abusive Python somewhere as well, but doing so would not preclude our reasons to use it in OpenStack. Misuse of a tool is not a reason to fear the tool itself, if that were so none of us would use any language, ever. Not to mention, we already use a ton of JS in Horizon... I'm not introducing JavaScript to Horizon for the first time or anything here.
I'm sure I've missed some good points, but this thread is a mess and is difficult to sort through... :P
-John Postlethwait
________________________________
From: openstack-bounces+john.postlethwait=nebula.com [at] lists<mailto:openstack-bounces+john.postlethwait=nebula.com [at] lists> [openstack-bounces+john.postlethwait=nebula.com [at] lists<mailto:openstack-bounces+john.postlethwait=nebula.com [at] lists>] on behalf of Simon G. [semyazz [at] gmail<mailto:semyazz [at] gmail>]
Sent: Friday, May 25, 2012 7:40 AM
To: Jay Pipes
Cc: openstack [at] lists<mailto:openstack [at] lists>
Subject: Re: [Openstack] Fwd: Nodejs in horizon
Maybe I've misuderstood something, but I've tried to give examples of other backends than node.js which can make use of mentioned before socket.io<http://socket.io> and can be used to implement realtime communication. I just wanted to minimize use of node.js. Hmm... I'm still talking about realtime communication, but it was only mentioned as an example and it's not even listed as a feature anywhere. So maybe my part in this topic is pointless. I'll be silent from now :)
Cheers,
On Fri, May 25, 2012 at 3:20 PM, Jay Pipes <jaypipes [at] gmail<mailto:jaypipes [at] gmail>> wrote:
On 05/25/2012 08:41 AM, Simon G. wrote:
Hello,
I don't want to be rude, but fast research about point *3c* and sockets
=> PyPi search
<http://pypi.python.org/pypi?%3Aaction=search&term=socket.io&submit=search>
* http://pypi.python.org/pypi/SocketTornad.IO/
* http://pypi.python.org/pypi/TornadIO2/0.0.3 ,
https://github.com/MrJoes/tornadio2
* http://pypi.python.org/pypi/django-socketio/0.3.3
* http://mrjoes.github.com/2011/12/15/sockjs-bench.html
How mature are those projects? I don't know. I'm not an expert in
python. I'm just trying to find alternatives to Node.js if almost
everything is in python. I'm just testing Openstack and right now I'm
trying to add something to nova, but I really like horizon and if it's
possible, I'd like to avoid node.js. I'm not a fan of this technology
even if it's popular and fast, because I just have some doubts about
Javascript and its maintainability.
Hi Simon,
socket.io<http://socket.io> is a Javascript library :) 3 of the 4 projects you reference above use socket.io<http://socket.io>.
Best,
-jay
_______________________________________________
Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
--
Semy
_______________________________________________
Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists<mailto:openstack [at] lists>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
|
