Hi,
On Mon, Oct 5, 2015 at 3:03 PM, Alex Schultz <aschu...@mirantis.com> wrote: > On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov > <enikano...@mirantis.com> wrote: > > Ok, > > > > Project-wise: > > 1) Pacemaker is not under our company's control, we can't assure its > quality > Mirantis does control neither Rabbitmq or Galera. Mirantis cannot assure their quality as well. > 2) it has terrible UX > It looks like personal opinion. I'd like to see surveys or operators feedbacks. Also, this statement is not constructive as it doesn't have alternative solutions. > > 3) it is not reliable > I would say openstack services are not HA reliable. So OCF scripts are reaction of operators on these problems. Many of them have child-ish issues from release to release. Operators made OCF scripts to fix these problems. A lot of openstack are stateful, so they require some kind of stickiness or synchronization. Openstack services doesn't have simple health-check functionality so it's hard to say it's running well or not. Sighup is still a problem for many of openstack services. Etc/etc So, let's be constructive here. > > > > I disagree with #1 as I do not agree that should be a criteria for an > open-source project. Considering pacemaker is at the core of our > controller setup, I would argue that if these are in fact true we need > to be using something else. I would agree that it is a terrible UX > but all the clustering software I've used fall in this category. I'd > like more information on how it is not reliable. Do we have numbers to > backup these claims? > > > (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 it's not an issue with moving services so much as being able to > stop the services when a condition is met. Have we tested all OS > services to ensure they do function 100% when out of disk space? I > would assume that glance might have issues with image uploads if there > is no space to handle a request. > > > 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. > > > > After I sent this email, I had further discussions around the issues > that I'm facing and it may not be completely related to disk space. I > think we might be relying on the expectation that the local rabbitmq > is always available but I need to look into that. Either way, I > believe we still should continue to discuss this issue as we are > managing services in multiple ways on a single host. Additionally I do > not believe that we really perform quality health checks on our > services. > > Thanks, > -Alex > > > > > > 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 > > > > __________________________________________________________________________ > 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
