With this option enabled, dnsmasq can offer the same IP address to
multiple hosts when their requests are close to each other. Remove this
option in order to use the built-in hashing mechanism which will
allocate random IP addresses, which should be less likely to conflict.
Closes-Bug: #1991390
Change-Id: I09a9fa2d0c54635b899ad7906cc2e2e4580ef5ad
Render {{ openstack_service_workers }} for workers
of each openstack service is not enough. There are
several services which has to have more workers because
there are more requests sent to them.
This patch is just adding default value for workers for
each service and sets {{ openstack_service_workers }} as
default, so value can be overrided in hostvars per server.
Nothing changed for normal user.
Change-Id: Ifa5863f8ec865bbf8e39c9b2add42c92abe40616
To use notifications with ironic, the notification_level
option in the [DEFAULT] section of the configuration file
must be set, we use ``info`` as a reasonable level.
Closes-Bug: #1969826
Change-Id: I38bb1e5404e917c788689a3181741022f875da06
With the ironic_http_interface/ironic_http_interface_address
parameters it is possible to set the addresses for the
ironic_http service.
Change-Id: I72c257ebedf283cdef1b98485a576631e2190657
Fixes an issue where access rules failed to validate:
Cannot validate request with restricted access rules. Set
service_type in [keystone_authtoken] to allow access rule validation
I've used the values from the endpoint. This was mostly a straight
forward copy and paste, except:
- versioned endpoints e.g cinderv3 where I stripped the version
- monasca has multiple endpoints associated with a single service. For
this, I concatenated logging and monitoring to be logging-monitoring.
Closes-Bug: #1965111
Change-Id: Ic4b3ab60abad8c3dd96cd4923a67f2a8f9d195d7
Following up on [1].
The 3 variables are only introducing noise after we removed
the reliance on Keystone's admin port.
[1] I5099b08953789b280c915a6b7a22bdd4e3404076
Change-Id: I3f9dab93042799eda9174257e604fd1844684c1c
Add a new parameter 'ironic_dnsmasq_dhcp_ranges' and enable the
configuration of the corresponding 'dhcp-range' and 'dhcp-option'
blocks in Ironic Inspector dnsmasq for multiple ranges.
The old parameters 'ironic_dnsmasq_dhcp_range' and
'ironic_dnsmasq_default_gateway' used for the only range are now
removed.
This change implements the same solution used in the TripleO several
years ago in the: Ie49b07ffe948576f5d9330cf11ee014aef4b282d
Also, this change contains: Iae15e9db0acc2ecd5b087a9ca430be948bc3e649
fix for lease time.
The value can be changed globally or per range.
Change-Id: Ib69fc0017b3bfbc8da4dfd4301710fbf88be661a
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Ironic is dropping default_boot_option and the new default has
been around for quite a while now so let's remove this old
scary comment.
Change-Id: I80d645cb97251ac63e04d7ec1c87d4600d17d4ee
The bootloader used to boot Ironic nodes in UEFI boot mode during
inspection when iPXE is enabled has been changed from ipxe.efi to
snponly.efi. This is in line with the default UEFI iPXE bootloader used
in Ironic since the Xena release. The bootloader may be changed via
ironic_dnsmasq_uefi_ipxe_boot_file.
Note that snponly.efi was not available via in the ironic-pxe image
prior to I79e78dca550262fc86b092a036f9ea96b214ab48.
Related-Bug: #1959203
Change-Id: I879db340769cc1b076e77313dff15876e27fcac4
Fix configuration for ironic role in order to apply custom
policies for ironic-inspector API
Closes-Bug: #1952948
Change-Id: Id454c693f570e99ea58d2a6231f01a84b80ca56a
This change adds the dnsmasq.log for the ironic-dnsmasq container and
also enables more verbose logging when debug logging enabled.
This can be triggered globbaly via 'openstack_logging_debug' or per
service via 'ironic_logging_debug' or 'neutron_logging_debug'.
Change-Id: I0e6b089beb88827effbcc365625eb2df902f5470
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
A system-scoped token implies the user has authorization to act on the
deployment system. These tokens are useful for interacting with
resources that affect the deployment as a whole, or exposes resources
that may otherwise violate project or domain isolation.
Since Queens, the keystone-manage bootstrap command assigns the admin
role to the admin user with system scope, as well as in the admin
project. This patch transitions the Keystone admin user from
authenticating using project scoped tokens to system scoped tokens.
This is a necessary step towards being able to enable the updated oslo
policies in services that allow finer grained access to system-level
resources and APIs.
An etherpad with discussion about the transition to the new oslo
service policies is:
https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
Change-Id: Ib631e2211682862296cce9ea179f2661c90fa585
Signed-off-by: Niklas Hagman <ubuntu@post.blinkiz.com>
Follow up for I0c7e9a28876a1d4278fb2ed8555c2b08472864b9 which added a
ironic_enable_keystone_integration variable to support Ironic in
multi-region environments. This change skips Keystone service
registration based on ironic_enable_keystone_integration rather than
enable_keystone. It also updates the ironic-inspector.conf template to
use the new variable.
Change-Id: I2ecba4999e194766258ac5beed62877d43829313
Basically, there are three main installation scenario:
Scenario 1:
Ironic installation together with other openstack services
including keystone. In this case variable enable_keystone
is set to true and keystone service will be installed
together with ironic installation. It is possible realise this
scenario, no fix needed
Scenario 2:
Ironic installation with connection to already installed
keystone. In this scenario we have to set enable_keystone
to “No” to prevent from new keystone service installation
during the ironic installation process. But in other hand,
we need to have correct sections in ironic.conf to provide
all information needed to connect to existing keystone.
But all sections for keystone are added to ironic.conf only
if enable_keystone var is set to “Yes”. It isn’t possible
to realise this scenario. Proposed fix provide support for
this scenario, where multiple regions share the same
keystone service.
Scenario 3:
No keystone integration. Ironic don't connect to Keystone.
It is possible realise this scenario, no fix needed
Proposed solution also keep the default behaviour: if no
enable_keystone_integration is manually defined by default
it takes value of enable_keystone variable and all behaviour
is the same. But if we don't want to install keystone and
want to connect to existing one at the same time, it will be
possible to set enable_keystone var to “No”
(preventing keystone from installation) and at the same
time set ironic_enable_keystone_integration to Yes to allow
needed section appear in ironic.conf through templating.
Change-Id: I0c7e9a28876a1d4278fb2ed8555c2b08472864b9
In the Xena release, Ironic removed the iSCSI driver [1]. The
recommended driver is direct, which uses HTTP to transfer the disk
image. This requires an HTTP server, and the simplest option is to use
the one currently deployed when enable_ironic_ipxe is set to true. For
this reason, this patch always enables the HTTP server running on the
conductor.
iPXE is still enabled separately, since it cannot currently be used at
the same time as PXE.
[1] https://review.opendev.org/c/openstack/ironic/+/789382
Change-Id: I30c2ad2bf2957ac544942aefae8898cdc8a61ec6
In services which use the Apache HTTP server to service HTTP requests,
there exists a TimeOut directive [1] which defaults to 60 seconds. APIs
which come under heavy load, such as Cinder, can sometimes exceed this
which results in a HTTP 504 Gateway timeout, or similar. However, the
request can still be serviced without error. For example, if Nova calls
the Cinder API to detach a volume, and this operation takes longer
than the shortest of the two timeouts, Nova will emit a stack trace
with a 504 Gateway timeout. At some time later, the request to detach
the volume will succeed. The Nova and Cinder DBs then become
out-of-sync with each other, and frequently DB surgery is required.
Although strictly this category of bugs should be fixed in OpenStack
services, it is not realistic to expect this to happen in the short
term. Therefore, this change makes it easier to set the Apache HTTP
timeout via a new variable.
An example of a related bug is here:
https://bugs.launchpad.net/nova/+bug/1888665
Whilst this timeout can currently be set by overriding the WSGI
config for individual services, this change makes it much easier.
Change-Id: Ie452516655cbd40d63bdad3635fd66693e40ce34
Closes-Bug: #1917648
* ipxe_enabled was removed in Ussuri, now there is a separate ipxe boot
interface.
* iPXE now has its own set of configuration for the bootfile and config
template, and the values previously set when iPXE is enabled are now
the default in ironic. The overrides have been removed, since they
match the iPXE defaults.
Change-Id: I9d9f030ee4be979d0a849b59e5eb991f2d82f6a4
This patch introduces an optional backend encryption for the Ironic API
service. When used in conjunction with enabling TLS for service API
endpoints, network communcation will be encrypted end to end, from
client through HAProxy to the Ironic service.
Change-Id: I9edf7545c174ca8839ceaef877bb09f49ef2b451
Partially-Implements: blueprint add-ssl-internal-network
When the internal VIP is moved in the event of a failure of the active
controller, OpenStack services can become unresponsive as they try to
talk with MariaDB using connections from the SQLAlchemy pool.
It has been argued that OpenStack doesn't really need to use connection
pooling with MariaDB [1]. This commit reduces the use of connection
pooling via two configuration options:
- max_pool_size is set to 1 to allow only a single connection in the
pool (it is not possible to disable connection pooling entirely via
oslo.db, and max_pool_size = 0 means unlimited pool size)
- lower connection_recycle_time from the default of one hour to 10
seconds, which means the single connection in the pool will be
recreated regularly
These settings have shown better reactivity of the system in the event
of a failover.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/061808.html
Change-Id: Ib6a62d4428db9b95569314084090472870417f3d
Closes-Bug: #1896635
This change adds support for encryption of communication between
OpenStack services and RabbitMQ. Server certificates are supported, but
currently client certificates are not.
The kolla-ansible certificates command has been updated to support
generating certificates for RabbitMQ for development and testing.
RabbitMQ TLS is enabled in the all-in-one source CI jobs, or when
The Zuul 'tls_enabled' variable is true.
Change-Id: I4f1d04150fb2b5af085b762890092f87ae6076b5
Implements: blueprint message-queue-ssl-support
This reverts commit 316b0496b3dd7a9b33692b171391d9d17d535116, because
ironic-inspector is not ready to use WSGI. It would need to be split
into two separate containers, one running ironic-inspector-api-wsgi and
another running ironic-inspector-conductor.
Change-Id: I7e6c59dc8ad4fdee0cc6d96313fe66bc1d001bf7
This patch introduces an optional backend encryption for the Ironic API
and Ironic Inspector service. When used in conjunction with enabling
TLS for service API endpoints, network communcation will be encrypted
end to end, from client through HAProxy to the Ironic service.
Change-Id: I3e82c8ec112e53f907e89fea0c8c849072dcf957
Partially-Implements: blueprint add-ssl-internal-network
Depends-On: https://review.opendev.org/#/c/742776/
The goal for this push request is to normalize the construction and use
of internal, external, and admin URLs. While extending Kolla-ansible
to enable a more flexible method to manage external URLs, we noticed
that the same URL was constructed multiple times in different parts
of the code. This can make it difficult for people that want to work
with these URLs and create inconsistencies in a large code base with
time. Therefore, we are proposing here the use of
"single Kolla-ansible variable" per endpoint URL, which facilitates
for people that are interested in overriding/extending these URLs.
As an example, we extended Kolla-ansible to facilitate the "override"
of public (external) URLs with the following standard
"<component/serviceName>.<companyBaseUrl>".
Therefore, the "NAT/redirect" in the SSL termination system (HAproxy,
HTTPD or some other) is done via the service name, and not by the port.
This allows operators to easily and automatically create more friendly
URL names. To develop this feature, we first applied this patch that
we are sending now to the community. We did that to reduce the surface
of changes in Kolla-ansible.
Another example is the integration of Kolla-ansible and Consul, which
we also implemented internally, and also requires URLs changes.
Therefore, this PR is essential to reduce code duplicity, and to
facility users/developers to work/customize the services URLs.
Change-Id: I73d483e01476e779a5155b2e18dd5ea25f514e93
Signed-off-by: Rafael Weingärtner <rafael@apache.org>
The use of default(omit) is for module parameters, not templates. We
define a default value for openstack_cacert, so it should never be
undefined anyway.
Change-Id: Idfa73097ca168c76559dc4f3aa8bb30b7113ab28
Service REST API urls should be constructed using the
{{ internal_protocol }} and {{ external_protocol }} configuration
parameters.
Change-Id: Id1e8098cf59f66aa35b371149fdb4b517fa4c908
Closes-Bug: 1862817
Include a reference to the globally configured Certificate Authority to
all services. Services use the CA to verify HTTPs connections.
Change-Id: I38da931cdd7ff46cce1994763b5c713652b096cc
Partially-Implements: blueprint support-trusted-ca-certificate-file
