Age | Commit message (Collapse) | Author | Files | Lines |
|
This change is to set the glance protocol and port as
configurable via the Heat template. Presently the port is
hard-coded in the elements nova.conf file, and the protocol
is assumed as being the default (http).
This change will allow the glance_api_servers
to be set (in nova.conf) using the constituent parts:
glance_protocol://glance_host:glance_port
Change to nova.conf to read this value is:
Idccc0d60c9f6b17a853c6de1bbea64bfc7e028b2
Default port value is set to the nova default(9292) which is
currently hard-coded in the elements nova.conf file.
Default protocol value is set to the nova default(http).
Change-Id: I3c7218292797c62c36e2aaab4f325bf053ef140b
|
|
|
|
|
|
|
|
VIP should be used when pointing an OS service to
another OS service in config files (most typical is
setting Keystone's host IP, but also Glance and Netron
host needs to be set in Nova config file).
Change-Id: Id91e6ef2747981f17a43afd279d4eebaad01fe4d
|
|
Rewrote template from scratch using HOT. Mail delivery does not work yet
but it does produce Nagios.
Change-Id: I347f8a008aa7db1145da0988053c791e6f2dbbc2
|
|
|
|
Establish the Public (SSL) port, 13777, and connect it to the internal port, 8777
Change-Id: I7bba7f8224b6e31fc4f5444eee679ca5a4ce4ebe
|
|
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
|
|
|
|
|
|
Now we're trying to automate VLAN deployed underclouds, this
suddenly becomes relevant.
Change-Id: I800a0ceab7443d685551d7a919724f6cf45fd891
|
|
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 need a paremeter to attempt scaling of the Controller resources in
merge.py.
Change-Id: I4a79059e72850da4a5a3fe30dbb9df92a9dca212
|
|
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 will allow us distribute identical keys/certs to all
control nodes in HA mode.
Change-Id: Ie84f3897717c02e196a405746865996c0a929977
|
|
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
|
|
|
|
|