<div dir="ltr">Thanks everyone for this useful feedback (I guess it helps a lot to discuss before the PTG, so we don't even need to spend too much time on this topic).<div><br></div><div>1) Everyone agrees that undercloud HA isn't something we target now, therefore we won't switch to Pacemaker by default.</div><div>2) Pacemaker would still be a good option for multinode/HA standalone deployments, like we do for the overcloud.</div><div>3) Investigate how we could replace keepalived by something which would handle the VIPs used by HAproxy.</div><div><br></div><div>I've abandoned the patches that tested Pacemaker on the undercloud, and also the patch in tripleoclient for enable_pacemaker parameter, I think we don't need it for now. There is another way to enable Pacemaker for Standalone. I also closed the blueprint: <a href="https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default">https://blueprints.launchpad.net/tripleo/+spec/undercloud-pacemaker-default</a></div><div>and created a new one: <a href="https://blueprints.launchpad.net/tripleo/+spec/replace-keepalived-undercloud">https://blueprints.launchpad.net/tripleo/+spec/replace-keepalived-undercloud</a></div><div>Please take a look and let me know what you think.</div><div><br></div><div>It fits well with the Simplicity theme for Stein, and it'll help to remove services that we don't need anymore.</div><div><br></div><div>If any feedback on this summary, please go ahead and comment.</div><div>Thanks,</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 18, 2018 at 11:07 AM Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 2018-07-17 at 22:00 +0200, Michele Baldessari wrote:<br>
> Hi Jarda,<br>
> <br>
> thanks for these perspectives, this is very valuable!<br>
> <br>
> On Tue, Jul 17, 2018 at 06:01:21PM +0200, Jaromir Coufal wrote:<br>
> > Not rooting for any approach here, just want to add a bit of<br>
> > factors which might play a role when deciding which way to go:<br>
> > <br>
> > A) Performance matters, we should be improving simplicity and speed<br>
> > of<br>
> > deployments rather than making it heavier. If the deployment time<br>
> > and<br>
> > resource consumption is not significantly higher, I think it<br>
> > doesn’t<br>
> > cause an issue. But if there is a significant difference between<br>
> > PCMK<br>
> > and keepalived architecture, we would need to review that.<br>
> <br>
> +1 Should the pcmk take substantially more time then I agree, not<br>
> worth<br>
> defaulting to it. Worth also exploring how we could tweak things<br>
> to make the setup of the cluster a bit faster (on a single node we<br>
> can<br>
> lower certain wait operations) but full agreement on this point.<br>
> <br>
> > B) Containerization of PCMK plans - eventually we would like to run<br>
> > the whole undercloud/overcloud on minimal OS in containers to keep<br>
> > improving the operations on the nodes (updates/upgrades/etc). If<br>
> > because PCMK we would be forever stuck on BM, it would be a bit of<br>
> > pita. As Michele said, maybe we can re-visit this.<br>
> <br>
> So I briefly discussed this in our team, and while it could be<br>
> re-explored, we need to be very careful about the tradeoffs.<br>
> This would be another layer which would bring quite a bit of<br>
> complexity<br>
> (pcs commands would have to be run inside a container, speed<br>
> tradeoffs,<br>
> more limited possibilities when it comes to upgrading/updating, etc.)<br>
> <br>
> > C) Unification of undercloud/overcloud is important for us, so +1<br>
> > to<br>
> > whichever method is being used in both. But what I know, HA folks<br>
> > went<br>
> > to keepalived since it is simpler so would be good to keep in sync<br>
> > (and good we have their presence here actually) :)<br>
> <br>
> Right so to be honest, the choice of keepalived on the undercloud for<br>
> VIP predates me and I was not directly involved, so I lack the exact<br>
> background for that choice (and I could not quickly reconstruct it<br>
> from git<br>
> history). But I think it is/was a reasonable choice for what it needs<br>
> doing, although I probably would have picked just configuring the<br>
> extra<br>
> VIPs on the interfaces and have one service less to care about.<br>
> +1 in general on the unification, with the caveats that have been<br>
> discussed so far.<br>
<br>
I think it was more of that we wanted to use HAProxy for SSL<br>
termination and keepalived is a simple enough way to set this up.<br>
Instack-Undercloud has used HAProxy/keepalived for years in this<br>
manner.<br>
<br>
I think this came up recently because downstream we did not have a<br>
keepalived container. So it got a bit of spotlight on it as to why we<br>
were using it. We do have a keepalived RPM and its worked as it has for<br>
years already so as far as single node/undercloud setups go I think it<br>
would continue to work fine. Kolla has had and supports the keepalived<br>
container for awhile now as well.<br>
<br>
---<br>
<br>
Comments on this thread seem to cover 2 main themes to me.<br>
Simplification and the desire to use the same architecture as the<br>
Overcloud (Pacemaker). And there is some competition between them.<br>
<br>
For simplification: If we can eliminate keepalived and still use<br>
HAProxy (thus keeping the SSL termination features working) then I<br>
think that would be worth trying. Specifically can we eliminate<br>
Keepalived without swapping in Pacemaker? Michele: if you have ideas<br>
here lets try them!<br>
<br>
With regards to Pacemaker I think we need to make an exception. It<br>
seems way too heavy for single node setups and increases the complexity<br>
there for very little benefit. To me the shared architecture for<br>
TripleO is the tools we use to setup services. By using t-h-t to drive<br>
our setup of the Undercloud and All-In-One installers we are already<br>
gaining a lot of benefit here. Pacemaker is weird as it is kind of<br>
augments the architecture a bit (HA architecture). But Pacemaker is<br>
also a service that gets configured by TripleO. So it kind of falls<br>
into both categories. Pacemaker gives us features we need in the<br>
Overcloud at the cost of some extra complexity. And in addition to all<br>
this we are still running the Pacemaker processes themselves on<br>
baremetal. All this just to say we are running the same "architecture"<br>
on both the Undercloud and Overcloud? I'm not a fan.<br>
<br>
Dan<br>
<br>
<br>
<br>
> <br>
> > D) Undercloud HA is a nice have which I think we want to get to one<br>
> > day, but it is not in as big demand as for example edge<br>
> > deployments,<br>
> > BM provisioning with pure OS, or multiple envs managed by single<br>
> > undercloud. So even though undercloud HA is important, it won’t<br>
> > bring<br>
> > operators as many benefits as the previously mentioned<br>
> > improvements.<br>
> > Let’s keep it in mind when we are considering the amount of work<br>
> > needed for it.<br>
> <br>
> +100<br>
> <br>
> > E) One of the use-cases we want to take into account is expanind a<br>
> > single-node deployment (all-in-one) to 3 node HA controller. I<br>
> > think<br>
> > it is important when evaluating PCMK/keepalived <br>
> <br>
> Right, so to be able to implement this, there is no way around having<br>
> pacemaker (at least today until we have galera and rabbit).<br>
> It still does not mean we have to default to it, but if you want to<br>
> scale beyond one node, then there is no other option atm.<br>
> <br>
> > HTH<br>
> <br>
> It did, thanks!<br>
> <br>
> Michele<br>
> > — Jarda<br>
> > <br>
> > > On Jul 17, 2018, at 05:04, Emilien Macchi <<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>><br>
> > > wrote:<br>
> > > <br>
> > > Thanks everyone for the feedback, I've made a quick PoC:<br>
> > > <a href="https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-de" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-de</a><br>
> > > fault<br>
> > > <br>
> > > And I'm currently doing local testing. I'll publish results when<br>
> > > progress is made, but I've made it so we have the choice to<br>
> > > enable pacemaker (disabled by default), where keepalived would<br>
> > > remain the default for now.<br>
> > > <br>
> > > On Mon, Jul 16, 2018 at 2:07 PM Michele Baldessari <michele@acksy<br>
> > > <a href="http://n.org" rel="noreferrer" target="_blank">n.org</a>> wrote:<br>
> > > On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote:<br>
> > > > On Mon, Jul 16, 2018 at 11:42 AM Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a><br>
> > > > > wrote:<br>
> > > > [...]<br>
> > > > <br>
> > > > > The biggest downside IMO is the fact that our Pacemaker<br>
> > > > > integration is<br>
> > > > > not containerized. Nor are there any plans to finish the<br>
> > > > > containerization of it. Pacemaker has to currently run on<br>
> > > > > baremetal<br>
> > > > > and this makes the installation of it for small dev/test<br>
> > > > > setups a lot<br>
> > > > > less desirable. It can launch containers just fine but the<br>
> > > > > pacemaker<br>
> > > > > installation itself is what concerns me for the long term.<br>
> > > > > <br>
> > > > > Until we have plans for containizing it I suppose I would<br>
> > > > > rather see<br>
> > > > > us keep keepalived as an option for these smaller setups. We<br>
> > > > > can<br>
> > > > > certainly change our default Undercloud to use Pacemaker (if<br>
> > > > > we choose<br>
> > > > > to do so). But having keepalived around for "lightweight"<br>
> > > > > (zero or low<br>
> > > > > footprint) installs that work is really quite desirable.<br>
> > > > > <br>
> > > > <br>
> > > > That's a good point, and I agree with your proposal.<br>
> > > > Michele, what's the long term plan regarding containerized<br>
> > > > pacemaker?<br>
> > > <br>
> > > Well, we kind of started evaluating it (there was definitely not<br>
> > > enough<br>
> > > time around pike/queens as we were busy landing the bundles<br>
> > > code), then<br>
> > > due to discussions around k8s it kind of got off our radar. We<br>
> > > can<br>
> > > at least resume the discussions around it and see how much effort<br>
> > > it<br>
> > > would be. I'll bring it up with my team and get back to you.<br>
> > > <br>
> > > cheers,<br>
> > > Michele<br>
> > > -- <br>
> > > Michele Baldessari            <<a href="mailto:michele@acksyn.org" target="_blank">michele@acksyn.org</a>><br>
> > > C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D<br>
> > > <br>
> > > _________________________________________________________________<br>
> > > _________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:un" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:un</a><br>
> > > subscribe<br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > > <br>
> > > <br>
> > > -- <br>
> > > Emilien Macchi<br>
> > > _________________________________________________________________<br>
> > > _________<br>
> > > OpenStack Development Mailing List (not for usage questions)<br>
> > > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:un" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:un</a><br>
> > > subscribe<br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > <br>
> > <br>
> > ___________________________________________________________________<br>
> > _______<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsu" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsu</a><br>
> > bscribe<br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> <br>
> <br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div>