On 09/05/15 02:28, Monty Taylor wrote:
On 05/08/2015 03:45 AM, Nikhil Manchanda wrote:
Comments and answers inline.
Li Tianqing writes:
[...]
1) why we put the trove vm into user's tenant, not the trove's
tenant? User can login on that vm, and that vm must connect to
rabbitmq. It is quite insecure.
what's about put the tenant into trove tenant?
While the default configuration of Trove in devstack puts Trove guest
VMs into the users' respective tenants, it's possible to configure Trove
to create VMs in a single "Trove" tenant. You would do this by
overriding the default novaclient class in Trove's remote.py with one
that creates all Trove VMs in a particular tenant whose user credentials
you will need to supply. In fact, most production instances of Trove do
something like this.
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.
2) Why there is no trove mgmt cli, but mgmt api is in the code?
Does it disappear forever ?
The reason for this is because the old legacy Trove client was rewritten
to be in line with the rest of the openstack clients. The new client
has bindings for the management API, but we didn't complete the work on
writing the shell pieces for it. There is currently an effort to
support Trove calls in the openstackclient, and we're looking to
support the management client calls as part of this as well. If this is
something that you're passionate about, we sure could use help landing
this in Liberty.
3) The trove-guest-agent is in vm. it is connected by taskmanager
by rabbitmq. We designed it. But is there some prectise to do this?
how to make the vm be connected in vm-network and management
network?
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.
I'd like to +1 this.
It is misleading that the standard documentation (and the devstack
setup) describes a configuration that is unsafe/unwise to use in
production. This is surely unusual to say the least! Normally when test
or dev setups use unsafe configurations the relevant docs clearly state
this - and describe how it should actually be done.
In addition the fact that several extended question threads were
required to extract this vital information is ...disappointing, and does
not display the right spirit for an open source project in my opinion!
Regards
Mark
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
