This refreshes the ipxe build makefile to build an image
that works in both legacy BIOS and UEFI environments.
This makes the following changes:
- Moves the ipxe submodule commit to current master
- Creates an EFI partition efi.img containing ipxe.efi
as the default binary
- Builds ipxe-boot.img as an MBR/GPT hybrid ISO which boots
and runs iPXE in both legacy BIOS and UEFI environments
- Stop creating ipxe-boot.qcow2 since the conversion from
ipxe-boot.img has an incorrect EFI partition, and there is
no real benefit over the raw image anyway
- Refresh the documentation for how to upload the images to
an OpenStack cloud, remove the redundancy from ipxe/README
Change-Id: I720ed5aaa0d55ded73e01aaba9db66602adc26cd
Add a new templates to configure radvd and dhcpv6 relay.
For IPv6 routed network the radvd daemon and the dhcpv6
relay is hosted on the same instance.
Since we do not want the networks in the OVB infra to
provide any DHCP or auto configuration we cannot use
neutron routers for provisioning network routing. The
instance running dhcpv6 relay and radvd will also be
the router for the provisioning networks.
Bump template version in undercloud-networks-routed.yaml
to version 2015-10-15. Need this version to avoid error:
'Items to join must be strings not
{u'str_split': [u'/', u'fd12:3456:789a:3::/64', 1]}'
Change-Id: Ib95f7d7cfd3d2318ac4f4f44f22955b0c18c465e
When using pre-deployed servers, you may want all of the networking
setup of OVB but don't actually need to control the instances via
IPMI. While this could already be done, it left a useless BMC
instance lying around. This change allows the BMC to be disabled
completely to clean up such environments.
Change-Id: Icd6936977684d178277ebb721a7fbb3ffad51d9a
This hasn't been a mandatory part of the host cloud setup for a while
now, and we should note that in the documentation.
Change-Id: I63b52270a740ae92eac0fa390179c44b3a2a41cd
This is the same as base-extra-node, except that it uses the port
template which opens all ports on all networks.
Change-Id: I14fd83e6ef69df0493656bf59ad8ccfeaa932b02
These are all deprecated. For unit testing stestr should be used
directly, and for doc builds sphinx-build should be used directly.
A couple of minor doc changes were needed to eliminate warnings.
Change-Id: Ic2e1b9d692c9b5866f888fb4c8c08bf95742764e
Since the router for the public network is disabled by default, we
should have an enablement environment so people don't have to
manually add it to their env file.
This allows the path-specific registry entries to be static and
doesn't impose any requirements on where the environment containing
parameters lives. The documentation is also updated, which required
a newer version of sphinx to allow automatic references to headings.
192.0.x.x is non-private addresses. Since we now in some
cases care about the address ranges used in the environment
switch to use addresses in the private space 192.168.x.x.
Also minor update to doc, router addresses are no longer
dynamically allocated.
Reference sample environments in environment index.
Update the deploy command to use the default env files.
Add Note regarding TripleO Undercloud physical network
name of ``local_subnet``.
Fixes some typos.
It's no longer true that OVB can't run on public clouds. This change
updates the introduction to better describe the current situation
with OVB on public cloud, and to make note of another limitation
that recently came to my attention.
Minimal requirements for undercloud nodes are described here:
https://images.rdoproject.org/docs/baremetal/requirements.html
Specifically, it says:
"The undercloud VM or baremetal machine requires: [...] 16 GB free
memory"
It's not just documentation that asks to change default flavor. If you
try to deploy using tripleo-quickstart in RDO cloud / OVB, you will hit
both tripleo-validations failures like:
There are 4 cores in the system, but there should be at least 8.
The RAM on the undercloud node is 7822 MB, the minimal recommended value
is 16384 MB.
And even when validations are ignored, the resulting environment fails
because mariadb (or another crucial service) is killed by oom-killer. I
personally experienced mariadb killed and as a result, heat-api
failing when listing stacks with ECONNREFUSED from db server, which
finally resulted in overcloud deployment failure.
xlarge is the smallest default flavor that provides 16gb ram, and so
this patch uses this flavor.
In practice, very few users deploy an OVB environment anymore with
no additional environments. This change adds a few common ones to
the example command. While these environments won't all work on
older clouds and may not be necessary in some circumstances, in
most cases they won't hurt anything and make it more likely that
a user's first attempt to deploy will succeed.
In addition, by explicitly passing env.yaml in the example, if users
do add more environment files they won't have to remember to also
add env.yaml. This would be an easy mistake to make that might
result in confusing failures.
Previously it was assumed that the user would know to delete the
Heat stack to delete an environment. Since that's not actually
obvious to a new user, add explicit documentation of it.
There may be situations where it is useful to boot only the
undercloud or only the baremetal nodes from volume. This commit
adds environment files to enable that.
There are multiple use cases for tracking the nodes of a given role
using a separate JSON file. This change adds output files for each
role individually, in addition to the standard nodes.json that
includes everything in the deployment. If no roles are being used,
the behavior is the same as before.
Adds a sample role environment that will deploy additional
undercloud-like nodes. In order to do this, it is necessary to
allow override of the baremetal_image parameter in role files, so
that functionality is added too.
The MTU docs were not in the usage section, which is problematic
since many users will not be doing the host cloud setup. This
change also improves the documentation around deploying a network
isolation cloud in an OVB environment.
In some clouds ephemeral storage is much slower than volume storage,
so we want to be able to use volume storage for the performance-
sensitive instances. This change adds new environments to enable
that and updates build-nodes-json to handle the case where there is
no image associated with an instance.
These values are ignored in a typical OVB deployment so there is no
need to change them. Let users know that since we are exposing the
parameters in the sample environments.
Deploying a QuintupleO environment is usually going to be much
easier than starting from a base baremetal environment and adding
all of the necessary bits. This is particularly true when using
port-security to allow undercloud DHCP because then the user is
responsible for shutting off port-security on the undercloud port.
Now that all current upstream releases support local_mtu, let's
use that for setting MTU. It's much simpler.
The previous docs are left as-is in a note for anyone deploying
older releases.
Docstrings were not written for this module initially. This
addresses that shortcoming. The module is also added to the api
doc index so it will show in the documentation.
Specify that the host cloud must be running on real baremetal. This
should sufficiently differentiate it from the nested clouds in a
virtual baremetal deployment.
There are a lot of subtle things that break if name collisions
happen between two OVB envs. --id should prevent all of them, so
it's a best practice to use it any time there are multiple envs.
It's better to have this early so if an initial deployment fails,
the user has the necessary details about deleting the stack up
front. Otherwise they had to get all the way to the end of the
doc.
Ghanshyam Mann