From tarek at ziade.org  Tue Jun  5 11:30:37 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 05 Jun 2012 11:30:37 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
Message-ID: <4FCDD1BD.6070508@ziade.org>

Hey

I am doing this experimentation where the WGSI server is not started 
with an host/port or a unix socket, but rather a FD value,
corresponding to a socket already bound by the parent process.

The server would then just accept new connection on the FD, using 
socket.fromfd() to get a socket object back,
and forget about all the binding work.

Here's a prototype based on wsgiref : 
https://github.com/tarekziade/chaussette

The goal I have is to be able to just spawn web workers using subprocess 
and take care myself  of the process
management part.  I wrote a blog post on my motivations here : 
http://blog.ziade.org/2012/06/12/shared-sockets-in-circus
if you want more background.

Anyways, the idea I wanted to bring here was the following:

most web servers out there support regular host/port or Unix Socket, 
which are usually the "unix:" prefix followed by a path on the system.

What if web servers had these two standards *and* a new one which would 
be a "fd:" prefix.

For instance, we would start server foo with:

$ foo --fd:12:localhost:8080

Where 12 is the fd number the foo server would use for getting the 
socket, and "localhost:8080" would just be there
as an information to be able to fill some WGSI headers that requires it.

 From there I could just spawn "foo" and pass to it socket.fileno()

Thoughts ?

Cheers
Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120605/493b5448/attachment.html>

From techtonik at gmail.com  Tue Jun  5 11:41:51 2012
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 5 Jun 2012 12:41:51 +0300
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <4FCDD1BD.6070508@ziade.org>
References: <4FCDD1BD.6070508@ziade.org>
Message-ID: <CAPkN8xKZE_vyN0YsO-8NC9cmUuhxCuzb7BYGtwR5GjmucwzjUQ@mail.gmail.com>

On Tue, Jun 5, 2012 at 12:30 PM, Tarek Ziad? <tarek at ziade.org> wrote:
>
> Thoughts ?

I've skimmed over the text and couldn't find any user story. What is
the end goal?

What is the responsibility of web server, web app and your controlling app?
Who should control keep-alives and connection drops?

From roberto at unbit.it  Tue Jun  5 11:46:36 2012
From: roberto at unbit.it (Roberto De Ioris)
Date: Tue, 5 Jun 2012 11:46:36 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <4FCDD1BD.6070508@ziade.org>
References: <4FCDD1BD.6070508@ziade.org>
Message-ID: <09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>


Il giorno 05/giu/2012, alle ore 11:30, Tarek Ziad? ha scritto:

> Hey 
> 
> I am doing this experimentation where the WGSI server is not started with an host/port or a unix socket, but rather a FD value, 
> corresponding to a socket already bound by the parent process. 
> 
> The server would then just accept new connection on the FD, using socket.fromfd() to get a socket object back, 
> and forget about all the binding work. 
> 
> Here's a prototype based on wsgiref : https://github.com/tarekziade/chaussette 
> 
> The goal I have is to be able to just spawn web workers using subprocess and take care myself  of the process 
> management part.  I wrote a blog post on my motivations here : http://blog.ziade.org/2012/06/12/shared-sockets-in-circus 
> if you want more background. 
> 
> Anyways, the idea I wanted to bring here was the following: 
> 
> most web servers out there support regular host/port or Unix Socket, which are usually the "unix:" prefix followed by a path on the system. 
> 
> What if web servers had these two standards *and* a new one which would be a "fd:" prefix. 
> 
> For instance, we would start server foo with: 
> 
> $ foo --fd:12:localhost:8080 
> 
> Where 12 is the fd number the foo server would use for getting the socket, and "localhost:8080" would just be there 
> as an information to be able to fill some WGSI headers that requires it. 
> 
> From there I could just spawn "foo" and pass to it socket.fileno() 
> 
> Thoughts ? 
> 

This is the approach used by fastcgi (even if only on file descriptor 0), old inetd-style daemons, and newer upstart and systemd daemons.

Gunicorn can already bind (or better, accept) from file descriptors specifying an environment variable. uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup,
and working on generic file descriptor or inet/upstart/systemd socket activation.

The vast majority of modern systems expects the file descriptor number on an environment variable:

upstart: UPSTART_FDS
systemd: LISTEN_FDS

Circus, could follow the same behaviour, but i do not know if a standard will be required for that.

Regarding the --fd:12:localhost:8080 syntax, is redundant as you can get the name of the socket mapped to a file descriptor
with getsockname:

http://linux.die.net/man/2/getsockname

--
Roberto De Ioris
http://unbit.it
JID: roberto at jabber.unbit.it


From tarek at ziade.org  Tue Jun  5 12:26:24 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 05 Jun 2012 12:26:24 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
Message-ID: <4FCDDED0.7030602@ziade.org>

On 6/5/12 11:46 AM, Roberto De Ioris wrote:
> ...
> Gunicorn can already bind (or better, accept) from file descriptors specifying an environment variable.
I don't think you can start gunicorn using a file descriptor, or I 
failed to do it. The best I was able to do was to create a small wsgi server
using Gunicorn as a lib.

Gunicorn uses an environment variable when it respawns workers but it 
does not offer it as a public option as far as I understand how it works

> uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup,
> and working on generic file descriptor or inet/upstart/systemd socket activation.
I did not find a way to start it using a provided fd -- they are 
plethora of options though, maybe I missed it
> The vast majority of modern systems expects the file descriptor number on an environment variable:
>
> upstart: UPSTART_FDS
> systemd: LISTEN_FDS
Yes, this seem fairly standard.
>
> Circus, could follow the same behaviour, but i do not know if a standard will be required for that.
The goal of the standard is just to be able to place any wsgi server out 
there and have it working out of the box.

So far I was not able to run an existing wsgi server like this without 
changing its code because they
all make the assumption they will be run with a host and port.


> Regarding the --fd:12:localhost:8080 syntax, is redundant as you can get the name of the socket mapped to a file descriptor
> with getsockname:
>
> http://linux.die.net/man/2/getsockname
Will look into this again, I had an issue trying to do it.

Thanks for the feedback!

>
> --
> Roberto De Ioris
> http://unbit.it
> JID: roberto at jabber.unbit.it
>


From bchesneau at gmail.com  Tue Jun  5 12:31:05 2012
From: bchesneau at gmail.com (Benoit Chesneau)
Date: Tue, 5 Jun 2012 12:31:05 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <4FCDDED0.7030602@ziade.org>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
	<4FCDDED0.7030602@ziade.org>
Message-ID: <CAJNb-9otQuhTN+y98PevY0vDYa=s8z+5NAYs21hhR-NF1YETRA@mail.gmail.com>

On Tue, Jun 5, 2012 at 12:26 PM, Tarek Ziad? <tarek at ziade.org> wrote:
> On 6/5/12 11:46 AM, Roberto De Ioris wrote:
>>
>> ...
>>
>> Gunicorn can already bind (or better, accept) from file descriptors
>> specifying an environment variable.
>
> I don't think you can start gunicorn using a file descriptor, or I failed to
> do it. The best I was able to do was to create a small wsgi server
> using Gunicorn as a lib.
>
> Gunicorn uses an environment variable when it respawns workers but it does
> not offer it as a public option as far as I understand how it works
>
>
export GUNICORN_FD=<your fd>

and then gunicorn will use this file descriptor when it starts.

But it should be possible to pass it directly using a config option if
it's needed.

- beno?t

From tarek at ziade.org  Tue Jun  5 12:31:08 2012
From: tarek at ziade.org (=?UTF-8?B?VGFyZWsgWmlhZMOp?=)
Date: Tue, 05 Jun 2012 12:31:08 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <CAPkN8xKZE_vyN0YsO-8NC9cmUuhxCuzb7BYGtwR5GjmucwzjUQ@mail.gmail.com>
References: <4FCDD1BD.6070508@ziade.org>
	<CAPkN8xKZE_vyN0YsO-8NC9cmUuhxCuzb7BYGtwR5GjmucwzjUQ@mail.gmail.com>
Message-ID: <4FCDDFEC.6040203@ziade.org>

On 6/5/12 11:41 AM, anatoly techtonik wrote:
> On Tue, Jun 5, 2012 at 12:30 PM, Tarek Ziad?<tarek at ziade.org>  wrote:
>> Thoughts ?
> I've skimmed over the text and couldn't find any user story. What is
> the end goal?
use a web server as a standalone, isolated process, with nothing but a 
single main thread that gets request then send back response.

then have Circus do all the processes management.

> What is the responsibility of web server, web app and your controlling app?

- The web server accept() connections on a socket and transforms a 
request into a wsgi environ it passes to a wsgi application  [Meinheld, 
Bjoern, Whatever..]
- The web app is a classical wsgi application that handles 
start_response and return a list of strings   [the application that 
follows the wsgi standard]
- The controlling app manages the life of the sockets and also manage 
the life of web app processes   [Circus]

> Who should control keep-alives and connection drops?

I don't know I did not get into those details yet.


Cheers
Tarek


From tarek at ziade.org  Tue Jun  5 12:33:32 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 05 Jun 2012 12:33:32 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <CAJNb-9otQuhTN+y98PevY0vDYa=s8z+5NAYs21hhR-NF1YETRA@mail.gmail.com>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
	<4FCDDED0.7030602@ziade.org>
	<CAJNb-9otQuhTN+y98PevY0vDYa=s8z+5NAYs21hhR-NF1YETRA@mail.gmail.com>
Message-ID: <4FCDE07C.3000102@ziade.org>

On 6/5/12 12:31 PM, Benoit Chesneau wrote:
> On Tue, Jun 5, 2012 at 12:26 PM, Tarek Ziad?<tarek at ziade.org>  wrote:
>> On 6/5/12 11:46 AM, Roberto De Ioris wrote:
>>> ...
>>>
>>> Gunicorn can already bind (or better, accept) from file descriptors
>>> specifying an environment variable.
>> I don't think you can start gunicorn using a file descriptor, or I failed to
>> do it. The best I was able to do was to create a small wsgi server
>> using Gunicorn as a lib.
>>
>> Gunicorn uses an environment variable when it respawns workers but it does
>> not offer it as a public option as far as I understand how it works
>>
>>
> export GUNICORN_FD=<your fd>
>
> and then gunicorn will use this file descriptor when it starts.
>
> But it should be possible to pass it directly using a config option if
> it's needed.
What you be great then is to be able to run Gunicorn as a single process 
without having it forking workers,
because the main goal is to be able to manage that process directly in 
Circus -- e.g. skip all the arbiter part in Gunicorn

My attempt at this was this hack : 
https://github.com/tarekziade/chaussette/commit/075003a24ffe92253da60aafc6f99062e0af267d#diff-3

Cheers
Tarek

>
> - beno?t


From tarek at ziade.org  Tue Jun  5 14:00:45 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Tue, 05 Jun 2012 14:00:45 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <9705AF77-9078-4B91-BF49-6F46C88F24B8@unbit.it>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
	<4FCDDED0.7030602@ziade.org>
	<9705AF77-9078-4B91-BF49-6F46C88F24B8@unbit.it>
Message-ID: <4FCDF4ED.7080707@ziade.org>

On 6/5/12 1:56 PM, Roberto De Ioris wrote:
>>> uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup,
>>> and working on generic file descriptor or inet/upstart/systemd socket activation.
>> I did not find a way to start it using a provided fd -- they are plethora of options though, maybe I missed it
>
> it is automatic if the fd is the zero one, otherwise you have to "authenticate" it adding a --socket/--http-socket/--fastcgi-socket directive
> mapping to the address (this is required for avoiding uWSGI inheriting unrelated sockets, like the ones created by ssh-agents and whatever you want).
>
> For example if you map fd 17 to 192.168.1.1:4040 you have to run uwsgi with
>
> --socket 192.168.1.1:4040
>
> it will find fd 17 mapped to a socket, and it will know the socket is authorized to be used.
>
> Other components take the special fd://<n>  syntax (like the various routers) but i do not think you are intersted in them

Great, thanks, will try this

>
>
>>> The vast majority of modern systems expects the file descriptor number on an environment variable:
>>>
>>> upstart: UPSTART_FDS
>>> systemd: LISTEN_FDS
>> Yes, this seem fairly standard.
>>> Circus, could follow the same behaviour, but i do not know if a standard will be required for that.
>> The goal of the standard is just to be able to place any wsgi server out there and have it working out of the box.
> if this is your objective i suggest you to follow the inetd/fastcgi style approach and use file descriptor 0 as the communication socket.
> Flup and uWSGI will work over this automatically. Gunicorn will work simply adding GUNICORN_FD=0
>
> Adding another env-var will mean each server will need to add a condition for that (like upstart and systemd)
The thing is, the main process might bind several sockets, and have 
various subprocesses linked to specific ones, so I guess the uWsgi --socket
approach is the most straightforward

Thanks for all the info

> --
> Roberto De Ioris
> http://unbit.it
> JID: roberto at jabber.unbit.it
>


From roberto at unbit.it  Tue Jun  5 13:56:03 2012
From: roberto at unbit.it (Roberto De Ioris)
Date: Tue, 5 Jun 2012 13:56:03 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <4FCDDED0.7030602@ziade.org>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
	<4FCDDED0.7030602@ziade.org>
Message-ID: <9705AF77-9078-4B91-BF49-6F46C88F24B8@unbit.it>


Il giorno 05/giu/2012, alle ore 12:26, Tarek Ziad? ha scritto:

> On 6/5/12 11:46 AM, Roberto De Ioris wrote:
>> ...
>> Gunicorn can already bind (or better, accept) from file descriptors specifying an environment variable.
> I don't think you can start gunicorn using a file descriptor, or I failed to do it. The best I was able to do was to create a small wsgi server
> using Gunicorn as a lib.
> 
> Gunicorn uses an environment variable when it respawns workers but it does not offer it as a public option as far as I understand how it works


benoit has already answered about that

> 
>> uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup,
>> and working on generic file descriptor or inet/upstart/systemd socket activation.
> I did not find a way to start it using a provided fd -- they are plethora of options though, maybe I missed it


it is automatic if the fd is the zero one, otherwise you have to "authenticate" it adding a --socket/--http-socket/--fastcgi-socket directive
mapping to the address (this is required for avoiding uWSGI inheriting unrelated sockets, like the ones created by ssh-agents and whatever you want).

For example if you map fd 17 to 192.168.1.1:4040 you have to run uwsgi with

--socket 192.168.1.1:4040 

it will find fd 17 mapped to a socket, and it will know the socket is authorized to be used.

Other components take the special fd://<n> syntax (like the various routers) but i do not think you are intersted in them



>> The vast majority of modern systems expects the file descriptor number on an environment variable:
>> 
>> upstart: UPSTART_FDS
>> systemd: LISTEN_FDS
> Yes, this seem fairly standard.
>> 
>> Circus, could follow the same behaviour, but i do not know if a standard will be required for that.
> The goal of the standard is just to be able to place any wsgi server out there and have it working out of the box.

if this is your objective i suggest you to follow the inetd/fastcgi style approach and use file descriptor 0 as the communication socket.
Flup and uWSGI will work over this automatically. Gunicorn will work simply adding GUNICORN_FD=0

Adding another env-var will mean each server will need to add a condition for that (like upstart and systemd)

--
Roberto De Ioris
http://unbit.it
JID: roberto at jabber.unbit.it


From tarek at ziade.org  Wed Jun  6 08:54:36 2012
From: tarek at ziade.org (=?ISO-8859-1?Q?Tarek_Ziad=E9?=)
Date: Wed, 06 Jun 2012 08:54:36 +0200
Subject: [Web-SIG] Starting Web Servers using socket FDs
In-Reply-To: <4FCDF4ED.7080707@ziade.org>
References: <4FCDD1BD.6070508@ziade.org>
	<09F83521-5C5F-46D1-962D-F66D9B734F07@unbit.it>
	<4FCDDED0.7030602@ziade.org>
	<9705AF77-9078-4B91-BF49-6F46C88F24B8@unbit.it>
	<4FCDF4ED.7080707@ziade.org>
Message-ID: <4FCEFEAC.1010004@ziade.org>

Just a follow-up on this:

an --socket fd://xx option was added to uWsgi, and meinheld can now be 
started with a socket_fd option,

I will try to propose the same option in other web servers.

Thanks to Roberto & Yutaka for these changes

Cheers
Tarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120606/f4218eea/attachment.html>

From alex at grep.ro  Thu Jun  7 10:08:24 2012
From: alex at grep.ro (Alex Morega)
Date: Thu, 7 Jun 2012 11:08:24 +0300
Subject: [Web-SIG] Web application packaging
Message-ID: <C48F0A1D-7385-48E1-B2D1-F54C679CCB85@grep.ro>

Hello!

There was a discussion here, about an year ago, about ways to deploy WSGI applications to servers. What is the status? What tools are out there, being currently developed, other than Buildout, Fabric and Silver Lining?

Cheers,
-- Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120607/569a94ed/attachment.pgp>

From matt at whoosh.ca  Thu Jun  7 23:09:01 2012
From: matt at whoosh.ca (Matt Chaput)
Date: Thu, 07 Jun 2012 17:09:01 -0400
Subject: [Web-SIG] Large, fixed latency on every wsgiref response
Message-ID: <4FD1186D.4020307@whoosh.ca>

I'm using Paste script to configure a wsgiref server on Windows. And I'm 
seeing some weird stuff.

On Safari, every request gets almost exactly 1 second of latency tacked 
on (the amount listed in the network diagnostics pane varies per 
request: 1.03s, 1.09s, 1.08s, 1.12s...). Every request. Even when the 
actual response takes practically no time (e.g. a 304), the connection 
latency is huge.

On Chrome, the latency is smaller (around 300ms) and not on every 
request. Hovering over a request with the latency in Chrome's network 
pane shows the following information:

   DNS Lookup: 1ms
   Connecting: 302ms
   Sending   : 0
   Waiting   : 15ms
   Receiving : 27ms

Firefox also shows a large (1s) "connecting" time for some requests and 
no delay on other requests in the Firebug net pane.

The only reason page load is barely tolerable is because at least with 
threading some of the delays are in parallel, but it's still slow.

I have no idea what's going on here. Any ideas?

Thanks,

Matt

From graham.dumpleton at gmail.com  Fri Jun  8 02:19:05 2012
From: graham.dumpleton at gmail.com (Graham Dumpleton)
Date: Fri, 8 Jun 2012 10:19:05 +1000
Subject: [Web-SIG] Large, fixed latency on every wsgiref response
In-Reply-To: <4FD1186D.4020307@whoosh.ca>
References: <4FD1186D.4020307@whoosh.ca>
Message-ID: <CALRNbkCuwm=jFjj0z759rN7y7tJNFN4uwi2-6CpfGDX9kZXFtw@mail.gmail.com>

Are you using an IP address or DNS name?

http://appletoolbox.com/2010/09/fix-safari-slowness-stalled-page-loads-by-disabling-dns-prefetching/
http://support.apple.com/kb/TS2296

Graham

On 8 June 2012 07:09, Matt Chaput <matt at whoosh.ca> wrote:
> I'm using Paste script to configure a wsgiref server on Windows. And I'm
> seeing some weird stuff.
>
> On Safari, every request gets almost exactly 1 second of latency tacked on
> (the amount listed in the network diagnostics pane varies per request:
> 1.03s, 1.09s, 1.08s, 1.12s...). Every request. Even when the actual response
> takes practically no time (e.g. a 304), the connection latency is huge.
>
> On Chrome, the latency is smaller (around 300ms) and not on every request.
> Hovering over a request with the latency in Chrome's network pane shows the
> following information:
>
> ?DNS Lookup: 1ms
> ?Connecting: 302ms
> ?Sending ? : 0
> ?Waiting ? : 15ms
> ?Receiving : 27ms
>
> Firefox also shows a large (1s) "connecting" time for some requests and no
> delay on other requests in the Firebug net pane.
>
> The only reason page load is barely tolerable is because at least with
> threading some of the delays are in parallel, but it's still slow.
>
> I have no idea what's going on here. Any ideas?
>
> Thanks,
>
> Matt
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com

From graham.dumpleton at gmail.com  Fri Jun  8 03:41:37 2012
From: graham.dumpleton at gmail.com (Graham Dumpleton)
Date: Fri, 8 Jun 2012 11:41:37 +1000
Subject: [Web-SIG] Large, fixed latency on every wsgiref response
In-Reply-To: <70250E21-7FE0-4899-8861-799152AE1DFA@whoosh.ca>
References: <4FD1186D.4020307@whoosh.ca>
	<CALRNbkCuwm=jFjj0z759rN7y7tJNFN4uwi2-6CpfGDX9kZXFtw@mail.gmail.com>
	<70250E21-7FE0-4899-8861-799152AE1DFA@whoosh.ca>
Message-ID: <CALRNbkC2K9H4bDxQ3k4YUWVvAYujePWGLqxVNVEFUjteXP9kNA@mail.gmail.com>

If on Windows then try using 127.0.0.1 instead of localhost.

There are known issues with Windows whereby localhost actually
resolves to an IPV6 address of ::1 rather than IPV4 address of
127.0.0.1. For reasons I can't remember, this causes an initial delay
in connections.

Graham

On 8 June 2012 11:28, Matt Chaput <matt at whoosh.ca> wrote:
>> Are you using an IP address or DNS name?
>>
>> http://appletoolbox.com/2010/09/fix-safari-slowness-stalled-page-loads-by-disabling-dns-prefetching/
>> http://support.apple.com/kb/TS2296
>
> "localhost", and this is on Windows, not Mac OS X. Also, as mentioned, this problem shows up to different degrees in Safari, Chrome, and Firefox. At least for me.
>
> At first glance the CherryPy server seems better and Waitress seems not to have the problem, but I haven't devoted too much time to testing them yet.
>
> Matt
>

From ianb at colorstudy.com  Sat Jun  9 07:35:19 2012
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 9 Jun 2012 00:35:19 -0500
Subject: [Web-SIG] Web application packaging
In-Reply-To: <C48F0A1D-7385-48E1-B2D1-F54C679CCB85@grep.ro>
References: <C48F0A1D-7385-48E1-B2D1-F54C679CCB85@grep.ro>
Message-ID: <CAHtfchoMHrWOjY0hWkys-AbogT0qqgA+3CpzXgZ3Zq810Y9oJQ@mail.gmail.com>

I've been doodling around with things, but honestly I've deployed zero
Python apps in the last year, so lacking a use case of any kind I find
myself rather unfocused, even though I feel a degree of confidence about
the approach.

Anyway, my indirect doodling is here: https://github.com/ianb/apppkg/

I'm interested in a cross-language approach, which means a lot of process
isolation, and that's where things are vague right now ? it would probably
be a bit easier if that didn't mean process isolation with Python on both
sides, because that's where it gets vague.


On Thu, Jun 7, 2012 at 3:08 AM, Alex Morega <alex at grep.ro> wrote:

> Hello!
>
> There was a discussion here, about an year ago, about ways to deploy WSGI
> applications to servers. What is the status? What tools are out there,
> being currently developed, other than Buildout, Fabric and Silver Lining?
>
> Cheers,
> -- Alex
>
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/ianb%40colorstudy.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120609/aa39f33a/attachment.html>

From alex at grep.ro  Wed Jun 20 22:09:05 2012
From: alex at grep.ro (Alex Morega)
Date: Wed, 20 Jun 2012 23:09:05 +0300
Subject: [Web-SIG] Sarge - a web application hosting tool
Message-ID: <FC9B05BC-31BC-4FEE-A404-50A027ADF6FD@grep.ro>

Hi folks,

I've been tinkering with a tool for hosting web applications. It aims to make deployment easier by automating configuration on the server: starting up processes, linking them to databases, configuring the front-end web server, etc. Many ideas are borrowed from Ian Bicking's proposal from April 2011[1].

http://alex-morega.github.com/Sarge/

On the server, Sarge reads a "hosting" configuration file for each "deployment". This describes resources available to the application (e.g. database), along with a domain name, public HTTP port, etc. The "guest" application is deployed with its own configuration file that provides a urlmap, service requirements, entry points. These configuration files are still underspecified; apppkg[2] may be a good model for them.

Processes are started with supervisor[3], and nginx is assumed as http server. For the application, services (e.g. database access) will be provided via plugins, but the plugin API is not very useful yet.

The code is thoroughly covered in unit tests. There is a small set of integration tests that run against a vagrant[4] virtual machine. Also there is the beginnings of a documentation, including a tutorial[5] that should give you an idea of the deployment workflow.

Feedback is most welcome! I've started work out of personal frustration of having to copy/paste fabric commands between projects, but I'd love for this tool to be widely useful.

Cheers,
-- Alex

[1] http://mail.python.org/pipermail/web-sig/2011-April/005009.html
[2] https://github.com/ianb/apppkg/
[3] http://supervisord.org/
[4] http://vagrantup.com/
[5] http://alex-morega.github.com/Sarge/tutorial.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120620/3470883b/attachment.pgp>