<div dir="ltr">Clint, Kevin,<div><br></div><div>Thanks for reassuring me :-) I just wanted to make sure that having direct access from VMs to a single facility is not a dead end in terms of security and extensibility. And since it is not, I agree it is much simpler (and hence better) than hypervisor-dependent design.</div>


<div><br></div><div><br></div><div>Then returning to two major suggestions made:</div>
<div> * Salt</div><div> * Custom solution specific to our needs </div><div><br></div><div>The custom solution could be made on top of oslo.messaging. That gives us RPC working on different messaging systems. And that is what we really need - an RPC into guest supporting various transports. What it lacks at the moment is security - it has neither authentication nor ACL.</div>
<div><br></div><div>Salt also provides RPC service, but it has a couple of disadvantages: it is tightly coupled with ZeroMQ and it needs a server process to run. A single transport option (ZeroMQ) is a limitation we really want to avoid. OpenStack could be deployed with various messaging providers, and we can't limit the choice to a single option in the guest agent. Though it could be changed in the future, it is an obstacle to consider.</div>
<div><br></div><div>Running yet another server process within OpenStack, as it was already pointed out, is expensive. It means another server to deploy and take care of, +1 to overall OpenStack complexity. And it does not look it could be fixed any time soon.</div>
<div><br></div><div>For given reasons I give favor to an agent based on oslo.messaging. </div><div><br></div><div>Thanks,</div><div><br></div><div>Dmitry</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/12/11 Fox, Kevin M <span dir="ltr"><<a href="mailto:kevin.fox@pnnl.gov" target="_blank">kevin.fox@pnnl.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah. Its likely that the metadata server stuff will get more scalable/hardened over time. If it isn't enough now, lets fix it rather then coming up with a new system to work around it.<br>
<br>
I like the idea of using the network since all the hypervisors have to support network drivers already. They also already have to support talking to the metadata server. This keeps OpenStack out of the hypervisor driver business.<br>

<br>
Kevin<br>
<br>
________________________________________<br>
From: Clint Byrum [<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>]<br>
Sent: Tuesday, December 10, 2013 1:02 PM<br>
To: openstack-dev<br>
<div class="im HOEnZb">Subject: Re: [openstack-dev] Unified Guest Agent proposal<br>
<br>
</div><div class="HOEnZb"><div class="h5">Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37 -0800:<br>
> >> What is the exact scenario you're trying to avoid?<br>
><br>
> It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server<br>
> (Salt / Our own self-written server). Looking at the design, it doesn't<br>
> look like the attack could be somehow contained within a tenant it is<br>
> coming from.<br>
><br>
<br>
We can push a tenant-specific route for the metadata server, and a tenant<br>
specific endpoint for in-agent things. Still simpler than hypervisor-aware<br>
guests. I haven't seen anybody ask for this yet, though I'm sure if they<br>
run into these problems it will be the next logical step.<br>
<br>
> In the current OpenStack design I see only one similarly vulnerable<br>
> component - metadata server. Keeping that in mind, maybe I just<br>
> overestimate the threat?<br>
><br>
<br>
Anything you expose to the users is "vulnerable". By using the localized<br>
hypervisor scheme you're now making the compute node itself vulnerable.<br>
Only now you're asking that an already complicated thing (nova-compute)<br>
add another job, rate limiting.<br>
<br>
_______________________________________________<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>
<br>
_______________________________________________<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>