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:
1. 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?
2. Provide clear documentation as to how the separate messaging network is
setup between the Trove control plane and the guest instances.
3. 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 <[email protected]<mailto:[email protected]>>
Reply-To: OpenStack List
<[email protected]<mailto:[email protected]>>
Date: Monday, May 11, 2015 at 5:44 AM
To: OpenStack List
<[email protected]<mailto:[email protected]>>
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
