<div class="gmail_quote">On Sat, Jun 30, 2012 at 1:51 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sat, Jun 30, 2012 at 3:06 AM, Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>> wrote:<br>
> Hm, Pacemaker/Corosync *inside* the VM will add the Service-IP to the local<br>
> ethernet<br>
> interface, and thus, the outside OpenStack components do not know about.<br>
><br>
> Using a dedicated floating IP pool for service IPs might feel like a great<br>
> solution, but<br>
> OpenStack is not the one to manage who gets what IP - but Corosync/Pacemaker<br>
> inside<br>
> the KVM instances. :-)<br>
><br>
> Anyone an idea how to solve this?<br>
<br>
</div>It sounds like you want to add explicit support to pacemaker to deal<br>
with openstack fixed addresses. Then you could run with rfc1918<br>
floating addresses, and then have pacemaker/corosync reassign the<br>
(external) fixed address when consensus changes.<br>
<br>
Think of the openstack fixed address control plane in a similar way to<br>
ifconfig. You should even be able to script it up yourself; you'd need<br>
to add your openstack creds to the HA images though.<br></blockquote><div><br></div><div>Hey,</div><div><br></div><div>that's a really great idea, and IMHO apparently the only way to not</div><div>interfere with OpenStack internals too much.</div>
<div><br></div><div>So I need to create a new resource agent that represents a floating IP.</div><div>If I succeed, I'll share that script then. :)</div></div><br><div>Cheers,</div><div>Christian Parpart.</div>