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

Tue Jan 31 17:50:16 CET 2012

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
+