[openstack-dev] Unified Guest Agent proposal

Clint Byrum clint at fewbar.com
Tue Dec 10 19:55:34 UTC 2013


Excerpts from Dmitry Mescheryakov's message of 2013-12-10 11:08:58 -0800:
> 2013/12/10 Clint Byrum <clint at fewbar.com>
> 
> > Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800:
> > > And one more thing,
> > >
> > > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].
> > > Its design is somewhat different and can be expressed by the following
> > > formulae:
> > >
> > > App -> Host (XenStore) <-> Guest Agent
> > >
> > > (taken from the wiki [3])
> > >
> > > It has an obvious disadvantage - it is hypervisor dependent and currently
> > > implemented for Xen only. On the other hand such design should not have
> > > shared facility vulnerability as Agent accesses the server not directly
> > but
> > > via XenStore (which AFAIU is compute node based).
> > >
> >
> > I don't actually see any advantage to this approach. It seems to me that
> > it would be simpler to expose and manage a single network protocol than
> > it would be to expose hypervisor level communications for all hypervisors.
> >
> 
> I think the Rackspace agent design could be expanded as follows:
> 
> Controller (Savanna/Trove) <-> AMQP/ZeroMQ <-> Agent on Compute host <->
> XenStore <-> Guest Agent
> 
> That is somewhat speculative because if I understood it correctly the
> opened code covers only the second part of exchange:
> 
> Python API / CMD interface <-> XenStore <-> Guest Agent
> 
> Assuming I got it right:
> 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.
> 

This still requires that we also write a backend to talk to the host
for all virt drivers. It also means that any OS we haven't written an
implementation for needs to be hypervisor-aware. That sounds like a
never ending battle.

If it is just a network API, it works the same for everybody. This
makes it simpler, and thus easier to scale out independently of compute
hosts. It is also something we already support and can very easily expand
by just adding a tiny bit of functionality to neutron-metadata-agent.

In fact we can even push routes via DHCP to send agent traffic through
a different neutron-metadata-agent, so I don't see any issue where we
are piling anything on top of an overstressed single resource. We can
have neutron route this traffic directly to the Heat API which hosts it,
and that can be load balanced and etc. etc. What is the exact scenario
you're trying to avoid?



More information about the OpenStack-dev mailing list