Open Stack

--

Best
    Li Tianqing



At 2015-05-11 16:50:05, "Flavio Percoco" <flavio at redhat.com> wrote:
>On 11/05/15 16:32 +0800, Li Tianqing wrote:
>>
>>
>>
>>
>>
>>--
>>Best
>>    Li Tianqing
>>
>>
>>
>>At 2015-05-11 16:04:07, "Mark Kirkwood" <mark.kirkwood at 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
>>>not display the right spirit for an open source project in my opinion!
>
>While I agree with this last paragraph....
>>
>>i really want to vote to put trove back into stackforge for it can not give an clear deployment,
>
>... I must point out this is *NOT* the way this community (OpenStack)
>works.
>
>This mailing list exists to discuss things in the open, make sure we
>can have wide and constructive discussions to make things like the ones
>discussed in this thread come out so that they can be improved,
>documented and made public for the sake of usability, operation and
>adoption.
>
>> and it is always avoiding problem, not to face it. The service vm need get connect through the management should
>>talk about a lot.
>
>It's now on Trove team's - or other people's - hands to help
>find/implement a better solution for the problem pointed out in this
>thread and make the product better.
>

>Let's collaborate,


Fine.


>Flavio
>
>>
>>
>>>
>>>Regards
>>>
>>>Mark
>>>
>>>
>>>
>>>
>>>__________________________________________________________________________
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>-- 
>@flaper87
>Flavio Percoco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150511/b9fa739f/attachment.html>