Open Stack

Hi Pradeep,

On Mon, Dec 12, 2016 at 02:51:59PM +0100, Giulio Fidente wrote:
> On 12/09/2016 04:49 PM, Pradeep Kilambi wrote:
> >I would like to get some thoughts on $Subject. This came up when i was
> >discussing the standalone roles for telemetry. Currently when we deploy
> >redis in tripleo, its a pacemaker managed service. So if we were to
> >deploy telemetry services on a dedicated node we could. But redis will
> >have to be on a another node? (assuming we dont want to pull in
> >pacemaker on to telemetry nodes).

Ok so with the composable HA work [1] you should be able to split out
the redis service on to dedicated nodes and these nodes can be either
full pacemaker cluster members or only have the pacemaker-remote
service.

> currently redis instances are not configured as a redis cluster but use the
> master/slave replication model instead and pacemaker is taking care of
> electing/relocating the redis master as needed
> 
> there shouldn't be any dependency on the redis profile for the telemetry
> roles, they should instead just point at the redis_vip
> 
> the redis_vip is always guaranteed (by haproxy) to point to the redis master
> 
> >With most services moved out of pacemaker in Newton, I think its time to
> >move redis as well? Are there any constraints in moving redis to be
> >managed by systemd? Looking at how we do it, It should be easily movable
> >to systemd? Can we consider doing this for Ocata?
> 
> I think we could look at using the redis cluster which allows multiple
> masters, but I am not sure this can happen in Ocata ... yet again, there
> shouldn't be in the telemetry roles any dependency on redis itself
> 
> if we were to use the cluster mode the only difference would probably be
> that the redis_vip will start balancing requests across the nodes

In general I am in favour to split out redis from pacemaker. There is
the question that in theory we'd have two potentially separate quorums,
but I think that with redis this should not be a big problem.

Maybe let's start with a prototype and see how things look and iterate
from there? I think it is a bit late for ocata, but we could at least
start the work without changing the defaults (i.e. let the operator
override the tripleo::service with a redis base profile instead of the
pacemaker one)

Does that make sense,
Michele

[1] https://review.openstack.org/#/q/topic:bp/composable-ha
-- 
Michele Baldessari            <michele at acksyn.org>
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D