Hi, Thank you for this sample (https://gist.github.com/odyssey4me/09d963776f8872f2562e477c5158a3e0).
I assume osa is not yet ready to handle n provider_networks blocs ? Here is the openstack_user_config I use (based on the one you proposed): https://respawner.fr/p/61aa5c Or is there something I missed ? I get this error when I run openstack-ansible setup-infrastructure.yml --syntax-check : Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml " ERROR! The file /opt/openstack-ansible/playbooks/inventory/dynamic_inventory.py is marked as executable, but failed to execute correctly. If this is not supposed to be an executable script, correct this with `chmod -x /opt/openstack-ansible/playbooks/inventory/dynamic_inventory.py`. Inventory script (/opt/openstack-ansible/playbooks/inventory/dynamic_inventory.py) had an execution error: No container or management network specified in user config. /opt/openstack-ansible/playbooks/inventory/dynamic_inventory.py:18: Expected key=value host variable assignment, got: argparse Thanks On 12/01/2017 15:28, Jesse Pretorius wrote: > Hi Benoit, > > Some time ago I did sketched out a possible way of doing this using a single > inventory for OSA: > https://gist.github.com/odyssey4me/09d963776f8872f2562e477c5158a3e0 > > This is an entirely untested mechanism and may expose some horrible > assumptions we’ve made in the way we configure things, but I thought it’d be > a way of implementing OSA in a pod-like deployment. All this does, in theory, > is have the dynamic inventory implement the container IP’s in different > CIDR’s. > > If someone puts together some sort of PoC for making this work and identifies > the shortcomings in the current mechanisms then I’m quite sure there would be > many interested parties in the community who’d love to pitch in to help > resolve them. It would make for a great discussion at the PTG! > > HTH, > > Jesse > IRC: odyssey4me > > On 11/15/16, 5:38 PM, "[email protected]" <[email protected]> wrote: > > Hi, > > I would like to deploy OpenStack (newton) on multiple management, > overlay and vlan/uplink l3 networks, thanks to Openstack-Ansible. > In other words, I would like to deploy Openstack on multiple compute and > controller nodes that are on different subnets, assuming I do the > routing configuration to permit to management network 1 to communicate > with management network n, overlay network 1 to overlay network n, > etc... > > I attached a sample schema to illustrate my statement. > > To sum up, in this case a compute or controller node which is on > management network 10.0.1.0/24 via br-mgmt can communicate with br-mgmt > of another compute node on management network 10.1.1.0/24. The same is > true from overlay network 10.0.2.0/24 to overlay network 10.1.2.0/24, > etc... > > Am I wrong if I understand that OSA is designed to handle only 1 > mangement subnet, 1 overlay subnet, etc... (storage subnet, ...) ? > > During my tests, specifying compute hosts in different networks, in > openstack_user_config.yml, results in the apparently correct setup of > the compute host "compute3" (Having previously setup correct static > route on each hypervisors): > > compute_hosts: > compute1: > ip: 10.0.1.4 > compute2: > ip: 10.0.1.5 > compute3: > ip: 10.1.1.4 > > However, how to deal with it in cidr_networks: ? (I assume I can't now). > During my tests, an example of what's lacking was that I had to manually > configure static routes in the neutron_agents_container lxc provisionned > by OSA. > > Is that kind of deployment possible ? If not possible, is this or could > this be in the roadmap of the project ? > > Thanks, > > Benoit Petit > > > > > > ________________________________ > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington Road, > Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be > viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may > contain confidential or privileged information intended for the recipient. > Any dissemination, distribution or copying of the enclosed material is > prohibited. If you receive this transmission in error, please notify us > immediately by e-mail at [email protected] and delete the original message. > Your cooperation is appreciated. _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
