<div style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial"><br><br><br><br><br><div style="position:relative;zoom:1">--<br><div>Best</div><div>    Li Tianqing</div><div style="clear:both"></div></div><div id="divNeteaseMailCard"></div><br><pre><br>At 2015-05-11 16:04:07, "Mark Kirkwood" <mark.kirkwood@catalyst.net.nz> wrote:
>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 
<div>>not display the right spirit for an open source project in my opinion!</div><div><br></div><div>i really want to vote to put trove back into stackforge for it can not give an clear deployment,</div><div> and it is always avoiding problem, not to face it. The service vm need get connect through the management should </div><div>talk about a lot. </div><div><br></div><div><br></div>>
>Regards
>
>Mark
>
>
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
</pre></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>