Closes-Bug: #2062401
Change-Id: I2f2bdbc9e1c6ad6da4ac7098ddd36143123c3062
(cherry picked from commit 904fae2a)

For possible config options see docs
https://docs.openstack.org/keystonemiddleware/latest/middlewarearchitecture.html#memcache-protection



Closes-bug: #1850733
Signed-off-by: Roman Krček <roman.krcek@tietoevry.com>
Change-Id: I169e27899f7350f5eb8adb1f81a062c51e6cbdfc

This reverts commit d77372e8.

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 recently started to enforce new policies and scope [1].
And Ironic is one of the sole openstack project which need
system scope for some admin related api calls [2].
However Ironic also started to allow project-scope behaviour
for service role with setting
``rbac_service_role_elevated_access``[3] [4]. This change enables
this setting to get similar behaviour of service role as other
openstack projects.

[1] https://review.opendev.org/c/openstack/ironic/+/902009
[2] https://opendev.org/openstack/governance/src/commit/e2a47de10a689a78c31765fd1b020f17c0d3109c/goals/selected/consistent-and-secure-rbac.rst?display=source#L261
[3] https://review.opendev.org/c/openstack/ironic/+/907148
[4] https://opendev.org/openstack/ironic/src/commit/8ec56066223301230ac0ed0f0c471a10d366b474/releasenotes/notes/service-project-service-role-fix-e4d1a8c23856926a.yaml

Related-Bug: #2051837

Change-Id: If8d7cf1663145d0398a2e936486e2b316d4df5e0

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

This implements a global toggle `om_enable_rabbitmq_quorum_queues`
to enable quorum queues for each service in RabbitMQ, similar to
what was done for HA[0].

Quorum Queues are enabled by default.

Quorum queues are more reliable, safer, simpler and faster than
replicated mirrored classic queues[1].

Mirrored classic queues are deprecated and scheduled for removal
in RabbitMQ 4.0[2].

Notice, that we do not need a new policy in the RabbitMQ definitions
template, because their usage is enabled on the client side and can't
be set using a policy[3].

Notice also, that quorum queues are not yet enabled in oslo.messaging
for the usage of reply_ and fanout_ queues (transient queues).
This will change once[4] is merged.

[0]: https://review.opendev.org/c/openstack/kolla-ansible/+/867771
[1]: https://www.rabbitmq.com/quorum-queues.html
[2]: https://blog.rabbitmq.com/posts/2021/08/4.0-deprecation-announcements/
[3]: https://www.rabbitmq.com/quorum-queues.html#declaring
[4]: https://review.opendev.org/c/openstack/oslo.messaging/+/888479



Signed-off-by: Sven Kieske <kieske@osism.tech>
Change-Id: I6c033d460a5c9b93c346e9e47e93b159d3c27830

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

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

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

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

Change-Id: I8e4096d7136d0ce9e54f1af0bb9ba110487fb35b

Depends-On: https://review.opendev.org/c/openstack/kolla/+/832163
Change-Id: Ia2dba1854e925041ae23c731273b810bb2d5ec30

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

Set kernel_append_params instead.

Change-Id: I4fb42d376636dc363cd86950ed37de4a3d28df73

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>

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

* 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 316b0496, 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>

Change-Id: I18f8855a758703968aba032add68add24b31f673
Closes-bug: #1875588

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

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

Introduce kolla_address filter.
Introduce put_address_in_context filter.

Add AF config to vars.

Address contexts:
- raw (default): <ADDR>
- memcache: inet6:[<ADDR>]
- url: [<ADDR>]

Other changes:

globals.yml - mention just IP in comment

prechecks/port_checks (api_intf) - kolla_address handles validation

3x interface conditional (swift configs: replication/storage)

2x interface variable definition with hostname
(haproxy listens; api intf)

1x interface variable definition with hostname with bifrost exclusion
(baremetal pre-install /etc/hosts; api intf)

neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network

basic multinode source CI job for IPv6

prechecks for rabbitmq and qdrouterd use proper NSS database now

MariaDB Galera Cluster WSREP SST mariabackup workaround
(socat and IPv6)

Ceph naming workaround in CI
TODO: probably needs documenting

RabbitMQ IPv6-only proto_dist

Ceph ms switch to IPv6 mode

Remove neutron-server ml2_type_vxlan/vxlan_group setting
as it is not used (let's avoid any confusion)
and could break setups without proper multicast routing
if it started working (also IPv4-only)

haproxy upgrade checks for slaves based on ipv6 addresses

TODO:

ovs-dpdk grabs ipv4 network address (w/ prefix len / submask)
not supported, invalid by default because neutron_external has no address
No idea whether ovs-dpdk works at all atm.

ml2 for xenapi
Xen is not supported too well.
This would require working with XenAPI facts.

rp_filter setting
This would require meddling with ip6tables (there is no sysctl param).
By default nothing is dropped.
Unlikely we really need it.

ironic dnsmasq is configured IPv4-only
dnsmasq needs DHCPv6 options and testing in vivo.

KNOWN ISSUES (beyond us):

One cannot use IPv6 address to reference the image for docker like we
currently do, see: https://github.com/moby/moby/issues/39033
(docker_registry; docker API 400 - invalid reference format)
workaround: use hostname/FQDN

RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4.
This is due to old RabbitMQ versions available in images.
IPv4 is preferred by default and may fail in the IPv6-only scenario.
This should be no problem in real life as IPv6-only is indeed IPv6-only.
Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will
no longer be relevant as we supply all the necessary config.
See: https://github.com/rabbitmq/rabbitmq-server/pull/1982

For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed
to work well). Older Ansible versions are known to miss IPv6 addresses
in interface facts. This may affect redeploys, reconfigures and
upgrades which run after VIP address is assigned.
See: https://github.com/ansible/ansible/issues/63227

Bifrost Train does not support IPv6 deployments.
See: https://storyboard.openstack.org/#!/story/2006689



Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c
Implements: blueprint ipv6-control-plane
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

In the Train cycle, ironic added a [nova] section to its configuration.
This is used to configure access to Nova API, for sending power state
callbacks.

This change adds the [nova] section to ironic.conf.

Change-Id: Ib891af1db2a2c838c887e858ea0721f5e6a4fab0
Closes-Bug: #1843070

The ironic configuration in ironic.conf uses several options which have
been removed in the Train cycle:

[glance] glance_api_servers was removed in https://review.opendev.org/#/c/665929.
[neutron] url was removed in https://review.opendev.org/#/c/672971.

We should use the endpoint catalog instead of specifying the endpoint
for both of these, and also ironic inspector. region_name and
valid_interfaces have been added for that purpose.

Other options are deprecated.

[conductor] api_url: Use [service_catalog] section to lookup ironic API
endpoint instead.

[inspector] enabled: No longer used.

Change-Id: If07c4ff9bfea7d780aeff5c3295a0ace7d10ecdc
Closes-Bug: #1843067

Change-Id: Ic80dbe1f4f7289fe2c2143125a381cec4586f7ef
Closes-Bug: #1841908

After all of the discussions we had on
"https://review.opendev.org/#/c/670626/2", I studied all projects that
have an "oslo_messaging" section. Afterwards, I applied the same method
that is already used in "oslo_messaging" section in Nova, Cinder, and
others. This guarantees that we have a consistent method to
enable/disable notifications across projects based on components (e.g.
Ceilometer) being enabled or disabled. Here follows the list of
components, and the respective changes I did.

* Aodh:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.

* Congress:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.

* Cinder:
It was already properly configured.

* Octavia:
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.

* Heat:
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Ceilometer:
Ceilometer publishes some messages in the rabbitMQ. However, the
default driver is "messagingv2", and not ''(empty) as defined in Oslo;
these configurations are defined in ceilometer/publisher/messaging.py.
Therefore, we do not need to do anything for the
"oslo_messaging_notifications" section in Ceilometer

* Tacker:
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Neutron:
It was already properly configured.

* Nova
It was already properly configured. However, we found another issue
with its configuration. Kolla-ansible does not configure nova
notifications as it should. If 'searchlight' is not installed (enabled)
the 'notification_format' should be 'unversioned'. The default is
'both'; so nova will send a notification to the queue
versioned_notifications; but that queue has no consumer when
'searchlight' is disabled. In our case, the queue got 511k messages.
The huge amount of "stuck" messages made the Rabbitmq cluster
unstable.

https://bugzilla.redhat.com/show_bug.cgi?id=1478274
https://bugs.launchpad.net/ceilometer/+bug/1665449

* Nova_hyperv:
I added the same configurations as in Nova project.

* Vitrage
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Searchlight
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.

* Ironic
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.

* Glance
It was already properly configured.

* Trove
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Blazar
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Sahara
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Watcher
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.

* Barbican
I created a mechanism similar to what we have in Cinder, Nova,
and others. I also added a configuration to 'keystone_notifications'
section. Barbican needs its own queue to capture events from Keystone.
Otherwise, it has an impact on Ceilometer and other systems that are
connected to the "notifications" default queue.

* Keystone
Keystone is the system that triggered this work with the discussions
that followed on https://review.opendev.org/#/c/670626/2

. After a long
discussion, we agreed to apply the same approach that we have in Nova,
Cinder and other systems in Keystone. That is what we did. Moreover, we
introduce a new topic "barbican_notifications" when barbican is
enabled. We also removed the "variable" enable_cadf_notifications, as
it is obsolete, and the default in Keystone is CADF.

* Mistral:
It was hardcoded "noop" as the driver. However, that does not seem a
good practice. Instead, I applied the same standard of using the driver
and pushing to "notifications" queue if Ceilometer is enabled.

* Cyborg:
I created a mechanism similar to what we have in AODH, Cinder, Nova,
and others.

* Murano
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Senlin
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Manila
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Zun
The section is declared, but it is not used. Therefore, it will
be removed in an upcomming PR.

* Designate
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

* Magnum
It was already using a similar scheme; I just modified it a little bit
to be the same as we have in all other components

Closes-Bug: #1838985

Change-Id: I88bdb004814f37c81c9a9c4e5e491fac69f6f202
Signed-off-by: Rafael Weingärtner <rafael@apache.org>

This allows ironic service endpoints to use custom hostnames, and adds the
following variables:

* ironic_internal_fqdn
* ironic_external_fqdn
* ironic_inspector_internal_fqdn
* ironic_inspector_external_fqdn

These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.

This also adds ironic_api_listen_port and ironic_inspector_listen_port
options, which default to ironic_api_port and ironic_inspector_port for
backward compatibility.

These options allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.

Change-Id: I45b175e85866b4cfecad8451b202a5a27f888a84
Implements: blueprint service-hostnames

We're duplicating code to build the keystone URLs in nearly every
config, where we've already done it in group_vars. Replace the
redundancy with a variable that does the same thing.

Change-Id: I207d77870e2535c1cdcbc5eaf704f0448ac85a7a

Adds a new flag, 'enable_openstack_core', which defaults to 'yes'.
Setting this flag to 'no' will disable the core OpenStack services,
including Glance, Heat, Horizon, Keystone, Neutron, and Nova.

Improves the default configuration of OpenStack Ironic when used in
standalone mode. In particular, configures a noauth mode when Keystone
is disabled, and allows the iPXE server to be used for provisioning as
well as inspection if Neutron is disabled.

Documentation for standalone ironic will be updated separately.

This patch was developed and tested using Bikolla [1].

[1] https://github.com/markgoddard/bikolla

Change-Id: Ic47f5ad81b8126a51e52a445097f7950dba233cd
Implements: blueprint standalone-ironic

This allows neutron service endpoints to use custom hostnames, and adds the
following variables:

* neutron_internal_fqdn
* neutron_external_fqdn

These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.

This also adds a neutron_server_listen_port option, which defaults to
neutron_server_port for backward compatibility.

This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.

Change-Id: I87d7387326b6eaa6adae1600b48d480319d10676
Implements: blueprint service-hostnames

This allows glance service endpoints to use custom hostnames, and adds the
following variables:

* glance_internal_fqdn
* glance_external_fqdn

These default to the old values of kolla_internal_fqdn or
kolla_external_fqdn.

This also adds a glance_api_listen_port option, which defaults to
glance_api_port for backward compatibility.

This option allow the user to differentiate between the port the
service listens on, and the port the service is reachable on. This is
useful for external load balancers which live on the same host as the
service itself.

Change-Id: Icb91f728533e2db1908b23dabb0501cf9f8a2b75
Implements: blueprint service-hostnames

The ironic TFTP server should be accessed via the internal API network.
For ironic inspector, dnsmasq.conf advertises this correctly:

dhcp-option=option:tftp-server,'api_interface_address'
dhcp-option=option:server-ip-address,'api_interface_address'

However, ironic conductor does not set the [pxe] tftp_server variable.
This means the TFTP server advertised gets the default value of $my_ip,
which is set by
https://docs.openstack.org/oslo.utils/latest/reference/netutils.html#oslo_utils.netutils.get_my_ipv4,
typically the source IP for the default route.

This change sets [pxe] tftp_server to 'api_interface_address'.

Change-Id: Ic3e688b3f2b92ad9515322f49cd5f4f29d763e49
Closes-Bug: #1808347