Skip to content
Snippets Groups Projects
  1. Sep 18, 2019
  2. Sep 12, 2019
    • Scott Solkhon's avatar
      Enable Swift Recon · d463d3f7
      Scott Solkhon authored
      
      This commit adds the necessary configuration to the Swift account,
      container and object configuration files to enable the Swift recon
      cli.
      
      In order to give the object server on each Swift host access to the
      recon files, a Docker volume is mounted into each container which
      generates them. The volume is then mounted read only into the object
      server container. Note that multiple containers append to the same
      file. This should not be a problem since Swift uses a lock when
      appending.
      
      Change-Id: I343d8f45a78ebc3c11ed0c68fe8bec24f9ea7929
      Co-authored-by: default avatarDoug Szumski <doug@stackhpc.com>
      d463d3f7
  3. Sep 10, 2019
    • Hongbin Lu's avatar
      Configure Zun for Placement (Train+) · 0f5e0658
      Hongbin Lu authored
      After the integration with placement [1], we need to configure how
      zun-compute is going to work with nova-compute.
      
      * If zun-compute and nova-compute run on the same compute node,
        we need to set 'host_shared_with_nova' as true so that Zun
        will use the resource provider (compute node) created by nova.
        In this mode, containers and VMs could claim allocations against
        the same resource provider.
      * If zun-compute runs on a node without nova-compute, no extra
        configuration is needed. By default, each zun-compute will create
        a resource provider in placement to represent the compute node
        it manages.
      
      [1] https://blueprints.launchpad.net/zun/+spec/use-placement-resource-management
      
      Change-Id: I2d85911c4504e541d2994ce3d48e2fbb1090b813
      0f5e0658
  4. Sep 05, 2019
  5. Aug 23, 2019
  6. Aug 16, 2019
  7. Aug 15, 2019
  8. Aug 14, 2019
    • Scott Solkhon's avatar
      Add support for Swift S3 API · d72b27f2
      Scott Solkhon authored
      This feature is disabled by default, and can be enabled by setting
      'enable_swift_s3api' to 'true' in globals.yml.
      
      Two middlewares are required for Swift S3 - s3api and s3token. Additionally, we
      need to configure the authtoken middleware to delay auth decisions to give
      s3token a chance to authorise requests using EC2 credentials.
      
      Change-Id: Ib8e8e3a1c2ab383100f3c60ec58066e588d3b4db
      d72b27f2
  9. Aug 06, 2019
  10. Jul 16, 2019
    • Michal Nasiadka's avatar
      ceph-nfs: Add rpcbind to Ubuntu host bootstrap · efcaf400
      Michal Nasiadka authored
      * Ubuntu ships with nfs-ganesha 2.6.0, which requires to do an rpcbind
      udp test on startup (was fixed later)
      * Add rpcbind package to be installed by kolla-ansible bootstrap when
      ceph_nfs is enabled
      * Update Ceph deployment docs with a note
      
      Change-Id: Ic19264191a0ed418fa959fdc122cef543446fbe5
      efcaf400
  11. Jul 15, 2019
  12. Jul 10, 2019
  13. Jul 04, 2019
    • Mark Goddard's avatar
      Deprecate Ceph deployment · e6d0e610
      Mark Goddard authored
      There are now several good tools for deploying Ceph, including Ceph
      Ansible and ceph-deploy. Maintaining our own Ceph deployment is a
      significant maintenance burden, and we should focus on our core mission
      to deploy OpenStack. Given that this is a significant part of kolla
      ansible currently we will need a long deprecation period and a migration
      path to another tool.
      
      Change-Id: Ic603c85c04d8794580a19f9efaa7a8589565f4f6
      Partially-Implements: blueprint remove-ceph
      e6d0e610
  14. Jun 24, 2019
  15. Jun 20, 2019
    • Doug Szumski's avatar
      Add some notes for users Migrating to Kolla Monasca · c4f488ad
      Doug Szumski authored
      This commit should help guide people migrating to Kolla Monasca
      through the murky depths of the migration process. Since Kolla
      did not support Monasca in Queens, some of these steps which
      could be automated are not.
      
      Change-Id: I79051cca27178c3cf1671f5c603e38baf929c55c
      c4f488ad
  16. Jun 17, 2019
  17. Jun 07, 2019
  18. Jun 05, 2019
    • Gaetan Trellu's avatar
      Improve Qinling documentation · 557193a7
      Gaetan Trellu authored
      - Remove trusted_cidrs that has just been removed from
      Qinling code.
      - Remove use_api_certificate because it's true by default
      - Improve list syntax
      - Add etcd section
      
      Change-Id: I0426a9d61fbeaa23a1affbc7e981a78283e88263
      557193a7
  19. May 31, 2019
    • Gaetan Trellu's avatar
      Adds Qinling Ansible role · edb34898
      Gaetan Trellu authored
      Qinling is an OpenStack project to provide "Function as a Service".
      This project aims to provide a platform to support serverless functions.
      
      Change-Id: I239a0130f8c8b061b531dab530d65172b0914d7c
      Implements: blueprint ansible-qinling-support
      Story: 2005760
      Task: 33468
      edb34898
  20. May 30, 2019
  21. May 17, 2019
    • Mark Goddard's avatar
      Fix keystone fernet key rotation scheduling · 6c1442c3
      Mark Goddard authored
      Right now every controller rotates fernet keys. This is nice because
      should any controller die, we know the remaining ones will rotate the
      keys. However, we are currently over-rotating the keys.
      
      When we over rotate keys, we get logs like this:
      
       This is not a recognized Fernet token <token> TokenNotFound
      
      Most clients can recover and get a new token, but some clients (like
      Nova passing tokens to other services) can't do that because it doesn't
      have the password to regenerate a new token.
      
      With three controllers, in crontab in keystone-fernet we see the once a day
      correctly staggered across the three controllers:
      
      ssh ctrl1 sudo cat /etc/kolla/keystone-fernet/crontab
      0 0 * * * /usr/bin/fernet-rotate.sh
      ssh ctrl2 sudo cat /etc/kolla/keystone-fernet/crontab
      0 8 * * * /usr/bin/fernet-rotate.sh
      ssh ctrl3 sudo cat /etc/kolla/keystone-fernet/crontab
      0 16 * * * /usr/bin/fernet-rotate.sh
      
      Currently with three controllers we have this keystone config:
      
      [token]
      expiration = 86400 (although, keystone default is one hour)
      allow_expired_window = 172800 (this is the keystone default)
      
      [fernet_tokens]
      max_active_keys = 4
      
      Currently, kolla-ansible configures key rotation according to the following:
      
         rotation_interval = token_expiration / num_hosts
      
      This means we rotate keys more quickly the more hosts we have, which doesn't
      make much sense.
      
      Keystone docs state:
      
         max_active_keys =
           ((token_expiration + allow_expired_window) / rotation_interval) + 2
      
      For details see:
      https://docs.openstack.org/keystone/stein/admin/fernet-token-faq.html
      
      Rotation is based on pushing out a staging key, so should any server
      start using that key, other servers will consider that valid. Then each
      server in turn starts using the staging key, each in term demoting the
      existing primary key to a secondary key. Eventually you prune the
      secondary keys when there is no token in the wild that would need to be
      decrypted using that key. So this all makes sense.
      
      This change adds new variables for fernet_token_allow_expired_window and
      fernet_key_rotation_interval, so that we can correctly calculate the
      correct number of active keys. We now set the default rotation interval
      so as to minimise the number of active keys to 3 - one primary, one
      secondary, one buffer.
      
      This change also fixes the fernet cron job generator, which was broken
      in the following cases:
      
      * requesting an interval of more than 1 day resulted in no jobs
      * requesting an interval of more than 60 minutes, unless an exact
        multiple of 60 minutes, resulted in no jobs
      
      It should now be possible to request any interval up to a week divided
      by the number of hosts.
      
      Change-Id: I10c82dc5f83653beb60ddb86d558c5602153341a
      Closes-Bug: #1809469
      6c1442c3
  22. Apr 08, 2019
  23. Mar 14, 2019
    • Scott Solkhon's avatar
      Support separate Swift storage networks · a781c643
      Scott Solkhon authored
      Adds support to seperate Swift access and replication traffic from other storage traffic.
      
      In a deployment where both Ceph and Swift have been deployed,
      this changes adds functionalality to support optional seperation
      of storage network traffic. This adds two new network interfaces
      'swift_storage_interface' and 'swift_replication_interface' which maintain
      backwards compatibility.
      
      The Swift access network interface is configured via 'swift_storage_interface',
      which defaults to 'storage_interface'. The Swift replication network
      interface is configured via 'swift_replication_interface', which
      defaults to 'swift_storage_interface'.
      
      If a separate replication network is used, Kolla Ansible now deploys separate
      replication servers for the accounts, containers and objects, that listen on
      this network. In this case, these services handle only replication traffic, and
      the original account-, container- and object- servers only handle storage
      user requests.
      
      Change-Id: Ib39e081574e030126f2d08f51de89641ddb0d42e
      a781c643
  24. Mar 08, 2019
    • Doug Szumski's avatar
      Support customising Fluentd formatting · c8a22f10
      Doug Szumski authored
      In some scenarios it may be useful to perform custom formatting of logs
      before forwarding them. For example, the JSON formatter plugin can be
      used to convert an event to JSON.
      
      Change-Id: I3dd9240c5910a9477456283b392edc9566882dcd
      c8a22f10
  25. Mar 07, 2019
    • Arkadiy Shinkarev's avatar
      Added ability to skip enabled backends pre-check · 1d9f4f9f
      Arkadiy Shinkarev authored
      When using custom storage backends with cinder.conf overrides file,
      precheck stage in kolla-ansible is fail. This commit adds option
      'skip_cinder_backend_check' (default: False) to cinder role.
      
      Change-Id: Ifee138ad8b281903ea2365441aada044c80c46f0
      1d9f4f9f
  26. Feb 28, 2019
    • Mark Goddard's avatar
      Update links in docs to latest · fba5e1ce
      Mark Goddard authored
      To avoid links to OpenStack docs getting out of date in our docs, use
      the latest version.
      
      Ideally after cutting each stable branch we should change these links to
      use the current release.
      
      Co-Authored-By: Isaiah Inuwa
      Change-Id: Ia1e3c720f4e688861b8f76874a3943b0f4e50b17
      fba5e1ce
  27. Feb 25, 2019
  28. Feb 14, 2019
    • Doug Szumski's avatar
      Automate Monasca documentation for configuring Kafka · ecf00096
      Doug Szumski authored
      Until the Monasca Kafka client fork is removed it is currently required
      to run Kafka in compatibility mode. It is also necessary to disable
      an optimisation in the Kafka brokers to clean up idle connections. This
      is because the optimisation was added after the Monasca Kafka client was
      forked, and the client hasn't been updated since. These settings are now
      applied automatically when Monasca is enabled.
      
      Change-Id: I6935f1fb29f4f731cf3c9a70a0adf4d5812ca55e
      ecf00096
    • Pedro Alvarez's avatar
      Fix link to Manila Guide · 6c6759e9
      Pedro Alvarez authored
      Change-Id: I3defe0c38f41d7335e1cbafb75523c3cd44323ee
      6c6759e9
  29. Feb 07, 2019
  30. Feb 01, 2019
  31. Jan 24, 2019
    • binhong.hua's avatar
      add ulimit support for kolla_docker · 3d3f5f16
      binhong.hua authored
      By default, docker containers inherit ulimit from limits of docker
      deamon. On CentOS 7, docker daemon default NOFILE is 1048576.
      It can found in /usr/lib/systemd/system/docker.service.
      The big limit will cause many problem. we should control it in
      production environment.
      
      Change-Id: Iab962446a94ef092977728259d9818b86cfa7f68
      3d3f5f16
  32. Jan 13, 2019
  33. Jan 10, 2019
  34. Jan 08, 2019
  35. Jan 03, 2019
  36. Dec 17, 2018
    • Patrick O'Neill's avatar
      Add support for Quobyte backend to Cinder and Nova · f77cc87e
      Patrick O'Neill authored
      Add an enable_cinder_backend_quobyte option to etc/kolla/globals.yml to
      enable use the Quobyte Cinder backend.
      Change the bind mounts for /var/lib/nova/mnt to include the shared
      propogation if Quobyte is enabled.
      Update the documentation to include a section on configuring the Cinder.
      
      Implements: blueprint cinder-quobyte-backend
      
      Change-Id: I364939407ad244fe81cea40f880effdbcaa8a20d
      f77cc87e
  37. Nov 30, 2018
    • João Feteira's avatar
      Option neutron_plugin_agent: "opendaylight" added · f8f97481
      João Feteira authored
      Added the missing option neutron_plugin_agent: "opendaylight" added to
      the opendaylight documentation page. Without it the deployment would
      not use the neutron_plugin_agent but the default one: openvswitch .
      
      Change-Id: I56a377e1faab9a50f36383ea59b45bf5a9155bcf
      f8f97481
    • Paul Bourke's avatar
      Add note to external ceph docs for pools/keyrings · a47f7010
      Paul Bourke authored
      When using external Ceph the operator must create pools for each service
      and configure keyrings with appropriate permissions. The official Ceph
      docs describe this in detail so let operators know this.
      
      Change-Id: Ic3e52e1fbbf09ec09ac21b5b3067092b195812f1
      a47f7010
Loading