The example's environments/base-extra-node.yaml
and environments/base-extra-node-all.yaml uses a
CentOS image to create undercloud like extra nodes.
There is no need for a virtual bmc for the servers
in this role. Set the BMC to OS::Heat::None so that
no BMC instance is created for this role.
Change-Id: I502de0a2e0352078e8f187cc0592f49ec0a9d65d
https://review.opendev.org/#/c/733598/ added support
of allocation_pools, but set type of public_net_allocation_pools
to comma_delimited_list which causes below issue because for
comma_delimited_list, list items are converted to string:-
Property error: : resources.public_subnet.properties.allocation_pools[0]:
"{'end': '10.0.0.199', 'start': '10.0.0.128'}" is not a map
We need to use type: json to get it work, this patch fixes it.
Related-Bug: #1874418
Change-Id: Iaebb297e5018ce8db6dd1f67a308e7707117fe03
TripleO CI uses 10.0.0.1 statically for the undercloud's
public interface. When using extra node in some job's
there is sometime a conflict, because the extra node get's
the 10.0.0.1 address allocated.
Adding support to define the allocation pools on the
public_net allows TripleO CI to define a pool with the
10.0.0.1 address eliminated.
A good practice would be to set up OVB to use
[{start: 10.0.0.128, end: 10.0.0.253}], and then configure
the undercloud/overcloud deployed on the OVB infrastructure
to use addresses in the range 10.0.0.1-10.0.0.127.
The parameter public_net_allocation_pools controls the
allocation pool setting, by default all addresses of the
subnet is in the pool.
Related-Bug: #1874418
Change-Id: Ieca4864e069148abb49eb709bf7f48a14ef04e77
Add prefix support for radvd and dhcrelay instances.
Also adds missing parameters for these instances in
the sample env generator environment.
Change-Id: I86bd6b014b62c3a382458f68443cfb02ed2e7031
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
Add parameters to set the ip_version for the subnets.
By default ip_version for all networks are 4.
Change-Id: I1c5a001fe2ec5c4194030fdf373c0a4318cba10c
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 is the same as base-extra-node, except that it uses the port
template which opens all ports on all networks.
Change-Id: I14fd83e6ef69df0493656bf59ad8ccfeaa932b02
For ease of migration to OVB 2.0, let's provide a compatibility
interface from the old names. A deprecation warning is also added
to deploy.py to notify users that they are using outdated
environments and should switch.
port-security.yaml is not symlinked because there's no analog in
OVB 2.0. port-security.yaml is just the default now. I suppose that
could be an empty file, but I'm not sure anyone is using it
anyway so for the moment I'm omitting it. That decision can be
revisited if necessary.
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.
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.
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.
In most cases a single extra node is going to suffice. The default
of 2 was only a result of using the same parameter as the regular
roles, which defaults to 2.
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.
There are use cases for the additional role functionality where
overriding baremetal_image is useful. Let's expose that more
explicitly in the sample environment file.
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.
Big changes here. This will make it easier to deploy some of the
more advanced OVB options like network-isolation. Instead of users
having to figure out which lines in the sample env.yaml to uncomment
when deploying advanced options, they will simply be able to include
one environment file that contains all the appropriate parameters
to turn on the option.
This _should_ be backwards compatible with existing monolithic
env.yaml configurations. If it is not, that is a bug.
To create the option environments, a slightly modified copy of the
sample environment generator from tripleo-heat-templates has been
copied into the project. The sample environments should _not_ be
edited directly. Instead, the definition in the sample-env-generator
directory should be altered and the tool re-run to update the
environment.