[Mageia-dev] Servers downtime scheduled from Feb. 1 to 2 for maintenance

[Guillaume Rousse]

Le 31/01/2012 17:02, Thierry Vignaud a écrit :
> On 31 January 2012 15:09, Michael Scherer<misc at zarb.org>  wrote:
>>> some Mageia servers will be down from Wednesday Feb. 1st to Thursday
>>> Feb. 2nd for maintenance. Particularly, the following services will be
>>> unavailable:
>>> - our LDAP/user identity db,
>>> - build system,
>>> - Bugzilla,
>>> - all mailing-lists hosted on ml.mageia.org,
>>> - Wiki,
>>> - forums.
>> - transifex
>> - epoll
>> - svn, git
>> - youri web interface
>> - maint db
>>
>> in short, almost all web applications ( ie, hosted on alamut ), and the
>> build system. See http://svnweb.mageia.org/adm/puppet/manifests/nodes/
>>
>> And to complete :
>> - ldap will still work ( we do have a redundant setup, even if I have
>> not finished making sure everything use the 2nd ldap in case of failure
>> ), but readonly
>>
>> - mails will still be queued, so nothing should be lost
>>
>> We will announce on irc the exact moment when we plan to shutdown
>> servers.
>
> Announce it by mail too please.
>
> BTW, we should try to make more stuff redundancy. Withough going up to
> using DRBD
> for VM images, we could:
> - for SVN, it's easy to have at least a RO secondary server:
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
> if we stop write access on the master, we could wait for the slave to
> keep up with the latest commits, then make it RW
> when we need to stop the master.
> - for bugzilla, have two VM who perform master-master replication; we
> can this way
>   I'm not sure bugzilla support writing on both ends, but without
> performing load balancing,
>   when needed, we could stop access to the active one, wait for
> replication to finish, open
>   access on the second one
Given the few downtime sofar, is this really justified ? Complexity is 
rarely a synonym of high availability...

> - having more hypervisors and live migrating our VMs off the
> hypervisor we update so that
>    rebooting it doesn't impact service;
> - ...
This one seems perfectly reasonable, tough, as natively supported by 
hypervisors.

-- 
BOFH excuse #101:

Collapsed Backbone