Skip to content
Snippets Groups Projects
  1. Aug 16, 2019
  2. Aug 15, 2019
    • Zuul's avatar
    • Zuul's avatar
      Merge "Testing Masakari role in gate" · fac64640
      Zuul authored
      fac64640
    • Zuul's avatar
      Merge "Add Masakari Ansible role" · bf372c25
      Zuul authored
      bf372c25
    • 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
    • Kien Nguyen's avatar
      Add Masakari Ansible role · 577bb50a
      Kien Nguyen authored
      Masakari provides Instances High Availability Service for
      OpenStack clouds by automatically recovering failed Instances.
      
      Depends-On: https://review.openstack.org/#/c/615469/
      
      
      Change-Id: I0b3457232ee86576022cff64eb2e227ff9bbf0aa
      Implements: blueprint ansible-masakari
      Co-Authored-By: default avatarGaëtan Trellu <gaetan.trellu@incloudus.com>
      577bb50a
    • Zuul's avatar
      Merge "Fix idempotency of fluentd customisations" · 6db0892f
      Zuul authored
      6db0892f
    • Zuul's avatar
      Merge "Enable iscsid on cinder-backup hosts" · dda18851
      Zuul authored
      dda18851
  3. Aug 14, 2019
  4. Aug 13, 2019
  5. Aug 12, 2019
  6. Aug 10, 2019
  7. Aug 09, 2019
  8. Aug 08, 2019
  9. Aug 07, 2019
    • Michal Nasiadka's avatar
      Add support for sha256 in ceph key distribution · ad9e8786
      Michal Nasiadka authored
      - add support for sha256 in bslurp module
      - change sha1 to sha256 in ceph-mon ansible role
      
      Depends-On: https://review.opendev.org/655623
      Change-Id: I25e28d150f2a8d4a7f87bb119d9fb1c46cfe926f
      Closes-Bug: #1826327
      ad9e8786
    • Marcin Juszkiewicz's avatar
      Stop using MountFlags=shared in Docker configuration · 35941738
      Marcin Juszkiewicz authored
      According to Docker upstream release notes [1] MountFlags should be
      empty.
      
      1. https://docs.docker.com/engine/release-notes/#18091
      
      "Important notes about this release
      
      In Docker versions prior to 18.09, containerd was managed by the Docker
      engine daemon. In Docker Engine 18.09, containerd is managed by systemd.
      Since containerd is managed by systemd, any custom configuration to the
      docker.service systemd configuration which changes mount settings (for
      example, MountFlags=slave) breaks interactions between the Docker Engine
      daemon and containerd, and you will not be able to start containers.
      
      Run the following command to get the current value of the MountFlags
      property for the docker.service:
      
      sudo systemctl show --property=MountFlags docker.service
      MountFlags=
      
      Update your configuration if this command prints a non-empty value for
      MountFlags, and restart the docker service."
      
      Closes-bug: #1833835
      
      Change-Id: I4f4cbb09df752d00073a606463c62f0a6ca6c067
      35941738
    • Mark Goddard's avatar
      Enable iscsid on cinder-backup hosts · ec075240
      Mark Goddard authored
      
      Without this we may see the following error in cinder-backup when using
      the LVM backend:
      
          Could not login to any iSCSI portal
      
      Enabling the iscsid container on hosts in the cinder-backup group fixes
      this.
      
      Closes-Bug: #1838624
      
      Change-Id: If373c002b0744ce9dbdffed50a02bab55dd0acb9
      Co-Authored-By: default avatardmitry-a-grachev <dmitry.a.grachev@gmail.com>
      ec075240
  10. Aug 06, 2019
  11. Aug 05, 2019
Loading