Dmitry, I understand that :) The only hypervisor dependency it has is how it communicates with the host, while this can be extended and turned into a binding, so people could connect to it in multiple ways.
The real value, as I see it, is which features this guest agent already implements and the fact that this is a mature code base. Thanks, Vladik ----- Original Message ----- > From: "Dmitry Mescheryakov" <dmescherya...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Thursday, 12 December, 2013 12:27:47 PM > Subject: Re: [openstack-dev] Unified Guest Agent proposal > > Vladik, > > Thanks for the suggestion, but hypervisor-dependent solution is exactly what > scares off people in the thread :-) > > Thanks, > > Dmitry > > > 2013/12/11 Vladik Romanovsky < vladik.romanov...@enovance.com > > > > > Maybe it will be useful to use Ovirt guest agent as a base. > > http://www.ovirt.org/Guest_Agent > https://github.com/oVirt/ovirt-guest-agent > > It is already working well on linux and windows and has a lot of > functionality. > However, currently it is using virtio-serial for communication, but I think > it can be extended for other bindings. > > Vladik > > ----- Original Message ----- > > From: "Clint Byrum" < cl...@fewbar.com > > > To: "openstack-dev" < openstack-dev@lists.openstack.org > > > Sent: Tuesday, 10 December, 2013 4:02:41 PM > > 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@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
