HI, yes you are right . the patch [0] depends on the patch[1]
In your case, you can create a trove manage network like octavia lb-mgmt-net, and set it as trove mgmt network.
Setting mgmt network in kolla for Trove:
Vim /etc/kolla/config/trove.conf
[DEFAULT]
management_networks = 7a93bb03-2797-4529-8d6e-27b1699b7eb1 // management network which is the same as the lb-mgmt-net,
nova_keypair = trove-key // nova keypair, the same as the octavia nova key
management_security_groups = c8c65b8b-17f5-48e5-b094-867a8ecfce32 // used for management port
docker_insecure_registries =
10.1.2.49:6400 // if you are using an insecurity docker registry
then, reconfigure your trove deployment // kolla-ansible reconfigure —tags trove, horizon
As you mentioned above:
Second thing I was thinking why don’t I expose rabbitmq/keystone etc on public ip using ngnix so trove vm can access those public endpoints.. what is the problem in this approach ?
This is also feasible for trove deployment, but in this situation, the cloud operator might be hard to ssh into the trove guest vm for debugging. We don’t recommend to use this approach in production.
Finally, you don’t need to cherry-pick the above patches. Just set up the resources manually to achieve the same result as patch[1].
Hi,
What stopped us to merge this patch because I am desperately looking to implement trove on our cloud infra. Let me know if you need help to test it out.
Hi,
I have tried following in global.yml and it didn't create any network. Assuming your patch is missing for that right? Or am I missing something?
# Trove (DBaaS)
enable_trove: "yes"
enable_cinder_backup: "no"
enable_cinder_backend_lvm: "no"
docker_disable_ip_forward: false
trove_mgmt_network:
name: trove-mgmt-net
provider_network_type: flat
provider_physical_network: physnet1
external: True
shared: True
subnet:
name: trove-mgmt-subnet
cidr: "
192.168.100.0/24"
gateway_ip: 192.168.100.1
allocation_pool_start: 192.168.100.150
allocation_pool_end: 192.168.100.199
enable_dhcp: yes
Thank you for the information.
Let me understand. You are saying I should create trove-mgmt network which attached to all controller services and same network will attach to trove instances (guest-agent) right? (Just like Octavia lb-mgmt-net)
Where do I tell trove to use trove-mgmt network when you spin up instance? (In what config file?)
Do I need your patch for that or without that patch it’s possible?
Second thing I was thinking why don’t I expose rabbitmq/keystone etc on public ip using ngnix so trove vm can access those public endpoints.. what is the problem in this approach ?
Folks,
I am trying to find a kolla-ansible doc related to how to implement trove in production with best practices. Especially when a guest-agent (running inside VM) talks to RPC service.
How are other folks doing in their environments? In most cases RPC is an internal service and not visible to any guest VMs. Looking for some guidance.