- Jan 21, 2025
-
-
Michal Nasiadka authored
Closes-Bug: #2062401 Change-Id: I2f2bdbc9e1c6ad6da4ac7098ddd36143123c3062 (cherry picked from commit 904fae2a)
-
- Aug 12, 2024
-
-
Roman Krček authored
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
-
- Feb 15, 2024
-
-
Bartosz Bezak authored
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
-
Bartosz Bezak authored
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
-
- Jan 31, 2024
-
-
Bartosz Bezak authored
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
-
- Nov 30, 2023
-
-
Sven Kieske authored
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
-
- Aug 30, 2023
-
-
Robin Klostermeyer authored
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
-
- Jan 13, 2023
-
-
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
-
- Jan 05, 2023
-
-
Matt Crees authored
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
-
- Jul 12, 2022
-
-
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
-
- Jun 09, 2022
-
-
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
-
- May 28, 2022
-
-
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
-
- Apr 06, 2022
-
-
Radosław Piliszek authored
Change-Id: I8e4096d7136d0ce9e54f1af0bb9ba110487fb35b
-
Radosław Piliszek authored
Depends-On: https://review.opendev.org/c/openstack/kolla/+/832163 Change-Id: Ia2dba1854e925041ae23c731273b810bb2d5ec30
-
- Mar 04, 2022
-
-
Radosław Piliszek authored
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
-
Radosław Piliszek authored
Set kernel_append_params instead. Change-Id: I4fb42d376636dc363cd86950ed37de4a3d28df73
-
- Sep 28, 2021
-
-
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:
Niklas Hagman <ubuntu@post.blinkiz.com>
-
- Aug 06, 2021
-
-
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
-
- Jul 22, 2021
-
-
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
-
- Oct 06, 2020
-
-
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
-
- Sep 24, 2020
-
-
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
-
- Sep 22, 2020
-
-
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
-
- Sep 17, 2020
-
-
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
-
- Sep 10, 2020
-
-
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
-
- Aug 29, 2020
-
-
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/
-
- Aug 19, 2020
-
-
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:
Rafael Weingärtner <rafael@apache.org>
-
- Apr 28, 2020
-
-
Marcin Juszkiewicz authored
Change-Id: I18f8855a758703968aba032add68add24b31f673 Closes-bug: #1875588
-
- Apr 03, 2020
-
-
Mark Goddard authored
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
-
- Jan 13, 2020
-
-
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
-
- Oct 16, 2019
-
-
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:
Radosław Piliszek <radoslaw.piliszek@gmail.com>
-
- Sep 06, 2019
-
-
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
-
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
-
- Aug 29, 2019
-
-
Will Szumski authored
Change-Id: Ic80dbe1f4f7289fe2c2143125a381cec4586f7ef Closes-Bug: #1841908
-
- Aug 15, 2019
-
-
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:
Rafael Weingärtner <rafael@apache.org>
-
- Mar 06, 2019
-
-
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
-
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
-
- Feb 22, 2019
-
-
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
-
- Feb 08, 2019
-
-
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
-
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
-
- Feb 04, 2019
-
-
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
-