Open Stack

1) Would you expect a deployer to create this tenant prior to configuring Trove in this manner?
Yes, i think we can use tenant 'services'


2) What impact would you expect this to have on quotas? For example, should this tenant just have “infinite” quota for CPU/storage etc or should the resources be proxied back to the tenant creating the Trove instance?
I think infinite would be prefer. We only conculate database instance and it's flavor. We do not care which tenant the nova instance is in. 


3) Provide clear documentation as to how the separate messaging network is setup between the Trove control plane and the guest instances.
    Is it the final way to set up  trove? For you have limit on user to use private network. How about the trove network is same with the user's private network in cidr?
    Or is there better way to make the trove-taskmanager to connect to with guest instances.


4) Can you specify which management operations are of most interest to you?
    quotas.


5 ) I’m confused by this comment: "The client can not fully use the api. It is .....  I think may be trove developers think all trove user are nice person who will never curse.” Would you mind providing a little more explanation about what you are getting at?
   I find the trove-client can not use mgmt api. So i say that the client can not fully use the api. Is it clear?


--

Best
    Li Tianqing

At 2015-05-12 00:48:16, "Doug Shelley" <doug at tesora.com> wrote:

Li,


Thanks for your input – definitely useful to get your perspective on some of the challenges implementing Trove in production. I definitely have an interest in understanding how we can improve the project going forward to address some of these concerns. 


Given that Summit is coming up (now one week away!) it seems like it might be useful to collect some more info on the requirements and convene a session during design summit for the community to discuss. 


As I understand it what you are looking for is:
Make it easily configurable for Trove to allocate Nova instances within a particular named tenant. Some questions for you:
Would you expect a deployer to create this tenant prior to configuring Trove in this manner?
What impact would you expect this to have on quotas? For example, should this tenant just have “infinite” quota for CPU/storage etc or should the resources be proxied back to the tenant creating the Trove instance?
Provide clear documentation as to how the separate messaging network is setup between the Trove control plane and the guest instances.
Implement a CLI for Trove management. Some questions for you:
Can you specify which management operations are of most interest to you?
I’m confused by this comment: "The client can not fully use the api. It is .....  I think may be trove developers think all trove user are nice person who will never curse.” Would you mind providing a little more explanation about what you are getting at?
Regards,
Doug


From: Li Tianqing <jazeltq at 163.com>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
Date: Monday, May 11, 2015 at 5:44 AM
To: OpenStack List <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [trove] How we make service vm to connect to management network



Hello,
 Now:
      The vm is created by trove is installed trove-guestagent. The agent should connect to the rabbitmq in management network for notifications and billing.
      Right now, the trove vm can boot by two or more net cards. One is user's, the other one is trove-defined (which is defined in configuration.)
 Problem:
     1)  The vm is put into user's tenant, so the user can login into this vm. It is quite inscure.  We could overwrite the remote.py to put the vm into trove tenant.
          But after overwrite, the user can not start, stop, the instance, the network ip uesed for to connect to msyql is also can not get. 
          Then we should overwrite the instance view to add those information.
          We should make the decision now. If put the vm into trove's tenant is better than into user's tenant. We should add api, rewrite view. Not just give choise to users that use trove.
         Because we are the developer for trove. We should know which is better.
     2)  If we deployment trove like that. The user can not use private network fully. For there is the chance that the user-defined-network is same as the trove-defined-nework
           in cidr. Then the packet can not send out.We should also try other deployment that can make trove connect to management's rabbitmq. For example, make the vm can 
         passthrough to the host that load that vm. For that deployment do not limit the user's in private network use. So i say we should talk a lot on this problem.
        
    3)  we should add mgmt-cli quickly. The client can not fully use the api. It is .....  I think may be trove developers think all trove user are nice person who will never curse.
  
May be i am not right. But i am open do discuss if i still interested in trove.
    
--

Best
    Li Tianqing


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150512/4e32d26f/attachment.html>