<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-14 22:11 GMT+02:00 Sylvain Thénault <span dir="ltr"><<a href="mailto:sylvain.thenault@logilab.fr" target="_blank">sylvain.thenault@logilab.fr</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 14 mai 13:22, Aurélien Campéas wrote:<br>
> The first patch set replaces the in-memory sessions with an<br>
> in-database CWSession object. The details lay in the patch set. (There<br>
> also comes a slight simplification of the web auth stack architecture)<br>
<br>
</div>as said as a comment on the patch, I'm -1 on database stored session by default.<br></blockquote><div><br></div><div>Why ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

IMO we should have an api flexible enough to allow session storage wherever you<br></blockquote><div><br></div><div>There are already a wealth of APIs concerning sessions, and I do not plan to add more.<br></div><div>Quite a bit the opposite in practice (dont worry, I removed just a little :)).<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
want (memory, file, database, redis/memcached, whatever), but by default it<br></blockquote><div><br></div><div>Firstly I introduce the persistent session base functionnality.<br></div><div>Secondly I provide a simple cache API with several well-polished backends<br>
</div><div>for in-memory, memcached, redis, whatnot).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
should be as simple as possible</blockquote><div><br></div><div>Simple it is :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and so in memory,</blockquote>
<div><br></div><div>This does not follow.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> with cubes to provide other<br>
backends. Also having CWSession in the core schema makes it nearly impossible to<br>
skip (you'll always at least have a table to store sessions in the database).<br></blockquote><div><br></div>Impossible to what ? I don't understand.<br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
<br>
> What is to be done<br>
> ------------------<br>
><br>
> * baseline distributed task handling in the core<br>
><br>
> The missing feature will be the handling of "tasks", currently<br>
> provided on a single-instance basis, and with instances configuration<br>
> variables.<br>
><br>
> For instance (pun assumed), session expiration should be handled by<br>
> such a task, but we don't want all instances to compete anarchically<br>
> for this.<br>
><br>
> Another one: the `vcsfile` cube should be able to schedule a periodic<br>
> mercurial-repositories-synchronisation task, with multiple instances,<br>
> without configuration option hacks (which are costly not only in terms<br>
> of code complexity but also in sysadmin time), without chaos<br>
> happening.<br>
><br>
> What is proposed is the integration of most of the `worker` cube, plus<br>
> some missing bits, within the core. This will provide:<br>
><br>
> * a database-enforced serialized synchronisation device<br>
> * a distributed task API<br>
><br>
> The missing bits are related to how a process "worker" will be elected<br>
> to perform a task (it could be by explicit configuration, for complex<br>
> deployments, but a zero-configuration lightweight default should be<br>
> provided).<br>
<br>
</div>I would rather go a way that remove things from cw core... Couldn't we rely on an<br></blockquote><div><br></div><div>I agree in general, but there is no dogma, is there ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

existing tool such as celery for this? We could even let some simple tasks such<br></blockquote><div><br></div><div>I have had a look at celery, and while it looks like the  taskly package to use<br>for advanced stuff, it doesnt seem yet to play well with zmq and tends to<br>
</div><div>bring rabbitmq or sqlalchemy or redis or whatever...<br><br></div><div>The worker cube thing is a bit simple and brutal, it won't be everything to everyone,<br>but I believe it works and can be made fit in no time.<br>
<br></div><div>I definitely think celery would find a place in a cube though.<br><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
as sessions cleaning be executed by a tool such as cron. </blockquote><div><br></div><div>We should strive to minimize the amount of sysadmin work for developpers,<br></div><div>real sysadmins and Coporate IT organisations people.<br>
<br></div><div>The thing must work out-of-the box.<br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There would be a litle<br>
more sysadmin to do, but less complexity in the instance configuration and<br>
overall more flexible/understandable things.<br></blockquote><div><br></div><div>I can't see how.<br></div><div><br></div><div>Regards,<br></div><div>Aurélien.<br></div></div><br></div></div>