This reverts commit d77372e86ab078711d48dbe2917714f338842ca5.
Reason for revert: service role support has been fixed in Ironic [1]
and added to Kolla-Ansible.
[1] https://review.opendev.org/c/openstack/ironic/+/907148
Closes-Bug: #2051837
Change-Id: I49664e3a353f54e0d51f454c552a78846ba64101
Ironic started enforcing new RBAC policies [1]. Kolla/Kayobe
CI jobs are failing, as K-A doesn't have service role support.
Moreover Ironic RBAC is not yet stable enough [2].
Disable enforcing new policies until fix merges and Kolla
Ansible service role support is added.
[1] https://review.opendev.org/c/openstack/ironic/+/902009
[2] https://review.opendev.org/c/openstack/ironic/+/907148
Related-Bug: #2051837
Change-Id: I424cff6ac96dfe0dd5dc58afca2b785f494c9f02
* Updates etcd to v3.4
* Updated the config to use v3.4's logging mechanism
* Deprecated etcd CA parameters aren't used, so we are not affected
by their removal.
* Note that we are not currently guarding against skip-version updates for
etcd.
Notable non-voting jobs exercising some of this:
* kolla-ansible-ubuntu-upgrade-cephadm (cinder->tooz->etcd3gw->etcd)
* kolla-ansible-ubuntu-zun (see
https://review.opendev.org/c/openstack/openstack-ansible/+/883194 )
Depends-On: https://review.opendev.org/c/openstack/kolla/+/890464
Change-Id: I086e7bbc7db64421445731a533265e7056fbdb43
This commit adds the ironic-prometheus-exporter, following the
conventions used by the previously integrated exporters. '[The] Ironic
Prometheus Exporter is a Tool to expose hardware sensor data in the
Prometheus format through an HTTP endpoint.'[0]
Prometheus has been enabled in CI jobs to ensure test coverage.
[0] https://opendev.org/openstack/ironic-prometheus-exporter
Depends-On: https://review.opendev.org/c/openstack/kolla/+/874415
Change-Id: I6d421effd833d2e0524dd0b81736445c9a730ea9
ironic tftp service binds on 0.0.0.0. This may be
an issue in some setup. This patch propose a better
default, such as using the same listen address as
the dnsmasq service
Closes-Bug: #2024664
Change-Id: I0401bfc03cd31d72c5a2ae0a111889d5c29a8aa2
deployments
This allows services to work with etcd when coordination is enabled
for TLS internal deployments. Without this fix, we fail to connect to
etcd with the coordination backend and the service itself crashes.
Change-Id: I0c1d6b87e663e48c15a846a2774b0a4531a3ca68
A combination of durable queues and classic queue mirroring can be used
to provide high availability of RabbitMQ. However, these options should
only be used together, otherwise the system will become unstable. Using
the flag ``om_enable_rabbitmq_high_availability`` will either enable
both options at once, or neither of them.
There are some queues that should not be mirrored:
* ``reply`` queues (these have a single consumer and TTL policy)
* ``fanout`` queues (these have a TTL policy)
* ``amq`` queues (these are auto-delete queues, with a single consumer)
An exclusionary pattern is used in the classic mirroring policy. This
pattern is ``^(?!(amq\\.)|(.*_fanout_)|(reply_)).*``
Change-Id: I51c8023b260eb40b2eaa91bd276b46890c215c25
The ``[oslo_messaging_rabbit] heartbeat_in_pthread`` config option
is set to ``true`` for wsgi applications to allow the RabbitMQ
heartbeats to function. For non-wsgi applications it is set to ``false``
as it may otherwise break the service [1].
[1] https://docs.openstack.org/releasenotes/oslo.messaging/zed.html#upgrade-notes
Change-Id: Id89bd6158aff42d59040674308a8672c358ccb3c
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
