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].

[0]:  https://review.opendev.org/c/openstack/kolla-ansible/+/863521
[1]: https://review.opendev.org/c/openstack/kolla-ansible/+/863321

2024年1月8日 04:53，Satish Patel <satish.txt@gmail.com> 写道：

Hi,

Didn't realize that entire trove deployment depend on this patch set - https://review.opendev.org/c/openstack/kolla-ansible/+/863321 

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. 



On Sun, Jan 7, 2024 at 1:05 PM Satish Patel <satish.txt@gmail.com> wrote:
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

On Sun, Jan 7, 2024 at 11:33 AM Satish Patel <satish.txt@gmail.com> wrote:
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 ? 

On Sun, Jan 7, 2024 at 5:16 AM W Ch <wchy1001@gmail.com> wrote:
Hi, please refer to this patch: https://review.opendev.org/c/openstack/kolla-ansible/+/863521/43/tests/templates/globals-default.j2   in kolla-ansible.

In your production, we recommend to create a provider network (vlan or flat network) to be used as the trove management network.

This network should be responsible for accessing  rabbitmq, swift, keystone and docker registry. 

For more information about trove management network, please read this document:  https://docs.openstack.org/trove/latest/admin/run_trove_in_production.html#management-network

thanks.

2024年1月6日 22:55，Satish Patel <satish.txt@gmail.com> 写道：

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.