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" <d...@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 <jaze...@163.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, May 11, 2015 at 5:44 AM
To: OpenStack List <openstack-dev@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
__________________________________________________________________________
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
