<div dir="ltr">The "whitebox container implementation", is that the ability to manage resources inside the VMs from the same ha-cluster that is managing the VM instances, i.e., the pacemaker-remote agent? I've not tried that; so far I've stuck to the stock SL6.4 RPMs... But that could help help some -- dependencies would be on services, not VMs, and location preferences tie services to VMs. But in some cases, like my db0 instance, I'll not have another VM to take over the service. Presumably restarting services on already-running VMs would be faster, though.<div>
<br></div><div style>Are people successfully using pacemaker-remote in production? Documentation seems a bit sparse (though I think enough to set it up)...</div><div style><br></div><div style>/Lindsay</div><div style><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 13, 2013 at 3:19 PM, Vladislav Bogdanov <span dir="ltr"><<a href="mailto:bubble@hoster-ok.com" target="_blank">bubble@hoster-ok.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">13.05.2013 19:28, Lindsay Todd wrote:<br>
> Folks: On my cluster built on SL6.4, I need to deploy some VMs that<br>
> depend on other VMs:<br>
><br>
</div>> * db0 has no dependendencies<br>
> * ldap01,ldap02 require db0 to be running -- ordering constraint, but<br>
<div class="im">> no collocation (other than we'll use a collocation constraint to<br>
> recommend ldap01, ldap02 run on different physical hosts)<br>
</div>> * bq01, bq02 depend on at least one of ldap01, ldap02 running<br>
<div class="im">><br>
> At this point, I've got a test arrangement corresponding to only the<br>
> db01 and ldap01 resources being deployed, but it is enough to expose a<br>
> problem...<br>
><br>
> The constraints themselves are quite simple. The trouble arises when we<br>
> try to migrate VMs. As the "Pacemaker Configuration Explained" manual<br>
> states: "The resource must not, directly or indirectly, depend on any<br>
> primitive or group resources." What is the reason for this restriction?<br>
> Sure enough, I can't migrate ldap01. I can migrate db01 successfully,<br>
> though it does force a stop/start on ldap01 (though that is really<br>
> unnecessary, since network connections would have been preserved).<br>
><br>
> So is there a way to:<br>
><br>
</div>> * At least get the bq01, bq02 VMs able to migrate, though they depend<br>
> on other VMs?<br>
> * Be able to get the ldap01,ldap02 VMs to migrate, without forcing the<br>
<div class="im">> bq01,bq02 VMs to stop/start (unless both get stopped the restarted)?<br>
</div>> * Be able to get the db01 resource to migrate, without forcing the<br>
<div class="im">> other dependents to stop/start, unless it is actually stop/started?<br>
<br>
</div>It seems to be exactly what was discussed a year ago here<br>
(<a href="http://www.mail-archive.com/pacemaker@oss.clusterlabs.org/msg12050.html" target="_blank">http://www.mail-archive.com/pacemaker@oss.clusterlabs.org/msg12050.html</a>)<br>
and then on bugtracker (<a href="http://bugs.clusterlabs.org/show_bug.cgi?id=5055" target="_blank">http://bugs.clusterlabs.org/show_bug.cgi?id=5055</a>).<br>
<br>
You may look at whitebox container implementation though, that may fit<br>
your needs. I didn't play with it yet, so that is just a guess.<br>
<br>
Alternative way would be to play with tickets as with cluster-wide<br>
attributes, but they are quite limited for that task I think.<br>
<br>
Vladislav<br>
<br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" target="_blank">http://bugs.clusterlabs.org</a><br>
</blockquote></div><br></div>