Age | Commit message (Collapse) | Author | Files | Lines |
|
There is no need for a tuskar-specific undercloud template. Tuskar is
installed via elements just like any other undercloud service.
This template is not being used in devtest and I'm not sure it ever has
been.
Change-Id: I531d927b1984873b32f440d33a130788670f7cd9
|
|
|
|
|
|
This provides a means for users to pass configuration through to the
machines they are deploying without us modelling that.
Change-Id: Ia8d1564bd0f3e7b988497a84e00831619047cd94
|
|
Change the undercloud deployment to use software-config similar to
that used by the overcloud.
Change-Id: I81bced2062e461fe10301969d856d709c0b573c3
|
|
|
|
We have had a change of opinion and are moving bootstrap_host properties
out of bootstack in order to prevent mysql / rabbit from depending on
boot-stack.
Change-Id: I85399019c5fc448e98362ef832988abc8d9d459d
|
|
|
|
These provide a single consistent interface for checking whether
a given node is the bootstrap node, or not the bootstrap node
for database initialisation etc.
Change-Id: I7c5a09cb3477b61c4050e4a47a680ffc9aee97d8
|
|
We've found a couple of bugs in swift-storage-source.yaml which
were exposed when we tried to use the template to build a second
Swift storage node. These errors are:
a. Error in swift-devices metadata description - indentation
wasn't correct and a "-" was missing
b. Keystone config data required by the swift-proxy element
weren't defined
c. The signal_transport property wasn't defined and set to
NO_SIGNAL for SwiftStorage0Deploy (this meant that the
completion condition for the resource was never satisfied)
d. The user_data_format property for the SwiftStorage0
resource was not defined and set to SOFTWARE_CONFIG, which
meant that the SwiftStorage servers never got their config data
We've fixed the above errors. We've added an
OS::Heat::StructuredConfig and corresponding
OS::Heat::StructuredDeployment for the Keystone config data.
Change-Id: I858ebf9eea4ed33987143277f4c986b4934555d1
|
|
|
|
|
|
This change is required to resolve scaling issue for
OVERCLOUD_CONTROLSCALE > 1
Basicly change affected all the places where endpoints
were configured to use controller0 ctlplane ip address
Change-Id: I76eb9d2b81d3ef5e9fae408f2432515f4de13e12
|
|
|
|
Add SSLCACertificate to the overcloud yaml.
This allows a CA certificate to be specified in cases where the Cert
does not come from a CA in the system bundle.
Partially implements: blueprint tripleo-ssl-overcloud
Full set of blueprint changes:
https://review.openstack.org/#/c/85098
https://review.openstack.org/#/c/85099
https://review.openstack.org/#/c/85100
Change-Id: I67d7c1362df323762023be5c74fbe75b1583570c
|
|
|
|
|
|
The control plane has to be up before the compute deployments can
work. By sequencing these we permit stopping the o-r-c scripts in
the overcloud rather than trying and failing to configure things.
It also reduces the total deploy time by front loading control
plane configuration - Heat has some sequence code which prevents
parallel instantiation on deployments, and the control plane bring
up is critical path for deploying OpenStack.
Change-Id: I0bb2f8ab41c4af1443af60f7547673d495e4e0fb
|
|
added ControlVirtualIP resource of type OS::Neutron::Port
Added ControlVirtualInterface - by default br-ex
To specify the IP address to use as ControlVirtualIP,
or for any others custom needs, you could provide:
-P 'ControlFixedIPs=[{"ip_address" : "192.0.2.251"}]'
Related to blueprint tripleo-icehouse-ha-production-configuration
Change-Id: Ie82750ac1537c80311a869880f636bda59ca5c58
|
|
Choosing 100MB here is not a production default. We also don't need two
places with the default value set. The closer a default is to the actual
usage of it, the better, so we'll set 0 here, which will defer to the
default in the element.
Change-Id: I1b41b604286245c2fb83249778db835253c02fc5
|
|
|
|
|
|
Creation of OS::Neutron::Port requires network_id parameter
OS::Neutron::Port will be used for VIP creation
Creating port for network by name, e.g:
neutron port-create ctlplane
works only with neutron cli
Change-Id: Ia8bd6f700a4897efd277fd67189d2e04ad716b87
|
|
|
|
Updates the overcloud nova-compute templates so that
the NTP server is properly configured.
Change-Id: I4fc407153da5e031dcf5e5e5e1b3b74d932dba45
Partial-bug: #1309677
|
|
This will indicate to os-collect-config that this config
resource represents os-apply-config configuration data,
so it can only write out top-level config files for
os-apply-config data (or Heat::Ungrouped for backwards
compatibility).
Change-Id: I3552fdd6df8106ab83cfd17d5f4b137cf33fbc36
Related-Bug: #1299109
|
|
Being able to figure out the hypervisors from the control nodes seems
useful, and equally all the hypervisors should know about all the
control nodes (at least until we have virtual IPs all in place), and
lastly the control plane need to know each other by hostname.
Change-Id: I92877501c58d8c210e7b2c94935e107355271fb9
|
|
-Undercloud Ceilometer has to have access to SNMPd credentials,
so it can poll the Overcloud nodes
-In every Overcloud node, we need to set the same cretentials
to SNMPd.conf
Change-Id: Icf7c0c1772b6380b7136108e61c15cafe17274ba
|
|
This was hard-coded to 5 gig, which is useless for anything other
than tempest runs and smoke testing
block-storage-nfs.yaml has intentionally not been changed, since
volume_size_mb is not used in that setup. Cleaning up that code will
be done separately.
Change-Id: I476b906a8d439d3e6643dd0c214965c5862418e8
|
|
The PXE deployment often times out on baremetal deployment with >5
overcloud nodes because the time being measured includes the
dd of the image, which can be slow when many images are sent
from the same undercloud host.
Ideally we'd make the image sizes smaller, and/or make the
undercloud cache the images more sanely. It would also be
possible to split the timout to measure dd-time and boot-time
separately, but for now we just make the timeout configurable so
a user can raise it if they have problems.
Change-Id: I15540eec7a68eab4c9d128b65a95b1c0a2b64582
Co-Author: nicholas.randon@hp.com
|
|
Adds a new parameter, NeutronDnsmasqOptions, to the overcloud template.
Allows the ability to set dnsmasq options for neutron dhcp agent. This
will allow us to configure mtu to be 1400 for tenant instances on the
overcloud. This should help with poor network performance and vm's that
are just plain unreachable via ssh due to the GRE tunnel overhead.
The default here has been set to:
dhcp-option-force=26,1400
This is the recommended way to configure OpenStack with the Open vSwitch
plugin per:
http://docs.openstack.org/admin-guide-cloud/content/openvswitch_plugin.html
All the documentation I can find on the web (openstack-dev,
ask.openstack.org, etc), recommend applying this setting. Others have
reported slow vm performance as well, and this resolves that issue
(apparently anyway...we'd need to test).
Change-Id: If24326045987b5a484ba2f71f591092987966536
Partial-Bug: #1270646
|
|
|
|
|
|
This provides a means for users to pass configuration through to the
machines they are deploying without us modelling that.
Change-Id: I7134eb0c6be2d5cb1795b2f03cfba4afb69dc837
blueprint: passthrough-config
|
|
Swift proxy-servers use memcache to store and share metadata. This
change adds swift.proxy-memcache metadata to the swift-source and
swift-storage-source yaml templates modelled on the existing
swift.devices metadata. This metadata will be consumed by the
swift-proxy/os-config-applier/etc/swift/proxy-server.conf element
if the metadata exists.
Change-Id: If0b5724f69e7ec1c98e4dbdbeb9f08c4a18151b6
|
|
-adding Undercloud Ceilometer that will collect statistics
about Overcloud nodes, via SNMP
Change-Id: I1e90ad8d5bad16bc1c418ca2dbd78163abe6267c
|
|
This migrates the overcloud to using OS::Heat::StructuredConfig and
OS::Heat::StructuredDeployment. With those tools, we can decouple
servers from software configuration and begin to deprecate features in
tripleo_heat_merge.
Change-Id: Ice85f0711e90d0fabf1d1bc4698201c4d6758508
|
|
|
|
|
|
Updates all references for notCompute and notcompute
to use 'controller' instead.
Change-Id: I70ef83f35064ab388bdc7e1a6da62b6585580010
Partial-bug: #1300324
|
|
|
|
|
|
|
|
|
|
|
|
Change-Id: I30c0e175fda448a300cae0b233757d31ce73402f
|
|
Add the enable_tunneling option to the neutron-openvswitch-agent
metadata for the swift storage template. If not preset, this option is
left blank in the openvswitch plugin configuration plugin. This causes
the service to fail to start because a blank value is not permissible
for a boolean option.
Change-Id: Ieadcdab295913121bd00dbd25e4245024bc2240f
|
|
Innodb buffer pool size in mysql config file is now set to 592M,
this value is for VMs with 2G RAM too much. This patch makes the
pool size configurable and decreases default value to 100 MB
(this should be sufficient for default devtest setup). A patch which
for tripleo-image-element which sets this value in my.cnf will follow.
Change-Id: I0d2529abe51d4dc34415bf6c40da7a267bf3e65b
|
|
This is necessary to support iscsi helpers other than tgtadm, such
as lioadm.
Change-Id: I8a63872185f73372fcf6c90d3dde31e5bb0a168b
|
|
Add a BlockStorage0Config resource in the block-storage.yaml template.
This was missing previously and was causing the behavior of having all
block storage nodes only being created after all other nodes were up in
a deployment (I presume b/c of the wait conditions).
Also, we need the BlockStorage0Config resource so that we can get the
configuration of neutron-openvswitch-agent from the metadata, previously
the values in the file were unset, causing the service to fail to start.
Change-Id: I297de24079d1ece66d35213b4ef1f2c8c50e73f0
|