A few wording changes and a split of the introduction and the
discussion of benefits and drawbacks. Also added a basic description
of an OVB environment.
The previous patch instructions for Nova installed from RDO did not
work because they attempted to do the patching at the wrong level
of the package directory structure. This change fixes that and
simplifies the patching command.
This patch still applies against Nova master, so it's not
actually specific to kilo. To avoid confusion, let's just name the
directory "nova". If it merge conflicts at some point we can add
version-specific ones again.
In my environments I tend to run as admin, hence why my quota
commands used the admin tenant uuid. This isn't necessarily the
case though, so it shouldn't be documented that way.
It turns out that it is also necessary to change the MTU of the
undercloud provisioning interface. In addition, the default MTU
for instances in a stock TripleO cloud is now 1350, so the previous
documented value of 1450 doesn't actually work anymore.
The commands listed to change the undercloud MTU wouldn't work as
written because there's no newline in /etc/dnsmasq-ironic.conf.
Add a leading \n to make the resulting file valid.
The configuration changes described in the readme only need to be
made on compute nodes. While it won't hurt to make them on
controllers as well, it's best to be explicit.
Turns out this was already documented, but after the network
creation so I missed it when doing a quintupleo deployment that
doesn't require network creation. Let's move the keypair doc up
so that's less likely to happen.
Provide an explicit explanation of what the host cloud is, update
the reference to RDO Kilo to make it more clear that the
instructions apply to all versions of TripleO and RDO, and add a
note to the devstack instructions that explains why you probably
don't want to use devstack for this anymore.
Undercloud ironic has a retry_timeout of 15 seconds
Host cloud nova default will wait for 60 seconds for a graceful
shutdown before forcing a shutdown.
The combination of these two means that ironic nodes end up in an
ERROR state after deleting an overcloud requiring manual
"ironic set-provision-state deleted" to cleanup.
This change sets a short os_shutdown_timeout so that shutdowns are
quick enough for ironic's timeout.
There's no real reason to be using a specific older version of the
CentOS base image, and it just wastes time updating packages.
Just use the current image, whatever that happens to be.
Deploying instances that use an MTU of 1500 in tunneled networks
that also have an MTU of 1500 causes problems. This change
documents the options for dealing with that.
The original single bmc change configured the bmc instance with
two Neutron ports. This was done mostly to avoid some extra
manual network configuration in the bmc instance, but it resulted
in duplicate routes to the private network. Recently it has come
to my attention that Ironic is having intermittent problems
talking to the bmc instance, which may be caused by this duplicate
route. I had similar problems with the initial single bmc change
because it added N routes to the bmc when N baremetal instances
were created. Reducing the duplicate routes probably mitigated
the problem, but didn't eliminate it.
This change switches to a single Neutron port for the bmc and does
the necessary configuration via os-net-config so the default route
and the Neutron assigned address will continue to work. It also
removes the note in the documentation about needing to allow
multiple ports on a single network.
Provide guidance on sizing the BMC flavor, and take advantage of
the fact that the BMC service now logs to the console, so it is
possible to know for sure when it is complete.
This should have been two commits, but apparently I forgot to push
the button after the first one.
Adding a public network allows us to simulate a more realistic
environment where the provisioning network and the public API
network are separate.
The QuintupleO template wraps the existing virtual-baremetal.yaml
and does some extra configuration suited to a TripleO deployment
model. I made it a separate template in an attempt to decouple
OVB and QuintupleO since the former doesn't necessarily need the
latter.
Ghanshyam Mann