Hi James, I'm glad you're in the forum! I have a question not specific to neutron, but more around patterns of deployments with cloud networking. I hope you can help.
I've been working on an openstack project where there are a number of pre-implemented neutron networks. I need to connect each of my hosts to three of these networks, and I'd like to automate their build using openstack heat for infrastructure provisioning, then ansible for the application deployment. I'm wondering what the best pattern is for automating these build steps before moving the hosts to production. Would you build the hosts directly in the networks where they are to reside or would you perhaps stage their build in a temporary build network, then turn up the hosts in their permanent networks afterwards? I feel like the first option is simpler, but the production networks are quite isolated making it hard to complete some of the package deployments.
If you have other ideas on how to accomplish this, I'd like to hear your thoughts. Thanks for your help!
Attaching the production networks from the get-go and performing the bootstrapping/build of the instance is certainly my preferred approach, but I understand that the networks themselves may not provide the connectivity needed to perform the build out. You could consider connecting a 4th interface/network at first boot that has the connectivity needed, and then remove the port from the instance when done, but you may run into routing issues depending on how these subnets are setup. A proxy server could sit out on that 4th network that would eliminate the need to modify routes on the instance.
You could also go with your idea of a bootstrapping network, deploy your application, then perform a 'nova interface-remove/attach' equivalent with Ansible to reconnect the instance to the production networks. The IP address would likely change, which could impact your configuration and any listeners.
When I encounter limited instance connectivity in other deployments, a proxy server *somewhere* is usually how connectivity is accomplished.
Yeah, that 4th bootstrapping interface is exactly what I did for my DEV build, so I'm glad that you've validated this approach. I do think the routing will be an issue once I am working in the production openstack environment, but this 4th interface may be achievable there as well. I'll also keep the proxy idea in my back pocket if I do encounter routing issues.
Thanks again for your suggestions!
Tick check! Okay, I guess that was just an itch. Oh wait! Just a tiny ad: