Open Stack

Clint, Kevin,

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.


Then returning to two major suggestions made:
 * Salt
 * Custom solution specific to our needs

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.

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.

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.

For given reasons I give favor to an agent based on oslo.messaging.

Thanks,

Dmitry



2013/12/11 Fox, Kevin M <kevin.fox at pnnl.gov>

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