Comments inline. Monty Taylor writes:
> [...] > Might I suggest that if this is how people regularly deploy, that such a > class be included in trove proper, and that a config option be provided > like "use_tenant='name_of_tenant_to_use'" that would trigger the use of > the overridden novaclient class? > > I think asking an operator as a standard practice to override code in > remote.py is a bad pattern. I concur with this 100%. I've spent a lot of time over the past months answering questions to do with how folks can deploy Trove inside a single tenant. Since 'use_tenant' is one of the top recommended models for deployment, it makes sense that the code for it should reside in Trove proper. This would also be a good first step of documenting this as a recommended deployment option. I've opened a blueprint to look into this [1]. [1] https://blueprints.launchpad.net/trove/+spec/trove-single-tenant > [...] >> Most deployments of Trove that I am familiar with set up a separate >> RabbitMQ server in cloud that is used by Trove. It is not recommended to >> use the same infrastructure RabbitMQ server for Trove for security >> reasons. Also most deployments of Trove set up a private (neutron) >> network that the RabbitMQ server and guests are connected to, and all >> RPC messages are sent over this network. > > This sounds like a great chunk of information to potentially go into > deployer docs. Agree wholeheartedly. IMO right now, Trove has fairly decent developer docs, but it's deployment docs are somewhat on the sparse side. We're planning on tackling this during one of the Work sessions at the upcoming Liberty summit in Vancouver. > [...] Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev