3b12b7b951
On computers with wi-fi adapters, promiscuous mode on the VirtualBox (or maybe other hypervisors as well) NICs does not work, which means the default way of connecting the Neutron external interface to a bridged adapter, will not allow communication to and from the Nova VMs over floating IPs with any computer on the external network (except the host computer) or with the wi-fi router. This means no ability to connect to the Nova VMs and no internet access inside the Nova VMs. According to VirtualBox documentation (excerpt): "Bridging to a wireless interface is done differently from bridging to a wired interface, because most wireless adapters do not support promiscuous mode. All traffic has to use the MAC address of the host’s wireless adapter, and therefore VirtualBox needs to replace the source MAC address in the Ethernet header of an outgoing packet to make sure the reply will be sent to the host interface. When VirtualBox sees an incoming packet with a destination IP address that belongs to one of the virtual machine adapters it replaces the destination MAC address in the Ethernet header with the VM adapter’s MAC address and passes it on. VirtualBox examines ARP and DHCP packets in order to learn the IP addresses of virtual machines." To fix this issue, a new flag has been introduced: WIFI. If true, the default Vagrant public network is not created anymore. Instead, the 3rd NIC will be connected to a NAT-Network named OSNetwork. The NAT-Network has a virtual gateway, which will be used to communicate with the external physical wi-fi router. Since Vagrant does not have a high-level mechanism to attach an adapter to a NAT-Network, the code uses the low-level Vagrant construct vm.customize which makes it provider specific. Promiscuous mode is now activated by default on the 3rd NIC. The WIFI flag is false by default. This commit only addresses VirtualBox, and it is currently unknown if the problem described and fixed in this commit is present in other hypervisors. DocImpact Closes-Bug: #1558766 Change-Id: I0b4dbbc562d87191b2179f47b634cdd6f6361a5e Signed-off-by: Andrei-Lucian Șerb <lucian.serb@icloud.com> |
||
|---|---|---|
| ansible | ||
| demos | ||
| dev | ||
| doc | ||
| docker | ||
| etc | ||
| kolla | ||
| specs | ||
| tests | ||
| tools | ||
| .gitignore | ||
| .gitreview | ||
| .testr.conf | ||
| LICENSE | ||
| README.rst | ||
| loc | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Kolla Overview
The Kolla project is a member of the OpenStack Big Tent Governance. Kolla's mission statement is:
Kolla provides production-ready containers and deployment tools for
operating OpenStack clouds.Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission. Kolla is highly opinionated out of the box, but allows for complete customization. This permits operators with little experience to deploy OpenStack quickly and as experience grows modify the OpenStack configuration to suit the operator's exact requirements.
Getting Started
Learn about Kolla by reading the documentation online docs.openstack.org.
Get started by reading the Developer Quickstart.
Kolla provides images to deploy the following OpenStack projects:
- Aodh
- Ceilometer
- Cinder
- Designate
- Glance
- Gnocchi
- Heat
- Horizon
- Ironic
- Keystone
- Magnum
- Manila
- Mistral
- Murano
- Nova
- Neutron
- Swift
- Tempest
- Trove
- Zaqar
As well as these infrastructure components:
- Ceph implementation for Cinder, Glance and Nova
- Openvswitch and Linuxbridge backends for Neutron
- MongoDB as a database backend for Ceilometer and Gnocchi
- RabbitMQ as a messaging backend for communication between services.
- HAProxy and Keepalived for high availability of services and their endpoints.
- MariaDB and Galera for highly available MySQL databases
- Heka A distributed and scalable logging system for openstack services.
Docker Images
The Docker images are built by the Kolla project maintainers. A detailed process for contributing to the images can be found in the image building guide.
The Kolla developers build images in the kollaglue namespace for every tagged release and implement an Ansible deployment for many but not all of them.
You can view the available images on Docker Hub or with the Docker CLI:
$ sudo docker search kollaglueDirectories
- ansible - Contains Ansible playbooks to deploy Kolla in Docker containers.
- demos - Contains a few demos to use with Kolla.
- dev/heat - Contains an OpenStack-Heat based development environment.
- dev/vagrant - Contains a vagrant VirtualBox/Libvirt based development environment.
- doc - Contains documentation.
- etc - Contains a reference etc directory structure which requires configuration of a small number of configuration variables to achieve a working All-in-One (AIO) deployment.
- docker - Contains jinja2 templates for the docker build system.
- tools - Contains tools for interacting with Kolla.
- specs - Contains the Kolla communities key arguments about architectural shifts in the code base.
- tests - Contains functional testing tools.
Getting Involved
Need a feature? Find a bug? Let us know! Contributions are much appreciated and should follow the standard Gerrit workflow.
- We communicate using the #kolla irc channel.
- File bugs, blueprints, track releases, etc on Launchpad.
- Attend weekly meetings.
- Contribute code.
Contributors
Check out who's contributing code and contributing reviews.