Open Stack

Excerpts from Steven Dake's message of 2013-12-12 12:32:55 -0800:
> On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:
> > 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.
> >
> 
> An agent based on oslo.messaging is a potential security attack vector 
> and a possible scalability problem.  We do not want the guest agents 
> communicating over the same RPC servers as the rest of OpenStack

I don't think we're talking about agents talking to the exact same
RabbitMQ/Qpid/etc. bus that things under the cloud are talking to. That
would definitely raise some eyebrows. No doubt it will be in the realm
of possibility if deployers decide to do that, but so is letting your
database server sit on the same flat network as your guests.

I have a hard time seeing how using the same library is a security
risk though.