I was recently in a need to start "playing" with setup) so I thought that it would be good idea to have my personal playground to start deploying from scratch/breaking/fixing that playground setup.
At first sight, Openstack looks , we just need :
- keystone (needed for the identity service)
- nova (hypervisor part)
- neutron (handling the network part)
- glance (to store the OS images that will be used to create the VMs)
Now that I have my requirements and list of needed components, let's see how to setup my PoC ... The guide. You can follow that guide, and as everything is packaged/built/tested and also delivered through CentOS mirror network, you can have a working RDO/openstack All-in-one setup working in minutes ...
The only issue is that it doesn't fit my need, as it will setup unneeded components, and the network layout isn't the one I wanted either, as it will be based on openvswitch, and other rules (so multiple layers I wanted to get rid of). The good news is that )
Just be sure to have enable_isolated_metadata = True in /etc/neutron/dhcp_agent.ini and then systemctl restart neutron-dhcp-agent : and from that point, cloud metadata will be served from dhcp too.
From that point you can just follow the too
One last remark with linuxbridge in an existing network : as neutron will have a dhcp-agent listening on the bridge, the provisioned VMs will get an IP from the pool declared in the "neutron subnet-create" command. However (and I saw that when I added other compute nodes in the same setup), you'll have a potential conflict with an existing dhcpd instance on the same segment/network, so your VM can potentially get their IP from your existing dhcpd instance on the network, and not from neutron. As a workaround, you can just ignore the mac addresses range used by openstack, so that your VMs will always get their IP from neutron dhcp.
To do this, there are different options, depending on your local dhcpd instance :
- for dnsmasq : dhcp-host=fa:16:3e:::*,ignore (see )
The default mac addresses range for openstack VMs is indeed fa:16:3e:00:00:00 (see /etc/neutron/neutron.conf, so that can be changed too)
Those were some of my findings for my openstack PoC/playground. Now that I understand a little bit more all this, I'm currently working on some puppet integration for this, as there are official openstack puppet modules available on git.openstack.org that one can import to deploy/configure openstack (and better than using packstack). But lot of "yaks to shave" to get to that point, so surely for another future blog post.
SOCIAL SHARE CARD GENERATOR