Hi Julien, I there are valid reasons why we can consider MQ approach for communicating with VM agents. The first obvious reason is scalability and performance. User can ask infrastructure to create 1000 VMs and configure them. With HTTP approach it will lead to a corresponding number of connections to a REST API service. Taking into account that cloud has multiple clients the load on infrastructure will be pretty significant. You can address this with introducing Load Balancing for each service, but it will significantly increase management overhead and complexity of OpenStack infrastructure.
The second issue is connectivity and security. I think that in typical production deployment VMs will not have an access to OpenStack infrastructure services. It is fine for core infrastructure services like Nova and Cinder as they do not work directly with VM. But it makes a huge problem for VM level services like Savanna, Heat, Trove and Murano which have to be able to communicate with VMs. The solution here is to put an intermediary to create a controllable way of communication. In case of HTTP you will need to have a proxy with QoS and Firewalls or policies, to be able to restrict an access to some specific URLS or services, to throttle the number of connections and bandwidth to protect services from DDoS attacks from VM sides. In case of MQ usage you can have a separate MQ broker for communication between service and VMs. Typical brokers have throttling mechanism, so you can protect service from DDoS attacks via MQ. Using different queues and even vhosts you can effectively segregate different tenants. For example we use this approach in Murano service when it is installed by Fuel. The default deployment configuration for Murano produced by Fuel is to have separate RabbitMQ instance for Murano<->VM communications. This configuration will not expose the OpenStack internals to VM, so even if someone broke the Murano rabbitmq instance, the OpenSatck itself will be unaffected and only the Murano part will be broken. Thanks Georgy On Thu, Mar 6, 2014 at 7:46 AM, Julien Danjou <jul...@danjou.info> wrote: > On Thu, Mar 06 2014, Dmitry Mescheryakov wrote: > > > So, messaging people, what is your opinion on that idea? I've already > > raised that question in the list [1], but seems like not everybody who > > has something to say participated. So I am resending with the > > different topic. For example, yesterday we started discussing security > > of the solution in the openstack-oslo channel. Doug Hellmann at the > > start raised two questions: is it possible to separate different > > tenants or applications with credentials and ACL so that they use > > different queues? My opinion that it is possible using RabbitMQ/Qpid > > management interface: for each application we can automatically create > > a new user with permission to access only her queues. Another question > > raised by Doug is how to mitigate a DOS attack coming from one tenant > > so that it does not affect another tenant. The thing is though > > different applications will use different queues, they are going to > > use a single broker. > > What about using HTTP and the REST APIs? What's what supposed to be the > world facing interface of OpenStack. If you want to receive messages, > it's still possible to use long polling connections. > > -- > Julien Danjou > ;; Free Software hacker > ;; http://julien.danjou.info > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
