<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/10 Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800:<br>
<div class="im">> And one more thing,<br>
><br>
> Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].<br>
> Its design is somewhat different and can be expressed by the following<br>
> formulae:<br>
><br>
> App -> Host (XenStore) <-> Guest Agent<br>
><br>
> (taken from the wiki [3])<br>
><br>
> It has an obvious disadvantage - it is hypervisor dependent and currently<br>
> implemented for Xen only. On the other hand such design should not have<br>
> shared facility vulnerability as Agent accesses the server not directly but<br>
> via XenStore (which AFAIU is compute node based).<br>
><br>
<br>
</div>I don't actually see any advantage to this approach. It seems to me that<br>
it would be simpler to expose and manage a single network protocol than<br>
it would be to expose hypervisor level communications for all hypervisors.<br></blockquote><div><br></div><div>I think the Rackspace agent design could be expanded as follows:</div><div><br></div><div>Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <-> XenStore <-> Guest Agent<br>
</div><div><br></div><div>That is somewhat speculative because if I understood it correctly the opened code covers only the second part of exchange:</div><div><br></div><div>Python API / CMD interface <-> XenStore <-> Guest Agent</div>
<div><br></div><div>Assuming I got it right:</div><div>While more complex, such design removes pressure from AMQP/ZeroMQ providers: on the 'Agent on Compute' you can easily control the amount of messages emitted by Guest with throttling. It is easy since such agent runs on a compute host. In the worst case, if it is happened to be abused by a guest, it affect this compute host only and not the whole segment of OpenStack.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>