Ok, Project-wise: 1) Pacemaker is not under our company's control, we can't assure its quality 2) it has terrible UX 3) it is not reliable
(3) is not evaluation of the project itself, but just a logical consequence of (1) and (2). As a part of escalation team I can say that it has cost our team thousands of man hours of head-scratching, staring at pacemaker logs which value are usually slightly below zero. Most of openstack services (in fact, ALL api servers) are stateless, they don't require any cluster management (also, they don't need to be moved in case of lack of space). Statefull services like neutron agents have their states being a function of db state and are able to syncronize it with the server without external "help". So now usage of pacemaker can be only justified for cases where service's clustering mechanism requires active monitoring (rabbitmq, galera) But even there, examples when we are better off without pacemaker are all around. Thanks, Eugene. On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko <svasile...@mirantis.com> wrote: > > On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov <enikano...@mirantis.com > > wrote: > >> No pacemaker for os services, please. >> We'll be moving out neutron agents from pacemaker control in 8.0, other >> os services don't need it too. >> > > could you please provide your arguments. > > > /sv > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev