In order to get flat networking working correctly we need to create
a new veth pair that neutron can use on the host machines. Neutron can
take the veth end of this pair for the brq bridge while the other end
remains in br-flat allowing communication back to the VM. This also
expands the DHCP range for the veth pairs and changes the
host_bind_override to use the new veth.
Change-Id: I9cd161599ba659890142143d4718420d680d7dca
Now expects a base URL that looks for iPXE files. Uses
boot.ipxe.org by default but the base URL can be overridden to
point to custom compiled versions of ipxe.lkrn, ipxe.efi,
and undionly.kpxe.
Change-Id: Ib2c10c4817eaf9a78326f3de00aed0c16f8df776
Adds support for iPXE scripting. Allows for the
operator to specify a remote iPXE kernel to pull in
newer iPXE kernel features and specify a remote
default iPXE script for customizing the multi node
for other types of deployments.
Switches the installations to use netboot installer kernels
instead of ISO retrival and extraction.
Restructures directory to allow for future multi node configs
instead of just debian based installs.
Change-Id: Ie97f021dbd33ad3d852132b0b2850f54d4e13476
This change makes it possible to deploy ACNG within a physical
host NOT automatically tied to an MNAIO installation. This also
adds an infra preseed file which can be used to provision physical
hosts.
By default the domain name is now passed into the server boot params
which is useful when setting up an environment in support of
RFC-1034/5.
Ubuntu 16.04 has an issue with the options "quiet splash" being passed
in which cause it to have no usable console. See [Related-Issue] for
more.
Related-Issue: #1656605
Change-Id: I731dfb70e4b5d676d8c22082da77c0d22d5afb58
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
This change allows the MNAIO to really be used as a stand alone kick
system which has the potential to be developed into a stand alone
project. At the very least this change improves playbook performance
by scoping variables.
The inventory has been converted into a typical Ansible inventory and
the "servers" used in the MNAIO are now simply host_vars
which will trigger specific VM builds when instructed to do so. This
gives the MNAIO the ability to serve as a stand alone kick system which
could be used for physical hosts as well as MNAIO testing all through
the same basic set of playbooks. Should a deployer want to use this with
physical servers they'd need to do nothing more than define their basic
inventory and where the the required pieces of infrastructure needed to
PXE boot their machines.
Change-Id: I6c47e02ecfbe8ee7533e77b11041785db485a1a9
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
The original mnaio was built using a lot of bash and was tailored
specifically for ubuntu 14.04. The new mnaio was built using a mix of
bash and ansible and was tailored specifically for ubuntu 16.04. This
patch takes the two code bases and combines the best things from each
method and wraps it up into a single code path all written using ansible
playbooks and basic variables.
While underlying system has changed the bash environment variable syntax
for overrides remains the same. This allows users to continue with what
has become their normal work-flow while leveraging the new structure and
capabilities.
High level overview:
* The general performance of the VMs running within the MNAIO will now
be a lot better. Before the VMs were built within QCOW2 containers,
while this was flexible and portable it was slower. The new
capabilities will use RAW logical volumes and native IO.
* New repo management starts with preseeds and allows the user to pin
to specific repositories without having to worry about flipping them
post build.
* CPU overhead will be a lot less. The old VM system used an
un-reasonable number of processors per VM which directly translated
to sockets. The new system will use cores and a single socket
allowing for generally better VM performance with a lot less
overhead and resource contention on the host.
* Memory consumption has been greatly reduced. Each VM is now
following the memory restrictions we'd find in the gate, as a MAX.
Most of the VMs are using 1 - 2 GiB of RAM which should be more than
enough for our purposes.
Overall the deployment process is simpler and more flexible and will
work on both trusty and xenial out of the box with the hope to bring
centos7 and suse into the fold some time in the future.
Change-Id: Idc8924452c481b08fd3b9362efa32d10d1b8f707
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
