Skip to content
Snippets Groups Projects
  1. Jan 21, 2025
  2. Aug 12, 2024
  3. Feb 15, 2024
  4. Jan 31, 2024
  5. Nov 30, 2023
  6. Aug 30, 2023
  7. Jan 13, 2023
    • Matt Crees's avatar
      Add a flag to handle RabbitMQ high availability · 09df6fc1
      Matt Crees authored
      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
      09df6fc1
  8. Jan 05, 2023
  9. Jul 12, 2022
    • Christian Berendt's avatar
      Set the ironic notification level · ced1e3b6
      Christian Berendt authored
      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
      ced1e3b6
  10. Jun 09, 2022
    • Will Szumski's avatar
      Add keystone_authtoken.service_type · 49006e56
      Will Szumski authored
      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
      49006e56
  11. May 28, 2022
    • Radosław Piliszek's avatar
      Do not use keystone_admin_url et al · 7ca9349b
      Radosław Piliszek authored
      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
      7ca9349b
  12. Apr 06, 2022
  13. Mar 04, 2022
  14. Sep 28, 2021
    • Niklas Hagman's avatar
      Transition Keystone admin user to system scope · 2e933dce
      Niklas Hagman authored
      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: default avatarNiklas Hagman <ubuntu@post.blinkiz.com>
      2e933dce
  15. Aug 06, 2021
    • Ilya Popov's avatar
      Extra var ironic_enable_keystone_integration added. · da4fd2d6
      Ilya Popov authored
      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
      da4fd2d6
  16. Jul 22, 2021
    • Mark Goddard's avatar
      ironic: always enable conductor HTTP server · 411668ea
      Mark Goddard authored
      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
      411668ea
  17. Oct 06, 2020
    • Mark Goddard's avatar
      Update ironic iPXE configuration · dd826417
      Mark Goddard authored
      * 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
      dd826417
  18. Sep 24, 2020
    • James Kirsch's avatar
      Add support for encrypting Ironic API · 7c2df87d
      James Kirsch authored
      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
      7c2df87d
  19. Sep 22, 2020
    • Pierre Riteau's avatar
      Reduce the use of SQLAlchemy connection pooling · c8177202
      Pierre Riteau authored
      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
      c8177202
  20. Sep 17, 2020
    • Mark Goddard's avatar
      Support TLS encryption of RabbitMQ client-server traffic · 761ea9a3
      Mark Goddard authored
      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
      761ea9a3
  21. Sep 10, 2020
    • Pierre Riteau's avatar
      Revert "Add support for encrypting Ironic API" · 3d30624c
      Pierre Riteau authored
      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
      3d30624c
  22. Aug 29, 2020
    • James Kirsch's avatar
      Add support for encrypting Ironic API · 316b0496
      James Kirsch authored
      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/
      316b0496
  23. Aug 19, 2020
    • Rafael Weingärtner's avatar
      Standardize use and construction of endpoint URLs · f425c067
      Rafael Weingärtner authored
      
      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: default avatarRafael Weingärtner <rafael@apache.org>
      f425c067
  24. Apr 28, 2020
  25. Apr 03, 2020
  26. Jan 13, 2020
    • James Kirsch's avatar
      Configure services to use Certificate Authority · c15dc203
      James Kirsch authored
      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
      c15dc203
  27. Oct 16, 2019
    • Radosław Piliszek's avatar
      Implement IPv6 support in the control plane · bc053c09
      Radosław Piliszek authored
      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: default avatarRadosław Piliszek <radoslaw.piliszek@gmail.com>
      bc053c09
  28. Sep 06, 2019
    • Mark Goddard's avatar
      Add [nova] section to ironic.conf · 8489a753
      Mark Goddard authored
      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
      8489a753
    • Mark Goddard's avatar
      Fix removed and deprecated options in ironic.conf · 3da05319
      Mark Goddard authored
      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
      3da05319
  29. Aug 29, 2019
  30. Aug 15, 2019
    • Rafael Weingärtner's avatar
      Standardize the configuration of "oslo_messaging" section · 22a6223b
      Rafael Weingärtner authored
      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: default avatarRafael Weingärtner <rafael@apache.org>
      22a6223b
  31. Mar 06, 2019
    • Jim Rollenhagen's avatar
      Allow ironic services to use independent hostnames · d1d1837c
      Jim Rollenhagen authored
      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
      d1d1837c
    • Jim Rollenhagen's avatar
      Use keystone_*_url var in all configs · 2e4e6050
      Jim Rollenhagen authored
      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
      2e4e6050
  32. Feb 22, 2019
    • Mark Goddard's avatar
      Improve standalone ironic support · 54965c87
      Mark Goddard authored
      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
      54965c87
  33. Feb 08, 2019
    • Jim Rollenhagen's avatar
      Allow neutron services to use independent hostnames · 255fff02
      Jim Rollenhagen authored
      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
      255fff02
    • Jim Rollenhagen's avatar
      Allow glance services to use independent hostnames · a819ef12
      Jim Rollenhagen authored
      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
      a819ef12
  34. Feb 04, 2019
    • Mark Goddard's avatar
      Set [pxe] tftp_server in ironic.conf · 4d646466
      Mark Goddard authored
      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
      4d646466
Loading