Skip to content
Snippets Groups Projects
  1. Jul 12, 2022
    • Michal Arbet's avatar
      Add api_workers for each service to defaults · 3e8db91a
      Michal Arbet authored
      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
      3e8db91a
  2. May 23, 2022
  3. Apr 20, 2022
  4. Apr 13, 2022
    • Maksim Malchuk's avatar
      Multiple DHCP ranges for Ironic Inspector · 762aecbf
      Maksim Malchuk authored
      
      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: default avatarMaksim Malchuk <maksim.malchuk@gmail.com>
      Co-Authored-By: default avatarRadosław Piliszek <radoslaw.piliszek@gmail.com>
      762aecbf
  5. Apr 06, 2022
  6. Feb 10, 2022
    • Mark Goddard's avatar
      ironic: sync default inspection UEFI iPXE bootloader with Ironic · 556d9799
      Mark Goddard authored
      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
      556d9799
  7. Dec 31, 2021
    • Pierre Riteau's avatar
      Move project_name and kolla_role_name to role vars · 56fc74f2
      Pierre Riteau authored
      Role vars have a higher precedence than role defaults. This allows to
      import default vars from another role via vars_files without overriding
      project_name (see related bug for details).
      
      Change-Id: I3d919736e53d6f3e1a70d1267cf42c8d2c0ad221
      Related-Bug: #1951785
      56fc74f2
  8. Dec 21, 2021
    • Dr. Jens Harbott's avatar
      Stop creating non-keystone admin endpoints · 479a7870
      Dr. Jens Harbott authored
      
      The admin interface for endpoints never had any real use, the
      functionality was the same as for the public or internal endpoints,
      except for Keystone. Even for Keystone with API v3 it would no longer
      really be needed, but it is still being required by some libraries that
      cannot be changed in order to stay backwards compatible.
      
      Signed-off-by: default avatarDr. Jens Harbott <harbott@osism.tech>
      Change-Id: Icf3bf08deab2c445361f0a0124d87ad8b0e4e9d9
      479a7870
  9. 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
  10. 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
  11. Jul 21, 2021
    • Mark Goddard's avatar
      Fix ironic_ipxe healthcheck on Debian/Ubuntu · aa28675c
      Mark Goddard authored
      The healthcheck checks for a process called httpd, but these distros
      call it apache2.  This results in the ironic_ipxe container being marked
      as unhealthy.
      
      This change fixes the issue by making the process name distro dependent.
      
      Change-Id: I0b0126e3071146e7f8593ba970ecbed65b36fcfa
      Closes-Bug: #1937037
      aa28675c
  12. Jun 23, 2021
    • Mark Goddard's avatar
      Use ansible_facts to reference facts · ade5bfa3
      Mark Goddard authored
      By default, Ansible injects a variable for every fact, prefixed with
      ansible_. This can result in a large number of variables for each host,
      which at scale can incur a performance penalty. Ansible provides a
      configuration option [0] that can be set to False to prevent this
      injection of facts. In this case, facts should be referenced via
      ansible_facts.<fact>.
      
      This change updates all references to Ansible facts within Kolla Ansible
      from using individual fact variables to using the items in the
      ansible_facts dictionary. This allows users to disable fact variable
      injection in their Ansible configuration, which may provide some
      performance improvement.
      
      This change disables fact variable injection in the ansible
      configuration used in CI, to catch any attempts to use the injected
      variables.
      
      [0] https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars
      
      Change-Id: I7e9d5c9b8b9164d4aee3abb4e37c8f28d98ff5d1
      Partially-Implements: blueprint performance-improvements
      ade5bfa3
  13. Mar 08, 2021
    • LinPeiWen's avatar
      Use Docker healthchecks for ironic services · cb537eb8
      LinPeiWen authored
      This change enables the use of Docker healthchecks for ironic services.
      Implements: blueprint container-health-check
      
      Change-Id: If0a11db5470899c3a0e69ca94fdd0903daadcf8b
      cb537eb8
  14. Dec 08, 2020
  15. 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
  16. 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
  17. 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
  18. 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
  19. Aug 10, 2020
    • Mark Goddard's avatar
      Mount /etc/timezone based on host OS · 146b00ef
      Mark Goddard authored
      Previously we mounted /etc/timezone if the kolla_base_distro is debian
      or ubuntu. This would fail prechecks if debian or ubuntu images were
      deployed on CentOS. While this is not a supported combination, for
      correctness we should fix the condition to reference the host OS rather
      than the container OS, since that is where the /etc/timezone file is
      located.
      
      Change-Id: Ifc252ae793e6974356fcdca810b373f362d24ba5
      Closes-Bug: #1882553
      146b00ef
  20. Apr 09, 2020
    • Dincer Celik's avatar
      Introduce /etc/timezone to Debian/Ubuntu containers · 4b5df0d8
      Dincer Celik authored
      Some services look for /etc/timezone on Debian/Ubuntu, so we should
      introduce it to the containers.
      
      In addition, added prechecks for /etc/localtime and /etc/timezone.
      
      Closes-Bug: #1821592
      Change-Id: I9fef14643d1bcc7eee9547eb87fa1fb436d8a6b3
      4b5df0d8
  21. Jan 30, 2020
    • Mark Goddard's avatar
      Python 3: Use distro_python_version for dev mode · 5a786436
      Mark Goddard authored
      In dev mode currently the python source is mounted under python2.7
      site-packages. This change fixes this to use the distro_python_version
      variable to ensure dev mode works with Python 3 images.
      
      Change-Id: Ieae3778a02f1b79023b4f1c20eff27b37f481077
      Partially-Implements: blueprint python-3
      5a786436
  22. Jan 10, 2020
    • Mark Goddard's avatar
      CentOS 8: Support variable image tag suffix · 9755c924
      Mark Goddard authored
      For the CentOS 7 to 8 transition, we will have a period where both
      CentOS 7 and 8 images are available. We differentiate these images via a
      tag - the CentOS 8 images will have a tag of train-centos8 (or
      master-centos8 temporarily).
      
      To achieve this, and maintain backwards compatibility for the
      openstack_release variable, we introduce a new 'openstack_tag' variable.
      This variable is based on openstack_release, but has a suffix of
      'openstack_tag_suffix', which is empty except on CentOS 8 where it has a
      value of '-centos8'.
      
      Change-Id: I12ce4661afb3c255136cdc1aabe7cbd25560d625
      Partially-Implements: blueprint centos-rhel-8
      9755c924
  23. Dec 12, 2019
    • Mark Goddard's avatar
      Allow ironic_ipxe to serve instance images · 2b662cfb
      Mark Goddard authored
      Ironic provides a feature to allow instance images to be served from a
      local HTTP server [1]. This is the same server used for PXE images with
      iPXE. This does not work currently because the ironic_ipxe container
      does not have access to /var/lib/ironic/images (ironic docker volume),
      where the images are cached. Note that to make use of this feature, the
      following is required in ironic.conf:
      
      [agent]
      image_download_source = http
      
      This change fixes the issue by giving ironic_ipxe container access to
      the ironic volume.
      
      [1] https://docs.openstack.org/ironic/latest/admin/interfaces/deploy.html#deploy-with-custom-http-servers
      
      Change-Id: I501d02cfd40fbacea32d551c3912640c5661d821
      Closes-Bug: #1856194
      2b662cfb
  24. 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
  25. Sep 17, 2019
  26. 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
  27. May 17, 2019
    • binhong.hua's avatar
      Make kolla-ansible support extra volumes · 12ff28a6
      binhong.hua authored
      When integrating 3rd party component into openstack with kolla-ansible,
      maybe have to mount some extra volumes to container.
      
      Change-Id: I69108209320edad4c4ffa37dabadff62d7340939
      Implements: blueprint support-extra-volumes
      12ff28a6
  28. Apr 08, 2019
    • Mark Goddard's avatar
      Use ironic inspector 'dnsmasq' PXE filter by default · 86e83fae
      Mark Goddard authored
      With Docker CE, the daemon sets the default policy of the iptables
      FORWARD chain to DROP. This causes problems for provisioning bare metal
      servers when ironic inspector is used with the 'iptables' PXE filter.
      It's not entirely clear why these two things interact in this way,
      but switching to the 'dnsmasq' filter works around the issue, and is
      probably a good move anyway because it is more efficient.
      
      We have added a migration task here to flush and remove the ironic-inspector
      iptables chain since inspector does not do this itself currently.
      
      Change-Id: Iceed5a096819203eb2b92466d39575d3adf8e218
      Closes-Bug: #1823044
      86e83fae
  29. 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
  30. 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
  31. Nov 20, 2018
    • Mark Goddard's avatar
      Support Ironic Inspector dnsmasq PXE filter · 4418c164
      Mark Goddard authored
      The dnsmasq PXE filter [1] provides far better scalability than the
      iptables filter typically used. Inspector manages files in a dhcp-hostsdir
      directory that is watched by dnsmasq via inotify. Dnsmasq then either
      whitelists or blacklists MAC addresses based on the contents of these
      files.
      
      This change adds a new variable, ironic_inspector_pxe_filter, that can
      be used to configure the PXE filter for ironic inspector. Currently
      supported values are 'iptables' and 'dnsmasq', with 'iptables' being the
      default for backwards compatibility.
      
      [1]
      https://docs.openstack.org/ironic-inspector/latest/admin/dnsmasq-pxe-filter.html
      
      Implements: blueprint ironic-inspector-dnsmasq-pxe-filter
      Change-Id: I73cae9c33b49972342cf1984372a5c784df5cbc2
      4418c164
  32. Sep 26, 2018
    • Adam Harwell's avatar
      Refactor haproxy config (split by service) V2.0 · f1c81365
      Adam Harwell authored
      Having all services in one giant haproxy file makes altering
      configuration for a service both painful and dangerous. Each service
      should be configured with a simple set of variables and rendered with a
      single unified template.
      
      Available are two new templates:
      
      * haproxy_single_service_listen.cfg.j2: close to the original style, but
      only one service per file
      * haproxy_single_service_split.cfg.j2: using the newer haproxy syntax
      for separated frontend and backend
      
      For now the default will be the single listen block, for ease of
      transition.
      
      Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b
      f1c81365
  33. Aug 14, 2018
  34. Aug 03, 2018
  35. Jul 26, 2018
    • Lakshmi Prasanna Goutham Pratapa's avatar
      Apply Resource Constraints to Services. · 14bf5247
      Lakshmi Prasanna Goutham Pratapa authored
      This commit is to apply resource-constraints to a few more OpenStack services.
      Commit to  apply constraints to the last set of services will be made in
      the upcoming commit.
      
      Depends-on: Icafa54baca24d2de64238222a5677b9d8b90e2aa
      Change-Id: I39004f54281f97d53dfa4b1dbcf248650ad6f186
      14bf5247
  36. Jul 25, 2018
  37. Jul 17, 2018
  38. Jun 04, 2018
    • wu.chunyang's avatar
      dev mode: Add support for ironic · 291c04c8
      wu.chunyang authored
      Allows users to develop on ironic using Kolla.
      
      Partially implements: blueprint mount-sources
      
      Change-Id: I74540f5bcbf723f097f3dea96dcaf067834c493a
      291c04c8
Loading