- Jul 23, 2018
-
-
Zuul authored
-
- Jul 20, 2018
-
-
Zuul authored
-
Zuul authored
-
Joshua Harlow authored
It is possible to have an accessible swift API that is not managed by kolla-ansible -- for example, ceph exposes a swift API, and using that requires setting swift as the glance backend. So, we should loosen the requirement that using the swift backend for glance requires swift be enabled in kolla-ansible. Co-Authored-By:
Adam Harwell <flux.adam@gmail.com> Change-Id: I17076d5412d2b1e1f13bb0badceaca85a5cee108
-
Zuul authored
-
Zuul authored
-
- Jul 19, 2018
-
-
Zuul authored
-
Zuul authored
-
Adam Harwell authored
The word "action" is now an Ansible reserved word, and things have transitioned to "kolla_action", but looks like this was missed. Change-Id: Ie07a2a7d8b153a6d39b91129256727157f8dfa34
-
Zuul authored
-
- Jul 18, 2018
-
-
Adam Harwell authored
In this patch, the glance-registry service was disabled: https://review.openstack.org/#/c/566804/ However, the config task still tries to copy files for it, which will break due to path errors. Change-Id: If39bb12bf830e6559342037ae2a2b99a784ee503
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
Minho Ban authored
The rsync prior to v3.1.0 the uid/gid parameter have no effect at all if it runs as normal(non-root) user. Since v3.1.0 these parameter are problematic for normal user because now rsync, regardless of root or non-root, if the parameters are given then it just tries to call setgroups() which is not possible for normal user so errors may occur. swift-object-replicator: @ERROR: setgroups failed\u0000 swift-object-replicator: rsync error: error starting client-server protocol (code 5) at main.c(1648) [sender=3.1.2]\u0000 Either way, these parameters are not needed for swift-rsync container. Change-Id: Ia7fe9f06d7a21a55f52b90c2cc1b2498300e6532 Signed-off-by:
Minho Ban <mhban@samsung.com>
-
- Jul 17, 2018
-
-
yuqian authored
Co-Authored-By:
caowei <cao.wei@99cloud.net> Co-Authored-By:
yuqian <yu.qian@99cloud.net> Change-Id: If8143b720203fe75cf586248f1fa1d3fde34c750 blueprint: onos-support
-
Zuul authored
-
Duong Ha-Quang authored
This patchset apply Ironic rolling upgrade logic [1][2] [1] https://docs.openstack.org/ironic/latest/contributor/rolling-upgrades.html [2] https://docs.openstack.org/ironic/latest/admin/upgrade-guide.html#rolling-upgrades Depends-On: https://review.openstack.org/#/c/575594/ Co-author: Ha Manh Dong <donghm@vn.fujitsu.com> Change-Id: Id68244951dc66d5c3423ef44324bd72058f4ba67 Implements: blueprint apply-service-upgrade-procedure
-
- Jul 16, 2018
-
-
Clint Byrum authored
This service is only required if you want to support cold migration. In some instances that is not a needed feature, and avoiding having another key to manage is an advantage. Co-Authored-By:
Adam Harwell <flux.adam@gmail.com> Change-Id: I0a55a91673d9178933f134832df4bd849ddf5af4
-
Clint Byrum authored
For large installations it makes sense to use a higher number of forks than the default. Change-Id: I34cdc146a4ed2185fb36fbb34ab72916ec98bee5
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
- Jul 15, 2018
- Jul 13, 2018
-
-
Zuul authored
-
- Jul 12, 2018
-
-
Lakshmi Prasanna Goutham Pratapa authored
This commit will constrain the dimensions of service `Nova` and sub-containers deployed along with it. A user can give the dimension values in `/etc/kolla/globals.yml` the data-types just like stated in this commit. Reference-Docs: https://docs.docker.com/config/containers/resource_constraints/ Added Test-cases for the same. Partially-Implements: blueprint resource-constraints Change-Id: I6458d8fb7b26a6e7c3a9fd0d674d9cf129b0bf5d
-
Doug Szumski authored
This is a Logstash component which reads processed logs from Kafka and writes them to Elasticsearch (or some other backend supported by Logstash). Ingesting the logs from this service with Fluentd will be covered under a different commit. Change-Id: I2d722991ab2072c54c4715507b19a4c9279f921b Partially-Implements: blueprint monasca-roles
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
Zuul authored
-
- Jul 11, 2018
-
-
Jorge Niedbalski authored
This patch extends the prometheus role for being able to deploy the prometheus-alertmanager[0] container. The variable enable_prometheus_alertmanager decides if the container should be deployed and enabled. If enabled, the following configuration and actions are performed: - The alerting section on the prometheus-server configuration is added pointing the prometheus-alertmanager host group as targets. - HAProxy is configured to load-balance over the prometheus-alertmanager host group. (external/internal). Please note that a default (dummy) configuration is provided, that allows the service to start, the operator should extend it via a node custom config [0] https://github.com/openstack/kolla/tree/master/docker/prometheus/prometheus-alertmanager Change-Id: I3a13342c67744a278cc8d52900a913c3ccc452ae Closes-Bug: 1774725 Signed-off-by:
Jorge Niedbalski <jorge.niedbalski@linaro.org>
-
Zuul authored
-
Zuul authored
-