[TYPO3-doc] Documentation servers

[Steffen Gebert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Fabien,

okay, so fine for me to have one single server, at least in the beginning.

> About the communication btw the rendering and delivery server, there
was the idea of Steffen Gebert
> to use beanstalkd as a central place within our infrastructure. In
this regard, the rendering
> service would post a message (in the queue) that is going to trigger
the sync by the delivery
> service. Is this vision still valid?
>
> https://notes.typo3.org/p/beanstalkd

Yes, I'm still interested in having beanstalkd running. Christian
Trabold told me that the Logstash/Graylog2/Kibana server will bring us
an ActiveMQ, which could be used for everything else, too.

But still.. ActiveMQ looks really overloaded, while beanstalkd is really
a nice and easy solution.
(the only problem I see with beanstalkd is the lack of authentication,
but we can limit access to the IPs of our infrastructure)

Kind regards
Steffen

- -- 
Steffen Gebert
TYPO3 v4 Core Team Member
TYPO3 Server Administration Team Member

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org

I work for TYPO3 solely in my spare time. If you think that
my work helps you running your business, you are invited to
send me a donation via PayPal to this email address. Thanks

On 9/29/12 11:11 AM, Fabien Udriot wrote:
> Hello,
> 
> Is the rendering that (over)loading? ReST rendering is more lightweight in term of resource than the
> previous XSLT rendering we had. We could also make the process "nicer" so that it does not consume
> and monopolize all the memory / processor. Having two servers may sound as a more flexible approach
> in term of architecture design but has more complexity as you pointed out. The bottom line, is that
> I am not opposed two have two machines (rendering and delivery) but perhaps consider it as a nice to
> have and based on the experience we need one. As a first step, I would "work" on the same instance
> but nevertheless develop things to be *decoupled* in case we need to separate the service.
> 
>> - srv123.typo3.org (a.k.a. preview.docs.typo3.org) is currently used for everything, rendering the
>> documentation and serving it too.
>> - srv130.typo3.org (a.k.a. docs.typo3.org) is supposed to be the "final" docs server.
> 
> For me srv123 was a testing server where we can experiment and play around without worries. srv130
> would be the "true" one which renders the documentation and is set up by Chef (which is currently
> the case). At one point, srv123 would be erased and set up again with an image of srv130. If we
> decide to go from the start with two separate rendering / delivery servers, then we would set up a
> new one.
> 
>> We also need to consider database issues. We plan to have the FLOW3 application that coordinates the
>> whole show create database entries for each manual/version/language combo. If the rendering happens
>> on srv123 that entry will be created there, but srv130 needs to be aware of it too. There are
>> several solutions:
>>
>> - use the same DB (e.g. srv123 accesses the DB on srv130)
>> - use MySQL's replication tools (which may be tricky if srv130 starts collecting data ...
>> - have some form of messaging for one server to inform the other.
> 
> I think solution 1 (use the same DB) is the easiest as a first step.
> 
> About the communication btw the rendering and delivery server, there was the idea of Steffen Gebert
> to use beanstalkd as a central place within our infrastructure. In this regard, the rendering
> service would post a message (in the queue) that is going to trigger the sync by the delivery
> service. Is this vision still valid?
> 
> https://notes.typo3.org/p/beanstalkd
> 
> Fb.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQZtoyAAoJEIskG/rSlyw4/n4IAL1JOllt6cpeenfN0ZOLdxXT
tX3PemopwUGKXXT3rnLvgOkBphBLjKE0ZQ0bHWpL0oAG4oi11Youo3+Cyji7ubHy
FkQcNkERnkox6XzQqYT2GJmzRJaHaOy0SQM/SLxDgu26eQS4lR8jyvxDw8UW7SxR
J30Oey9bsT6pK9XwXgSa5ICuPYZcSA/w17yF2TxL4/VF9nihmPYJmrW181qacceP
A5uis7xlkOgERAUuH0fRRSNn/hLWsvlP3aqTArmucZQCb7XWpYwYYahnn7joFyl3
c8Z3jg7BqWmoEXRg93B1m2KEpyJWDDMgFjgEJ7Mc43L4756eajHYQmE0JyV+7Ok=
=XpCO
-----END PGP SIGNATURE-----