Eugene
With all due respect to you and other OpenStack developers, I as a system
administrator do not believe when someone says that something is working
that way. Actually, what I would prefer to do is to stress-test these
services on their 'statelessness'. Currently we have l3-agent not so
On Tue, Oct 6, 2015 at 4:22 PM, Vladimir Kuklin
wrote:
> Eugene
>
> For example, each time that you need to have one instance (e.g. master
> instance) of something non-stateless running in the cluster.
>
Right. This is theoretical. Practically, there are no such services
> 2) I think you misunderstand what is the difference between
> upstart/systemd and Pacemaker in this case. There are many cases when you
> need to have syncrhonized view of the cluster. Otherwise you will hit
> split-brain situations and have your cluster misfunctioning. Until
> OpenStack
Eugene
I would prefer to tackle your points in the following way:
1) Regarding rabbitmq - you and me both know that this a major flaw in how
OpenStack operates - it uses message broker in very unoptimal way sending
lots of unneeded data through when it actually may not send it. So far we
Eugene
For example, each time that you need to have one instance (e.g. master
instance) of something non-stateless running in the cluster. You are right
that currently lots of things are fixed already - heat engine is fine, for
example. But I still see this issue with l3 agents and I will not
>
>
>>
> Mirantis does control neither Rabbitmq or Galera. Mirantis cannot assure
> their quality as well.
>
Correct, and rabbitmq was always the pain in the back, preventing any *real
*enterprise usage of openstack where reliability does matter.
> > 2) it has terrible UX
>>
>
> It looks like
Good morning gentlemen!
Alex raised very good question. Thank you very much! We have 3 init systems
right now. Some services use SystemV, some services use upstart, some
services are under pacemaker. Personally, I would like to have pacemaker as
pid 1 to replace init [1]. However, I would like to
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.
E.
5 окт. 2015 г. 12:01 пользователь "Sergii Golovatiuk" <
sgolovat...@mirantis.com> написал:
> Good morning gentlemen!
>
> Alex raised very good question.
On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
wrote:
> 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
>
I disagree with #1 as I do not agree that should be a criteria
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
On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov
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
Hi,
On Mon, Oct 5, 2015 at 3:03 PM, Alex Schultz wrote:
> On Mon, Oct 5, 2015 at 5:56 AM, Eugene Nikanorov
> wrote:
> > Ok,
> >
> > Project-wise:
> > 1) Pacemaker is not under our company's control, we can't assure its
> quality
>
Mirantis does
On Fri, Oct 2, 2015 at 10:50 PM, Alex Schultz wrote:
> So I was working on Bug 1493520 which is about what happens when a
> controller runs out of space. For this I came up with a solution[1] to
> leverage pacemaker to migrate services away from the controller when
> it
13 matches
Mail list logo