Compare commits

..

21 Commits

Author SHA1 Message Date
licanwei
a8974556ec Don't throw exception when missing metrics
When querying data from datasource, it's possible to miss some data.
In this case if we throw an exception, Audit will failed because of
the exception. We should remove the exception and give the decision
to the strategy.

Change-Id: I1b0e6b78b3bba4df9ba16e093b3910aab1de922e
Closes-Bug: #1847434
can not cherry picke from master because of code refactoring
(cherry picked from commit 306224f70c)
2019-10-21 03:26:36 +00:00
Stamatis Katsaounis
6a4a9af538 Fix issues on stable/rocky
This patch fixes issues present to stable/rocky branch. Due to heavy
refactoring in later branches backporting is no possible.

Change-Id: I896a7c49eea1b267099fc90d837458ec7bb7853d
Signed-off-by: Stamatis Katsaounis <skatsaounis@admin.grnet.gr>
2019-10-09 10:31:53 +03:00
Zuul
214ee82e45 Merge "pass default_config_dirs variable for config initialization." into stable/rocky 2019-09-18 02:00:25 +00:00
Guang Yee
5c7fcc22c0 fix test failure with ironic client
The watcher.tests.common.test_clients.TestClients.test_clients_ironic unit
test's been failure since python-ironicclient 2.5.2 release. In that release,
we fixed a bug with the interface argument was ignored.

https://docs.openstack.org/releasenotes/python-ironicclient/rocky.html#relnotes-2-5-2-stable-rocky

Therefore, we need to adjust the ironic test case in watcher to account for
the interface argument.

Change-Id: Iedb27efc9f296054fcbd485b27736a789cee3496
2019-09-16 10:33:36 -07:00
Sumit Jamgade
4db5a58d0d pass default_config_dirs variable for config initialization.
Currently default config files are being for initialization of CONF from
oslo_config. However default config dirs are not being passed as a
result watcher components (eg: decision-engine) are unable to load
files from default directories (eg: /etc/watcher/watcher.conf.d)
supported by oslo_config. This is a short-coming on watcher's side.
Also this forces user to have multiple config for each component.

Without this default set, oslo_config will search for conf with string
'python-watcher' in it, eg: /etc/python-watcher/.... Since there is a
because project=python-watcher a couple of lines below

This patch adds the option after evaluating using project as 'watcher'
which is similar to evaluation of default_config_files and also allows
it to be passed in as a function parameter.

Change-Id: I013f9d03978f8716847f8d1ee6888629faf5779b
(cherry picked from commit dce23d7eb4)
(cherry picked from commit ec5780902f)
2019-09-16 15:29:29 +00:00
OpenDev Sysadmins
0a20d27860 OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:

http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html

Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.
2019-04-19 19:40:47 +00:00
Ian Wienand
dc9dba2fda Replace openstack.org git:// URLs with https://
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.

This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.

This update should result in no functional change.

For more information see the thread at

 http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html

Change-Id: I90059bb4fdbe0b5355170999896accde0dc3e59b
2019-03-24 20:36:26 +00:00
Zuul
6203a280ce Merge "Access to action's uuid by key" into stable/rocky 2019-03-16 04:23:08 +00:00
licanwei
294c3cd760 set watcherclient no voting
Change-Id: I817328148559dd35755a706085247f3547b188cb
2019-03-15 17:13:20 +08:00
Tatiana Kholkina
d226c5d0fb Access to action's uuid by key
Change-Id: I9fe992be8f54de51f0c8e0a9fcf7880c68360929
Closes-Bug: #1818962
(cherry picked from commit e830d3793e)
2019-03-15 06:30:13 +00:00
Sumit Jamgade
abbe182cf1 make ceilometer client import optional
on ImportError set HAS_CEILCLIENT to false

Without this none of the watcher componenets can be started for master
as well as rocky because the ceilometercleint was deprecated.

Using the variable the support for ceilometer can be gradually removed
from master

A backport to rocky will allow using watcher without ceilometerclient.

Change-Id: I3beb0fb8f0a8e8e0a22acaf6bdeca492836bbee2
2019-03-04 03:56:28 +00:00
Tatiana Kholkina
c1c0a472dd Provide two arguments to exception's message
Change-Id: I003c9e88abb08b11c22b008936413ee51f6096b1
Closes-Bug: #1817533
(cherry picked from commit 594039f794)
2019-02-27 07:06:39 +00:00
Alexander Chadin
bb0e959bd2 Fix stop_watcher function
Apache should be reloaded after watcher-api is disabled.

Change-Id: Ifee0e7701849348630568aa36b3f3c4c62d3382e
2018-12-10 13:55:52 +00:00
Tatiana Kholkina
41bfba5cac Fix accessing to optional cinder pool attributes
Leave storage pool arguments empty if they are not provided
by cinderclient.

Change-Id: I90435146b33465c8eef95a6104e53285f785b014
Closes-Bug: #1800468
(cherry picked from commit e8c08e2abb)
2018-11-08 09:26:35 +00:00
licanwei
ef66e75b77 optimize get_instances_by_node
We can set host filed in search_opts.
refer to:
https://developer.openstack.org/api-ref/compute/?expanded=list-servers-detail#list-servers

Change-Id: I36b27167d7223f3bf6bb05995210af41ad01fc6d
2018-11-06 10:40:23 +00:00
Tatiana Kholkina
f517cc662a Use limit -1 for nova servers list
By default nova has a limit for returned items in a single response [1].
We should pass limit=-1 to get all items.

[1] https://docs.openstack.org/nova/rocky/configuration/config.html

Change-Id: I1fabd909c4c0356ef5fcb7c51718fb4513e6befa
2018-10-16 08:37:37 +00:00
Tatiana Kholkina
d99e8f33da Do not pass www_authenticate_uri to RequestContext
Change-Id: I0ee32031d714608c33643b12b1e217a04157f5b3
Closes-Bug: #1795613
(cherry picked from commit f0b96b8a37)
2018-10-04 05:51:25 +00:00
Tatiana Kholkina
ef14aec225 Provide region name while initialize clients
Add new option 'region_name' to config for each client section.

Change-Id: Ifad8908852f4be69dd294a4c4ab28d2e1df265e8
Closes-Bug: #1787937
(cherry picked from commit 925b971377)
2018-09-21 12:08:12 +00:00
Nguyen Hai
546012bed4 import zuul job settings from project-config
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.

Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.

Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.

See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html

Change-Id: I7a7838d04c7a22c1c80d211393c1e1be10f3e0b0
Story: #2002586
Task: #24344
2018-08-19 00:59:24 +09:00
OpenStack Release Bot
9be780b2b9 Update UPPER_CONSTRAINTS_FILE for stable/rocky
The new stable upper-constraints file is only available
after the openstack/requirements repository is branched.
This will happen around the RC1 timeframe.

Recheck and merge this change once the requirements
repository has been branched.

The CI system will work with this patch before the requirements
repository is branched because zuul configues the job to run
with a local copy of the file and defaults to the master branch.
However, accepting the patch will break the test configuration
on developers' local systems, so please wait until after the
requirements repository is branched to merge the patch.

Change-Id: I1070c8dff1b38f7335eb7cfc55fcca9b94383199
2018-08-08 14:10:47 +00:00
OpenStack Release Bot
f80e7098fd Update .gitreview for stable/rocky
Change-Id: I8c1d18f7f38b23f4763b4b57a455f42ac6adbde9
2018-08-08 14:10:45 +00:00
685 changed files with 10018 additions and 29822 deletions

4
.gitignore vendored
View File

@@ -26,7 +26,6 @@ pip-log.txt
.stestr/
.venv
.idea
.testrepository/
# Translations
*.mo
@@ -75,6 +74,3 @@ releasenotes/build
# Autogenerated sample config file
etc/watcher/watcher.conf.sample
# Atom
.remote-sync.json

View File

@@ -2,3 +2,4 @@
host=review.opendev.org
port=29418
project=openstack/watcher.git
defaultbranch=stable/rocky

View File

@@ -1,62 +0,0 @@
---
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v5.0.0
hooks:
# whitespace
- id: trailing-whitespace
- id: mixed-line-ending
args: ['--fix', 'lf']
exclude: '.*\.(svg)$'
- id: check-byte-order-marker
# file format and permissions
- id: check-ast
- id: debug-statements
- id: check-json
files: .*\.json$
- id: check-yaml
files: .*\.(yaml|yml)$
- id: check-executables-have-shebangs
- id: check-shebang-scripts-are-executable
# git
- id: check-added-large-files
- id: check-case-conflict
- id: detect-private-key
- id: check-merge-conflict
- repo: https://github.com/Lucas-C/pre-commit-hooks
rev: v1.5.5
hooks:
- id: remove-tabs
exclude: '.*\.(svg)$'
- repo: https://opendev.org/openstack/hacking
rev: 7.0.0
hooks:
- id: hacking
additional_dependencies: []
exclude: '^(doc|releasenotes|tools)/.*$'
- repo: https://github.com/PyCQA/bandit
rev: 1.8.3
hooks:
- id: bandit
args: ['-x', 'tests', '-s', 'B101,B311,B320']
- repo: https://github.com/hhatto/autopep8
rev: v2.3.2
hooks:
- id: autopep8
files: '^.*\.py$'
- repo: https://github.com/codespell-project/codespell
rev: v2.4.1
hooks:
- id: codespell
args: ['--ignore-words=doc/dictionary.txt']
- repo: https://github.com/sphinx-contrib/sphinx-lint
rev: v1.0.0
hooks:
- id: sphinx-lint
args: [--enable=default-role]
files: ^doc/|^releasenotes/|^api-guide/
types: [rst]
- repo: https://github.com/PyCQA/doc8
rev: v1.1.2
hooks:
- id: doc8

View File

@@ -1,30 +1,76 @@
- project:
templates:
- openstack-python-jobs
- openstack-python35-jobs
- publish-openstack-sphinx-docs
- check-requirements
- release-notes-jobs
check:
jobs:
- watcher-tempest-functional
- watcher-tempest-dummy_optim
- watcher-tempest-actuator
- watcher-tempest-basic_optim
- watcher-tempest-workload_balancing
- watcherclient-tempest-functional
- watcher-tempest-zone_migration
- openstack-tox-lower-constraints
gate:
queue: watcher
jobs:
- watcher-tempest-functional
- openstack-tox-lower-constraints
- job:
name: watcher-tempest-dummy_optim
parent: watcher-tempest-multinode
voting: false
vars:
tempest_test_regex: watcher_tempest_plugin.tests.scenario.test_execute_dummy_optim
- job:
name: watcher-tempest-actuator
parent: watcher-tempest-multinode
voting: false
vars:
tempest_test_regex: watcher_tempest_plugin.tests.scenario.test_execute_actuator
- job:
name: watcher-tempest-strategies
name: watcher-tempest-basic_optim
parent: watcher-tempest-multinode
voting: false
vars:
tempest_concurrency: 1
# All tests inside watcher_tempest_plugin.tests.scenario with tag "strategy"
# or test_execute_strategies file
# excluding tests with tag "real_load"
tempest_test_regex: (^watcher_tempest_plugin.tests.scenario)(.*\[.*\bstrategy\b.*\].*)|(^watcher_tempest_plugin.tests.scenario.test_execute_strategies)
tempest_exclude_regex: .*\[.*\breal_load\b.*\].*
tempest_test_regex: watcher_tempest_plugin.tests.scenario.test_execute_basic_optim
- job:
name: watcher-tempest-workload_balancing
parent: watcher-tempest-multinode
voting: false
vars:
tempest_test_regex: watcher_tempest_plugin.tests.scenario.test_execute_workload_balancing
- job:
name: watcher-tempest-zone_migration
parent: watcher-tempest-multinode
voting: false
vars:
tempest_test_regex: watcher_tempest_plugin.tests.scenario.test_execute_zone_migration
- job:
name: watcher-tempest-multinode
parent: watcher-tempest-functional
nodeset: openstack-two-node-noble
nodeset: openstack-two-node
pre-run: playbooks/pre.yaml
run: playbooks/orchestrate-tempest.yaml
roles:
- zuul: openstack/tempest
group-vars:
subnode:
devstack_local_conf:
post-config:
$NOVA_CONF:
libvirt:
live_migration_uri: qemu+ssh://root@%s/system
$WATCHER_CONF:
watcher_cluster_data_model_collectors.compute:
period: 120
@@ -32,16 +78,12 @@
period: 120
watcher_cluster_data_model_collectors.storage:
period: 120
$CINDER_CONF:
# enable notifications in compute node, by default they are only
# configured in the controller
oslo_messaging_notifications:
driver: messagingv2
devstack_services:
watcher-api: false
watcher-decision-engine: true
watcher-applier: false
c-bak: false
# We need to add TLS support for watcher plugin
tls-proxy: false
ceilometer: false
ceilometer-acompute: false
ceilometer-acentral: false
@@ -52,15 +94,11 @@
rabbit: false
mysql: false
vars:
devstack_localrc:
GNOCCHI_ARCHIVE_POLICY_TEMPEST: "ceilometer-low-rate"
CEILOMETER_PIPELINE_INTERVAL: 15
devstack_services:
ceilometer-acompute: false
ceilometer-acentral: true
ceilometer-anotification: true
devstack_local_conf:
post-config:
$NOVA_CONF:
libvirt:
live_migration_uri: qemu+ssh://root@%s/system
$WATCHER_CONF:
watcher_cluster_data_model_collectors.compute:
period: 120
@@ -68,23 +106,13 @@
period: 120
watcher_cluster_data_model_collectors.storage:
period: 120
$CINDER_CONF:
# enable notifications in compute node, by default they are only
# configured in the controller
oslo_messaging_notifications:
driver: messagingv2
test-config:
$TEMPEST_CONFIG:
compute:
min_compute_nodes: 2
min_microversion: 2.56
compute-feature-enabled:
live_migration: true
block_migration_for_live_migration: true
placement:
min_microversion: 1.29
telemetry:
ceilometer_polling_interval: 15
devstack_plugins:
ceilometer: https://opendev.org/openstack/ceilometer
@@ -92,17 +120,19 @@
name: watcher-tempest-functional
parent: devstack-tempest
timeout: 7200
required-projects: &base_required_projects
required-projects:
- openstack/ceilometer
- openstack/devstack-gate
- openstack/python-openstackclient
- openstack/python-watcherclient
- openstack/watcher
- openstack/watcher-tempest-plugin
- openstack/tempest
vars: &base_vars
vars:
devstack_plugins:
watcher: https://opendev.org/openstack/watcher
devstack_services:
tls-proxy: false
watcher-api: true
watcher-decision-engine: true
watcher-applier: true
@@ -111,292 +141,24 @@
s-container: false
s-object: false
s-proxy: false
tempest_plugins:
- watcher-tempest-plugin
devstack_localrc:
TEMPEST_PLUGINS: /opt/stack/watcher-tempest-plugin
tempest_test_regex: watcher_tempest_plugin.tests.api
tox_envlist: all
tox_environment:
# Do we really need to set this? It's cargo culted
PYTHONUNBUFFERED: 'true'
zuul_copy_output:
/etc/hosts: logs
- job:
name: watcher-tempest-functional-ipv6-only
parent: devstack-tempest-ipv6
description: |
Watcher devstack tempest tests job for IPv6-only deployment
required-projects: *base_required_projects
vars: *base_vars
- job:
name: watcher-grenade
parent: grenade
required-projects:
- openstack/watcher
- openstack/python-watcherclient
- openstack/watcher-tempest-plugin
vars: *base_vars
irrelevant-files: &irrelevent_files
- ^(test-|)requirements.txt$
- ^.*\.rst$
- ^api-ref/.*$
- ^doc/.*$
- ^watcher/hacking/.*$
- ^watcher/tests/.*$
- ^releasenotes/.*$
- ^setup.cfg$
- ^tools/.*$
- ^tox.ini$
- job:
name: watcher-sg-core-tempest-base
parent: devstack-tempest
nodeset: openstack-two-node-noble
description: |
This job is for testing watcher and sg-core/prometheus installation
abstract: true
pre-run:
- playbooks/generate_prometheus_config.yml
irrelevant-files: *irrelevent_files
timeout: 7800
required-projects: &base_sg_required_projects
- openstack/aodh
- openstack/ceilometer
- openstack/tempest
- openstack-k8s-operators/sg-core
- openstack/watcher
- openstack/python-watcherclient
- openstack/watcher-tempest-plugin
- openstack/devstack-plugin-prometheus
# This job is used in python-watcherclient repo
name: watcherclient-tempest-functional
parent: watcher-tempest-functional
voting: false
timeout: 4200
vars:
configure_swap_size: 8192
devstack_plugins:
ceilometer: https://opendev.org/openstack/ceilometer
aodh: https://opendev.org/openstack/aodh
sg-core: https://github.com/openstack-k8s-operators/sg-core
watcher: https://opendev.org/openstack/watcher
devstack-plugin-prometheus: https://opendev.org/openstack/devstack-plugin-prometheus
devstack_services:
ceilometer-acompute: true
watcher-api: true
watcher-decision-engine: true
watcher-applier: true
tempest: true
# We do not need Swift in this job so disable it for speed
# Swift services
s-account: false
s-container: false
s-object: false
s-proxy: false
# Prometheus related service
prometheus: true
node_exporter: true
devstack_localrc:
CEILOMETER_BACKENDS: "sg-core"
CEILOMETER_PIPELINE_INTERVAL: 15
CEILOMETER_ALARM_THRESHOLD: 6000000000
PROMETHEUS_CONFIG_FILE: "/home/zuul/prometheus.yml"
devstack_local_conf:
post-config:
$WATCHER_CONF:
watcher_datasources:
datasources: prometheus
prometheus_client:
host: 127.0.0.1
port: 9090
watcher_cluster_data_model_collectors.compute:
period: 120
watcher_cluster_data_model_collectors.baremetal:
period: 120
watcher_cluster_data_model_collectors.storage:
period: 120
compute_model:
enable_extended_attributes: true
nova_client:
api_version: "2.96"
test-config:
$TEMPEST_CONFIG:
compute:
min_compute_nodes: 2
min_microversion: 2.56
compute-feature-enabled:
live_migration: true
block_migration_for_live_migration: true
placement:
min_microversion: 1.29
service_available:
sg_core: True
telemetry_services:
metric_backends: prometheus
telemetry:
disable_ssl_certificate_validation: True
ceilometer_polling_interval: 15
optimize:
datasource: prometheus
extended_attributes_nova_microversion: "2.96"
data_model_collectors_period: 120
tempest_plugins:
- watcher-tempest-plugin
# All tests inside watcher_tempest_plugin.tests.scenario with tag "strategy"
# and test_execute_strategies, test_data_model files
# excluding tests with tag "real_load"
tempest_test_regex: (watcher_tempest_plugin.tests.scenario)(.*\[.*\bstrategy\b.*\].*)|(watcher_tempest_plugin.tests.scenario.(test_execute_strategies|test_data_model))
tempest_exclude_regex: .*\[.*\breal_load\b.*\].*
tempest_concurrency: 1
tox_envlist: all
zuul_copy_output:
/etc/prometheus/prometheus.yml: logs
group-vars:
subnode:
devstack_plugins:
ceilometer: https://opendev.org/openstack/ceilometer
devstack-plugin-prometheus: https://opendev.org/openstack/devstack-plugin-prometheus
devstack_services:
ceilometer-acompute: true
sg-core: false
prometheus: false
node_exporter: true
devstack_localrc:
CEILOMETER_BACKEND: "none"
CEILOMETER_BACKENDS: "none"
devstack_local_conf:
post-config:
$WATCHER_CONF:
watcher_cluster_data_model_collectors.compute:
period: 120
watcher_cluster_data_model_collectors.baremetal:
period: 120
watcher_cluster_data_model_collectors.storage:
period: 120
- job:
name: watcher-prometheus-integration
parent: watcher-sg-core-tempest-base
vars:
devstack_services:
ceilometer-acompute: false
node_exporter: false
group-vars:
subnode:
devstack_services:
ceilometer-acompute: false
node_exporter: false
- job:
name: watcher-aetos-integration
parent: watcher-sg-core-tempest-base
description: |
This job tests Watcher with Aetos reverse-proxy for Prometheus
using Keystone authentication instead of direct Prometheus access.
required-projects:
- openstack/python-observabilityclient
- openstack/aetos
vars: &aetos_vars
devstack_services:
ceilometer-acompute: false
node_exporter: false
devstack_plugins:
ceilometer: https://opendev.org/openstack/ceilometer
sg-core: https://github.com/openstack-k8s-operators/sg-core
watcher: https://opendev.org/openstack/watcher
devstack-plugin-prometheus: https://opendev.org/openstack/devstack-plugin-prometheus
aetos: https://opendev.org/openstack/aetos
devstack_local_conf:
post-config:
$WATCHER_CONF:
watcher_datasources:
datasources: aetos
aetos_client:
interface: public
region_name: RegionOne
fqdn_label: fqdn
instance_uuid_label: resource
test-config:
$TEMPEST_CONFIG:
optimize:
datasource: prometheus
group-vars:
subnode:
devstack_services:
ceilometer-acompute: false
node_exporter: false
- job:
name: watcher-prometheus-integration-realdata
parent: watcher-sg-core-tempest-base
vars: &realdata_vars
devstack_services:
ceilometer-acompute: true
node_exporter: true
devstack_localrc:
NODE_EXPORTER_COLLECTOR_EXCLUDE: ""
devstack_local_conf:
test-config:
$TEMPEST_CONFIG:
optimize:
datasource: ""
real_workload_period: 300
# All tests inside watcher_tempest_plugin.tests.scenario with tag "real_load"
tempest_test_regex: (^watcher_tempest_plugin.tests.scenario)(.*\[.*\breal_load\b.*\].*)
tempest_exclude_regex: ""
group-vars: &realdata_group_vars
subnode:
devstack_services:
ceilometer-acompute: true
node_exporter: true
devstack_localrc:
NODE_EXPORTER_COLLECTOR_EXCLUDE: ""
- job:
name: watcher-prometheus-integration-threading
parent: watcher-prometheus-integration
vars:
devstack_localrc:
'SYSTEMD_ENV_VARS["watcher-decision-engine"]': OS_WATCHER_DISABLE_EVENTLET_PATCHING=true
- job:
name: openstack-tox-py312-threading
parent: openstack-tox-py312
description: |
Run tox with the py3-threading environment.
vars:
tox_envlist: py3-threading
- job:
name: watcher-aetos-integration-realdata
parent: watcher-aetos-integration
vars: *realdata_vars
group-vars: *realdata_group_vars
- project:
queue: watcher
templates:
- check-requirements
- openstack-cover-jobs
- openstack-python3-jobs
- publish-openstack-docs-pti
- release-notes-jobs-python3
check:
jobs:
- openstack-tox-py312-threading
- watcher-tempest-functional
- watcher-grenade
- watcher-tempest-strategies
- watcher-tempest-actuator
- python-watcherclient-functional:
files:
- ^watcher/api/*
- watcher-tempest-functional-ipv6-only
- watcher-prometheus-integration
- watcher-prometheus-integration-threading
- watcher-aetos-integration
gate:
jobs:
- watcher-tempest-functional
- watcher-tempest-functional-ipv6-only
experimental:
jobs:
- watcher-prometheus-integration-realdata
- watcher-aetos-integration-realdata
periodic-weekly:
jobs:
- watcher-prometheus-integration-realdata
- watcher-aetos-integration-realdata
TEMPEST_PLUGINS: /opt/stack/python-watcherclient
tempest_test_regex: watcherclient.tests.functional

View File

@@ -1,6 +1,6 @@
=======
Watcher
=======
========================
Team and repository tags
========================
.. image:: https://governance.openstack.org/tc/badges/watcher.svg
:target: https://governance.openstack.org/tc/reference/tags/index.html
@@ -13,6 +13,10 @@ Watcher
https://creativecommons.org/licenses/by/3.0/
=======
Watcher
=======
OpenStack Watcher provides a flexible and scalable resource optimization
service for multi-tenant OpenStack-based clouds.
Watcher provides a robust framework to realize a wide range of cloud
@@ -22,8 +26,7 @@ migration, increased energy efficiency and more!
* Free software: Apache license
* Wiki: https://wiki.openstack.org/wiki/Watcher
* Source: https://opendev.org/openstack/watcher
* Source: https://github.com/openstack/watcher
* Bugs: https://bugs.launchpad.net/watcher
* Documentation: https://docs.openstack.org/watcher/latest/
* Release notes: https://docs.openstack.org/releasenotes/watcher/
* Design specifications: https://specs.openstack.org/openstack/watcher-specs/

View File

@@ -22,6 +22,9 @@
# All configuration values have a default; values that are commented out
# serve to show the default.
from watcher import version as watcher_version
extensions = [
'openstackdocstheme',
'os_api_ref',
@@ -43,13 +46,21 @@ project = u'Infrastructure Optimization API Reference'
copyright = u'2010-present, OpenStack Foundation'
# openstackdocstheme options
openstackdocs_repo_name = 'openstack/watcher'
openstackdocs_auto_name = False
openstackdocs_bug_project = 'watcher'
openstackdocs_bug_tag = ''
repository_name = 'openstack/watcher'
bug_project = 'watcher'
bug_tag = ''
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The full version, including alpha/beta/rc tags.
release = watcher_version.version_info.release_string()
# The short X.Y version.
version = watcher_version.version_string
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'native'
pygments_style = 'sphinx'
# -- Options for HTML output --------------------------------------------------
@@ -64,6 +75,10 @@ html_theme_options = {
"sidebar_mode": "toc",
}
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
html_last_updated_fmt = '%Y-%m-%d %H:%M'
# -- Options for LaTeX output -------------------------------------------------
# Grouping the document tree into LaTeX files. List of tuples

View File

@@ -6,7 +6,6 @@ Watcher API
.. rest_expand_all::
.. include:: watcher-api-versions.inc
.. include:: watcher-api-v1-audittemplates.inc
.. include:: watcher-api-v1-audits.inc
.. include:: watcher-api-v1-actionplans.inc
@@ -14,6 +13,4 @@ Watcher API
.. include:: watcher-api-v1-goals.inc
.. include:: watcher-api-v1-strategies.inc
.. include:: watcher-api-v1-services.inc
.. include:: watcher-api-v1-scoring_engines.inc
.. include:: watcher-api-v1-datamodel.inc
.. include:: watcher-api-v1-webhooks.inc
.. include:: watcher-api-v1-scoring_engines.inc

View File

@@ -1,42 +1,3 @@
# variables in header
header_version:
description: |
Specific API microversion used to generate this response.
in: header
required: true
type: string
openstack-api-max-version:
description: |
Maximum API microversion supported by this endpoint, eg. "1.1"
in: header
required: true
type: string
openstack-api-min-version:
description: |
Minimum API microversion supported by this endpoint, eg. "1.0"
in: header
required: true
type: string
openstack-api-version:
description: >
A request SHOULD include this header to indicate to the Watcher API service what
version the client supports. The server will transform the response object into
compliance with the requested version, if it is supported, or return a
406 Not Acceptable error.
If this header is not supplied, the server will response with server minimum
supported version.
in: header
required: true
type: string
openstack-request-id:
description: >
An unique ID for tracking the request. The request ID associated with the request
appears in the log lines for that request. By default, the middleware configuration
ensures that the request ID appears in the log files.
in: header
required: false
type: string
# Path
action_ident:
description: |
@@ -129,14 +90,6 @@ r_strategy:
in: query
required: false
type: string
r_type:
description: |
Type of data model user want to list. Default type is compute.
Supported values: compute.
Future support values: storage, baremetal.
in: query
required: false
type: string
sort_dir:
description: |
Sorts the response by the requested sort direction.
@@ -189,16 +142,6 @@ action_state:
in: body
required: true
type: string
action_status_message:
description: |
Message with additional information about the Action state.
This field can be set when transitioning an action to SKIPPED state,
or updated for actions that are already in SKIPPED state to provide
more detailed explanations, fix typos, or expand on initial reasons.
in: body
required: false
type: string
min_version: 1.5
action_type:
description: |
Action type based on specific API action. Actions in Watcher are
@@ -227,12 +170,6 @@ actionplan_global_efficacy:
in: body
required: false
type: array
actionplan_hostname:
description: |
Hostname the actionplan is running on
in: body
required: false
type: string
actionplan_state:
description: |
State of this action plan. To get more information about states and
@@ -240,55 +177,20 @@ actionplan_state:
in: body
required: false
type: string
actionplan_status_message:
description: |
Message with additional information about the Action Plan state.
in: body
required: false
type: string
min_version: 1.5
# Audit
audit_autotrigger:
description: |
Auto execute action plan once audit is succeeded.
Autoexecute action plan once audit is succeeded.
in: body
required: false
type: boolean
audit_endtime_req:
description: |
The local time after which audit can't be executed.
It will be converted to UTC time by Watcher.
in: body
required: false
type: string
min_version: 1.1
audit_endtime_resp:
description: |
The UTC time after which audit can't be executed.
in: body
required: false
type: string
min_version: 1.1
audit_force:
description: |
Launch audit even if action plan is ongoing.
in: body
required: false
type: boolean
min_version: 1.2
audit_goal:
description: |
The UUID or name of the Goal.
in: body
required: false
type: string
audit_hostname:
description: |
Hostname the audit is running on
in: body
required: false
type: string
audit_interval:
description: |
Time interval between audit's execution.
@@ -315,21 +217,6 @@ audit_parameters:
in: body
required: false
type: JSON
audit_starttime_req:
description: |
The local time after which audit can be executed in accordance
with interval. It will be converted to UTC time by Watcher.
in: body
required: false
type: string
min_version: 1.1
audit_starttime_resp:
description: |
The UTC time after which audit can be executed in accordance with interval.
in: body
required: false
type: string
min_version: 1.1
audit_state:
description: |
State of this audit. To get more information about states and
@@ -337,13 +224,6 @@ audit_state:
in: body
required: true
type: string
audit_status_message:
description: |
Message with additional information about the Audit state.
in: body
required: false
type: string
min_version: 1.5
audit_strategy:
description: |
The UUID or name of the Strategy.
@@ -352,7 +232,7 @@ audit_strategy:
type: string
audit_type:
description: |
Type of this audit. Can only be either ONESHOT or CONTINUOUS.
Type of this audit. Can be either ONESHOT or CONTINUOUS.
in: body
required: true
type: string
@@ -388,12 +268,6 @@ audittemplate_strategy:
in: body
required: false
type: string
audittemplate_uuid:
description: |
The UUID of the Audit template.
in: body
required: true
type: string
created_at:
description: |
@@ -443,91 +317,6 @@ links:
required: true
type: array
# Data Model Node
node_disabled_reason:
description: |
The Disabled Reason of the node.
in: body
required: true
type: string
node_disk:
description: |
The Disk of the node(in GiB).
in: body
required: true
type: integer
node_disk_gb_reserved:
description: |
The Disk Reserved of the node (in GiB).
in: body
required: true
type: integer
node_disk_ratio:
description: |
The Disk Ratio of the node.
in: body
required: true
type: float
node_hostname:
description: |
The Host Name of the node.
in: body
required: true
type: string
node_memory:
description: |
The Memory of the node(in MiB).
in: body
required: true
type: integer
node_memory_mb_reserved:
description: |
The Memory Reserved of the node(in MiB).
in: body
required: true
type: integer
node_memory_ratio:
description: |
The Memory Ratio of the node.
in: body
required: true
type: float
node_state:
description: |
The State of the node. The value is up or down.
in: body
required: true
type: string
node_status:
description: |
The Status of the node.
in: body
required: true
type: string
node_uuid:
description: |
The Unique UUID of the node.
in: body
required: true
type: string
node_vcpu_ratio:
description: |
The Vcpu ratio of the node.
in: body
required: true
type: float
node_vcpu_reserved:
description: |
The Vcpu Reserved of the node.
in: body
required: true
type: integer
node_vcpus:
description: |
The Vcpu of the node.
in: body
required: true
type: integer
# Scoring Engine
scoring_engine_description:
description: |
@@ -547,110 +336,34 @@ scoring_engine_name:
in: body
required: true
type: string
# Data Model Server
server_disk:
description: |
The Disk of the server.
in: body
required: true
type: integer
server_flavor_extra_specs:
description: |
The flavor extra specs of the server.
in: body
required: true
type: JSON
min_version: 1.6
server_locked:
description: |
Whether the server is locked.
in: body
required: true
type: boolean
server_memory:
description: |
The Memory of server.
in: body
required: true
type: integer
server_metadata:
description: |
The metadata associated with the server.
in: body
required: true
type: JSON
server_name:
description: |
The Name of the server.
in: body
required: true
type: string
server_pinned_az:
description: |
The pinned availability zone of the server.
in: body
required: true
type: string
min_version: 1.6
server_project_id:
description: |
The project ID of the server.
in: body
required: true
type: string
server_state:
description: |
The State of the server.
in: body
required: true
type: string
server_uuid:
description: |
The Unique UUID of the server.
in: body
required: true
type: string
server_vcpus:
description: |
The Vcpu of the server.
in: body
required: true
type: integer
server_watcher_exclude:
description: |
Whether the server is excluded from the scope.
in: body
required: true
type: boolean
# Service
service_host:
description: |
The Name of host where service is placed on.
Name of host where service is placed on.
in: body
required: true
type: string
service_id:
description: |
The ID of service.
ID of service.
in: body
required: true
type: integer
service_last_seen_up:
description: |
The Time when Watcher service sent latest heartbeat.
Time when Watcher service sent latest heartbeat.
in: body
required: true
type: string
service_name:
description: |
The Name of service like ``watcher-applier``.
Name of service like ``watcher-applier``.
in: body
required: true
type: string
service_status:
description: |
The State of service. It can be either in ACTIVE or FAILED state.
State of service. It can be either in ACTIVE or FAILED state.
in: body
required: true
type: string
@@ -718,29 +431,3 @@ uuid:
in: body
required: true
type: string
# Version
version:
description: |
Versioning of this API response, eg. "1.1".
in: body
required: true
type: string
version_description:
description: |
Descriptive text about the Watcher service.
in: body
required: true
type: string
version_id:
description: |
Major API version, eg, "v1"
in: body
required: true
type: string
versions:
description: |
Array of information about currently supported versions.
in: body
required: true
type: array

View File

@@ -1,12 +0,0 @@
[
{
"op": "replace",
"value": "SKIPPED",
"path": "/state"
},
{
"op": "replace",
"value": "Skipping due to maintenance window",
"path": "/status_message"
}
]

View File

@@ -1,7 +0,0 @@
[
{
"op": "replace",
"value": "SKIPPED",
"path": "/state"
}
]

View File

@@ -1,29 +0,0 @@
{
"state": "SKIPPED",
"description": "Migrate instance to another compute node",
"parents": [
"b4529294-1de6-4302-b57a-9b5d5dc363c6"
],
"links": [
{
"rel": "self",
"href": "http://controller:9322/v1/actions/54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a"
},
{
"rel": "bookmark",
"href": "http://controller:9322/actions/54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a"
}
],
"action_plan_uuid": "4cbc4ede-0d25-481b-b86e-998dbbd4f8bf",
"uuid": "54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a",
"deleted_at": null,
"updated_at": "2018-04-10T12:15:44.026973+00:00",
"input_parameters": {
"migration_type": "live",
"destination_node": "compute-2",
"resource_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef"
},
"action_type": "migrate",
"created_at": "2018-04-10T11:59:12.725147+00:00",
"status_message": "Action skipped by user. Reason:Skipping due to maintenance window"
}

View File

@@ -1,7 +0,0 @@
[
{
"op": "replace",
"value": "Action skipped due to scheduled maintenance window",
"path": "/status_message"
}
]

View File

@@ -1,29 +0,0 @@
{
"state": "SKIPPED",
"description": "Migrate instance to another compute node",
"parents": [
"b4529294-1de6-4302-b57a-9b5d5dc363c6"
],
"links": [
{
"rel": "self",
"href": "http://controller:9322/v1/actions/54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a"
},
{
"rel": "bookmark",
"href": "http://controller:9322/actions/54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a"
}
],
"action_plan_uuid": "4cbc4ede-0d25-481b-b86e-998dbbd4f8bf",
"uuid": "54acc7a0-91b0-46ea-a5f7-4ae2b9df0b0a",
"deleted_at": null,
"updated_at": "2018-04-10T12:20:15.123456+00:00",
"input_parameters": {
"migration_type": "live",
"destination_node": "compute-2",
"resource_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef"
},
"action_type": "migrate",
"created_at": "2018-04-10T11:59:12.725147+00:00",
"status_message": "Action skipped by user. Reason: Action skipped due to scheduled maintenance window"
}

View File

@@ -20,9 +20,7 @@
"deleted_at": null,
"uuid": "4cbc4ede-0d25-481b-b86e-998dbbd4f8bf",
"audit_uuid": "7d100b05-0a86-491f-98a7-f93da19b272a",
"created_at": "2018-04-10T11:59:52.640067+00:00",
"hostname": "controller",
"status_message": null
"created_at": "2018-04-10T11:59:52.640067+00:00"
}
]
}

View File

@@ -16,7 +16,5 @@
"updated_at": "2018-04-10T11:59:52.640067+00:00",
"strategy_name": "dummy_with_resize",
"uuid": "4cbc4ede-0d25-481b-b86e-998dbbd4f8bf",
"audit_uuid": "7d100b05-0a86-491f-98a7-f93da19b272a",
"hostname": "controller",
"status_message": null
}
"audit_uuid": "7d100b05-0a86-491f-98a7-f93da19b272a"
}

View File

@@ -18,6 +18,5 @@
"uuid": "4cbc4ede-0d25-481b-b86e-998dbbd4f8bf",
"audit_uuid": "7d100b05-0a86-491f-98a7-f93da19b272a",
"created_at": "2018-04-10T11:59:12.592729+00:00",
"deleted_at": null,
"hostname": null
"deleted_at": null
}

View File

@@ -24,8 +24,7 @@
"duration": 3.2
},
"action_type": "sleep",
"created_at": "2018-03-26T11:56:08.235226+00:00",
"status_message": null
"created_at": "2018-03-26T11:56:08.235226+00:00"
}
]
}
}

View File

@@ -22,6 +22,5 @@
"message": "Welcome"
},
"action_type": "nop",
"created_at": "2018-04-10T11:59:12.725147+00:00",
"status_message": null
}
"created_at": "2018-04-10T11:59:12.725147+00:00"
}

View File

@@ -1,30 +0,0 @@
{
"default_version": {
"id": "v1",
"links": [
{
"href": "http://controller:9322/v1/",
"rel": "self"
}
],
"min_version": "1.0",
"status": "CURRENT",
"max_version": "1.1"
},
"description": "Watcher is an OpenStack project which aims to improve physical resources usage through better VM placement.",
"name": "OpenStack Watcher API",
"versions": [
{
"id": "v1",
"links": [
{
"href": "http://controller:9322/v1/",
"rel": "self"
}
],
"min_version": "1.0",
"status": "CURRENT",
"max_version": "1.1"
}
]
}

View File

@@ -1,80 +0,0 @@
{
"scoring_engines": [
{
"href": "http://controller:9322/v1/scoring_engines/",
"rel": "self"
},
{
"href": "http://controller:9322/scoring_engines/",
"rel": "bookmark"
}
],
"media_types": [
{
"base": "application/json",
"type": "application/vnd.openstack.watcher.v1+json"
}
],
"links": [
{
"href": "http://controller:9322/v1/",
"rel": "self"
},
{
"href": "http://docs.openstack.org/developer/watcher/dev/api-spec-v1.html",
"type": "text/html",
"rel": "describedby"
}
],
"actions": [
{
"href": "http://controller:9322/v1/actions/",
"rel": "self"
},
{
"href": "http://controller:9322/actions/",
"rel": "bookmark"
}
],
"audit_templates": [
{
"href": "http://controller:9322/v1/audit_templates/",
"rel": "self"
},
{
"href": "http://controller:9322/audit_templates/",
"rel": "bookmark"
}
],
"action_plans": [
{
"href": "http://controller:9322/v1/action_plans/",
"rel": "self"
},
{
"href": "http://controller:9322/action_plans/",
"rel": "bookmark"
}
],
"services": [
{
"href": "http://controller:9322/v1/services/",
"rel": "self"
},
{
"href": "http://controller:9322/services/",
"rel": "bookmark"
}
],
"audits": [
{
"href": "http://controller:9322/v1/audits/",
"rel": "self"
},
{
"href": "http://controller:9322/audits/",
"rel": "bookmark"
}
],
"id": "v1"
}

View File

@@ -28,7 +28,6 @@
}
},
"auto_trigger": false,
"force": false,
"uuid": "65a5da84-5819-4aea-8278-a28d2b489028",
"goal_name": "workload_balancing",
"scope": [],
@@ -48,8 +47,5 @@
],
"strategy_name": "workload_stabilization",
"next_run_time": "2018-04-06T11:56:00",
"updated_at": "2018-04-06T11:54:01.266447+00:00",
"hostname": "controller",
"start_time": null,
"end_time": null
}
"updated_at": "2018-04-06T11:54:01.266447+00:00"
}

View File

@@ -1,6 +1,5 @@
{
"auto_trigger": false,
"force": false,
"audit_template_uuid": "76fddfee-a9c4-40b0-8da0-c19ad6904f09",
"name": "test_audit",
"parameters": {
@@ -9,7 +8,5 @@
]
},
"audit_type": "CONTINUOUS",
"interval": "*/2 * * * *",
"start_time":"2018-04-02 20:30:00",
"end_time": "2018-04-04 20:30:00"
}
"interval": "*/2 * * * *"
}

View File

@@ -1,6 +1,5 @@
{
"audit_type": "ONESHOT",
"auto_trigger": false,
"force": true,
"audit_template_uuid": "5e70a156-ced7-4012-b1c6-88fcb02ee0c1"
}
}

View File

@@ -28,7 +28,6 @@
}
},
"auto_trigger": false,
"force": false,
"uuid": "65a5da84-5819-4aea-8278-a28d2b489028",
"goal_name": "workload_balancing",
"scope": [],
@@ -48,9 +47,5 @@
],
"strategy_name": "workload_stabilization",
"next_run_time": null,
"updated_at": null,
"hostname": null,
"start_time": null,
"end_time": null,
"status_message": null
}
"updated_at": null
}

View File

@@ -30,7 +30,6 @@
}
},
"auto_trigger": false,
"force": false,
"uuid": "65a5da84-5819-4aea-8278-a28d2b489028",
"goal_name": "workload_balancing",
"scope": [],
@@ -50,11 +49,7 @@
],
"strategy_name": "workload_stabilization",
"next_run_time": "2018-04-06T09:46:00",
"updated_at": "2018-04-06T09:44:01.604146+00:00",
"hostname": "controller",
"start_time": null,
"end_time": null,
"status_message": null
"updated_at": "2018-04-06T09:44:01.604146+00:00"
}
]
}
}

View File

@@ -28,7 +28,6 @@
}
},
"auto_trigger": false,
"force": false,
"uuid": "65a5da84-5819-4aea-8278-a28d2b489028",
"goal_name": "workload_balancing",
"scope": [],
@@ -48,9 +47,5 @@
],
"strategy_name": "workload_stabilization",
"next_run_time": "2018-04-06T11:56:00",
"updated_at": "2018-04-06T11:54:01.266447+00:00",
"hostname": "controller",
"start_time": null,
"end_time": null,
"status_message": null
}
"updated_at": "2018-04-06T11:54:01.266447+00:00"
}

View File

@@ -28,7 +28,6 @@
}
},
"auto_trigger": false,
"force": false,
"uuid": "65a5da84-5819-4aea-8278-a28d2b489028",
"goal_name": "workload_balancing",
"scope": [],
@@ -48,8 +47,5 @@
],
"strategy_name": "workload_stabilization",
"next_run_time": "2018-04-06T11:56:00",
"updated_at": "2018-04-06T11:54:01.266447+00:00",
"hostname": "controller",
"start_time": null,
"end_time": null
}
"updated_at": "2018-04-06T11:54:01.266447+00:00"
}

View File

@@ -1,62 +0,0 @@
{
"context": [
{
"server_watcher_exclude": false,
"server_name": "chenke-test1",
"server_state": "active",
"server_memory": "512",
"server_disk": "1",
"server_vcpus": "1",
"server_metadata": {},
"server_project_id": "baea342fc74b4a1785b4a40c69a8d958",
"server_locked":false,
"server_uuid": "1bf91464-9b41-428d-a11e-af691e5563bb",
"server_pinned_az": "nova",
"server_flavor_extra_specs": {
"hw_rng:allowed": true
},
"node_hostname": "localhost.localdomain",
"node_status": "enabled",
"node_disabled_reason": null,
"node_state": "up",
"node_memory": "16383",
"node_memory_mb_reserved": "512",
"node_disk": "37",
"node_disk_gb_reserved": "0",
"node_vcpus": "4",
"node_vcpu_reserved": "0",
"node_memory_ratio": "1.5",
"node_vcpu_ratio": "16.0",
"node_disk_ratio": "1.0",
"node_uuid": "253e5dd0-9384-41ab-af13-4f2c2ce26112"
},
{
"server_watcher_exclude": false,
"server_name": "chenke-test2",
"server_state": "active",
"server_memory": "512",
"server_disk": "1",
"server_vcpus": "1",
"server_metadata": {},
"server_project_id": "baea342fc74b4a1785b4a40c69a8d958",
"server_locked": false,
"server_uuid": "e2cb5f6f-fa1d-4ba2-be1e-0bf02fa86ba4",
"server_pinned_az": "nova",
"server_flavor_extra_specs": {},
"node_hostname": "localhost.localdomain",
"node_status": "enabled",
"node_disabled_reason": null,
"node_state": "up",
"node_memory": "16383",
"node_memory_mb_reserved": "512",
"node_disk": "37",
"node_disk_gb_reserved": "0",
"node_vcpus": "4",
"node_vcpu_reserved": "0",
"node_memory_ratio": "1.5",
"node_vcpu_ratio": "16.0",
"node_disk_ratio": "1.0",
"node_uuid": "253e5dd0-9384-41ab-af13-4f2c2ce26112"
}
]
}

View File

@@ -50,7 +50,6 @@ version 1:
- efficacy_indicators: actionplan_efficacy_indicators
- global_efficacy: actionplan_global_efficacy
- links: links
- hostname: actionplan_hostname
**Example JSON representation of an Action Plan:**
@@ -138,8 +137,6 @@ Response
- efficacy_indicators: actionplan_efficacy_indicators
- global_efficacy: actionplan_global_efficacy
- links: links
- hostname: actionplan_hostname
- status_message: actionplan_status_message
**Example JSON representation of an Action Plan:**
@@ -177,8 +174,6 @@ Response
- efficacy_indicators: actionplan_efficacy_indicators
- global_efficacy: actionplan_global_efficacy
- links: links
- hostname: actionplan_hostname
- status_message: actionplan_status_message
**Example JSON representation of an Audit:**
@@ -234,8 +229,6 @@ version 1:
- efficacy_indicators: actionplan_efficacy_indicators
- global_efficacy: actionplan_global_efficacy
- links: links
- hostname: actionplan_hostname
- status_message: actionplan_status_message
**Example JSON representation of an Action Plan:**

View File

@@ -23,9 +23,6 @@ following:
- **PENDING** : the ``Action`` has not been executed yet by the
``Watcher Applier``.
- **SKIPPED** : the ``Action`` will not be executed because a predefined
skipping condition is found by ``Watcher Applier`` or is explicitly
skipped by the ``Administrator``.
- **ONGOING** : the ``Action`` is currently being processed by the
``Watcher Applier``.
- **SUCCEEDED** : the ``Action`` has been executed successfully
@@ -114,7 +111,6 @@ Response
- description: action_description
- input_parameters: action_input_parameters
- links: links
- status_message: action_status_message
**Example JSON representation of an Action:**
@@ -152,111 +148,8 @@ Response
- description: action_description
- input_parameters: action_input_parameters
- links: links
- status_message: action_status_message
**Example JSON representation of an Action:**
.. literalinclude:: samples/actions-show-response.json
:language: javascript
Skip Action
===========
.. rest_method:: PATCH /v1/actions/{action_ident}
Skips an Action resource by changing its state to SKIPPED.
.. note::
Only Actions in PENDING state can be skipped. The Action must belong to
an Action Plan in RECOMMENDED or PENDING state. This operation requires
API microversion 1.5 or later.
Normal response codes: 200
Error codes: 400,404,403,409
Request
-------
.. rest_parameters:: parameters.yaml
- action_ident: action_ident
**Example Action skip request:**
.. literalinclude:: samples/action-skip-request.json
:language: javascript
**Example Action skip request with custom status message:**
.. literalinclude:: samples/action-skip-request-with-message.json
:language: javascript
Response
--------
.. rest_parameters:: parameters.yaml
- uuid: uuid
- action_type: action_type
- state: action_state
- action_plan_uuid: action_action_plan_uuid
- parents: action_parents
- description: action_description
- input_parameters: action_input_parameters
- links: links
- status_message: action_status_message
**Example JSON representation of a skipped Action:**
.. literalinclude:: samples/action-skip-response.json
:language: javascript
Update Action Status Message
============================
.. rest_method:: PATCH /v1/actions/{action_ident}
Updates the status_message of an Action that is already in SKIPPED state.
.. note::
The status_message field can only be updated for Actions that are currently
in SKIPPED state. This allows administrators to fix typos, provide more
detailed explanations, or expand on reasons that were initially omitted.
This operation requires API microversion 1.5 or later.
Normal response codes: 200
Error codes: 400,404,403,409
Request
-------
.. rest_parameters:: parameters.yaml
- action_ident: action_ident
**Example status_message update request for a SKIPPED action:**
.. literalinclude:: samples/action-update-status-message-request.json
:language: javascript
Response
--------
.. rest_parameters:: parameters.yaml
- uuid: uuid
- action_type: action_type
- state: action_state
- action_plan_uuid: action_action_plan_uuid
- parents: action_parents
- description: action_description
- input_parameters: action_input_parameters
- links: links
- status_message: action_status_message
**Example JSON representation of an Action with updated status_message:**
.. literalinclude:: samples/action-update-status-message-response.json
:language: javascript

View File

@@ -28,6 +28,10 @@ itself. In the first case, there also should be supplied
``audit_template_uuid``. If ``Audit`` is created without ``Audit Template``,
``goal`` should be provided.
.. warning::
**Only ``audit_template_uuid`` can be used to create audit so far.**
It should be fixed during the ``Rocky`` cycle.
Normal response codes: 201
Error codes: 400,404
@@ -37,17 +41,15 @@ Request
.. rest_parameters:: parameters.yaml
- audit_template_uuid: audittemplate_uuid
- audit_template_uuid: audittemplate_name
- audit_type: audit_type
- name: audit_name
- goal: audit_goal
- strategy: audit_strategy
- parameters: audit_parameters
- interval: audit_interval
- scope: audittemplate_scope
- auto_trigger: audit_autotrigger
- start_time: audit_starttime_req
- end_time: audit_endtime_req
- force: audit_force
**Example ONESHOT Audit creation request:**
@@ -81,11 +83,6 @@ version 1:
- state: audit_state
- scope: audittemplate_scope
- links: links
- hostname: audit_hostname
- start_time: audit_starttime_resp
- end_time: audit_endtime_resp
- force: audit_force
- status_message: audit_status_message
**Example JSON representation of an Audit:**
@@ -181,11 +178,6 @@ Response
- state: audit_state
- scope: audittemplate_scope
- links: links
- hostname: audit_hostname
- start_time: audit_starttime_resp
- end_time: audit_endtime_resp
- force: audit_force
- status_message: audit_status_message
**Example JSON representation of an Audit:**
@@ -229,11 +221,6 @@ Response
- state: audit_state
- scope: audittemplate_scope
- links: links
- hostname: audit_hostname
- start_time: audit_starttime_resp
- end_time: audit_endtime_resp
- force: audit_force
- status_message: audit_status_message
**Example JSON representation of an Audit:**
@@ -285,11 +272,6 @@ version 1:
- state: audit_state
- scope: audittemplate_scope
- links: links
- hostname: audit_hostname
- start_time: audit_starttime_resp
- end_time: audit_endtime_resp
- force: audit_force
- status_message: audit_status_message
**Example JSON representation of an Audit:**
@@ -341,11 +323,6 @@ Response
- state: audit_state
- scope: audittemplate_scope
- links: links
- hostname: audit_hostname
- start_time: audit_starttime_resp
- end_time: audit_endtime_resp
- force: audit_force
- status_message: audit_status_message
**Example JSON representation of an Audit:**
@@ -369,4 +346,4 @@ Request
.. rest_parameters:: parameters.yaml
- audit_ident: audit_ident
- audit_ident: audit_ident

View File

@@ -1,68 +0,0 @@
.. -*- rst -*-
==========
Data Model
==========
.. versionadded:: 1.3
``Data Model`` is very important for Watcher to generate resource
optimization solutions. Users can easily view the data model by the
API.
List Data Model
===============
.. rest_method:: GET /v1/data_model
Returns the information about Data Model.
Normal response codes: 200
Error codes: 400,401,406
Request
-------
.. rest_parameters:: parameters.yaml
- audit: r_audit
- type: r_type
Response
--------
.. rest_parameters:: parameters.yaml
- server_watcher_exclude: server_watcher_exclude
- server_name: server_name
- server_state: server_state
- server_memory: server_memory
- server_disk: server_disk
- server_vcpus: server_vcpus
- server_metadata: server_metadata
- server_project_id: server_project_id
- server_locked: server_locked
- server_uuid: server_uuid
- server_pinned_az: server_pinned_az
- server_flavor_extra_specs: server_flavor_extra_specs
- node_hostname: node_hostname
- node_status: node_status
- node_disabled_reason: node_disabled_reason
- node_state: node_state
- node_memory: node_memory
- node_memory_mb_reserved: node_memory_mb_reserved
- node_disk: node_disk
- node_disk_gb_reserved: node_disk_gb_reserved
- node_vcpus: node_vcpus
- node_vcpu_reserved: node_vcpu_reserved
- node_memory_ratio: node_memory_ratio
- node_vcpu_ratio: node_vcpu_ratio
- node_disk_ratio: node_disk_ratio
- node_uuid: node_uuid
**Example JSON representation of a Data Model:**
.. literalinclude:: samples/datamodel-list-response.json
:language: javascript

View File

@@ -12,7 +12,7 @@ Here are some examples of ``Goals``:
- minimize the energy consumption
- minimize the number of compute nodes (consolidation)
- balance the workload among compute nodes
- minimize the license cost (some software have a licensing model which is
- minimize the license cost (some softwares have a licensing model which is
based on the number of sockets or cores where the software is deployed)
- find the most appropriate moment for a planned maintenance on a
given group of host (which may be an entire availability zone):
@@ -123,4 +123,4 @@ Response
**Example JSON representation of a Goal:**
.. literalinclude:: samples/goal-show-response.json
:language: javascript
:language: javascript

View File

@@ -1,26 +0,0 @@
.. -*- rst -*-
========
Webhooks
========
.. versionadded:: 1.4
Triggers an event based Audit.
Trigger EVENT Audit
===================
.. rest_method:: POST /v1/webhooks/{audit_ident}
Normal response codes: 202
Error codes: 400,404
Request
-------
.. rest_parameters:: parameters.yaml
- audit_ident: audit_ident

View File

@@ -1,81 +0,0 @@
.. -*- rst -*-
============
API versions
============
In order to bring new features to users over time, the Watcher API
supports versioning. There are two kinds of versions in Watcher.
- ''major versions'', which have dedicated URLs.
- ''microversions'', which can be requested using the
``OpenStack-API-Version`` header.
.. note:: The maximum microversion depends on release.
Please reference:
`API Microversion History
<https://docs.openstack.org/watcher/latest/contributor/api_microversion_history.html>`__
for API microversion history details.
The Version API resource works differently from other API resources as they *do not*
require authentication.
If Watcher receives a request with unsupported version, it responds with a 406 Not Acceptable,
along with the -Min- and -Max- headers that it can support.
List API versions
=================
.. rest_method:: GET /
This fetches all the information about all known major API versions in the
deployment. Links to more specific information will be provided for each major
API version, as well as information about supported min and max microversions.
Normal response codes: 200
Request
-------
Response Example
----------------
.. rest_parameters:: parameters.yaml
- description: version_description
- versions: versions
- version: version
- id: version_id
- links: links
- min_version: openstack-api-min-version
- max_version: openstack-api-max-version
.. literalinclude:: samples/api-root-response.json
:language: javascript
Show v1 API
===========
.. rest_method:: GET /v1/
Show all the resources within the Watcher v1 API.
Normal response codes: 200
Request
-------
Response Example
----------------
.. rest_parameters:: parameters.yaml
- id: version_id
- links: links
- OpenStack-API-Version: header_version
- OpenStack-API-Minimum-Version: openstack-api-min-version
- OpenStack-API-Maximum-Version: openstack-api-max-version
.. literalinclude:: samples/api-v1-root-response.json
:language: javascript

2
babel.cfg Normal file
View File

@@ -0,0 +1,2 @@
[python: **.py]

View File

@@ -1,23 +0,0 @@
# This is a cross-platform list tracking distribution packages needed for install and tests;
# see https://docs.openstack.org/infra/bindep/ for additional information.
mysql [platform:rpm !platform:redhat test]
mysql-client [platform:dpkg !platform:debian test]
mysql-devel [platform:rpm !platform:redhat test]
mysql-server [!platform:redhat !platform:debian test]
mariadb-devel [platform:rpm platform:redhat test]
mariadb-server [platform:rpm platform:redhat platform:debian test]
python3-all [platform:dpkg test]
python3-all-dev [platform:dpkg test]
python3 [platform:rpm test]
python3-devel [platform:rpm test]
sqlite-devel [platform:rpm test]
# gettext and graphviz are needed by doc builds only.
gettext [doc]
graphviz [doc]
# fonts-freefont-otf is needed for pdf docs builds with the 'xelatex' engine
fonts-freefont-otf [pdf-docs]
texlive [pdf-docs]
texlive-latex-recommended [pdf-docs]
texlive-xetex [pdf-docs]
latexmk [pdf-docs]

View File

@@ -0,0 +1,42 @@
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
# This is an example Apache2 configuration file for using the
# Watcher API through mod_wsgi. This version assumes you are
# running devstack to configure the software.
Listen %WATCHER_SERVICE_PORT%
<VirtualHost *:%WATCHER_SERVICE_PORT%>
WSGIDaemonProcess watcher-api user=%USER% processes=%APIWORKERS% threads=1 display-name=%{GROUP}
WSGIScriptAlias / %WATCHER_WSGI_DIR%/app.wsgi
WSGIApplicationGroup %{GLOBAL}
WSGIProcessGroup watcher-api
WSGIPassAuthorization On
ErrorLogFormat "%M"
ErrorLog /var/log/%APACHE_NAME%/watcher-api.log
CustomLog /var/log/%APACHE_NAME%/watcher-api-access.log combined
<Directory %WATCHER_WSGI_DIR%>
WSGIProcessGroup watcher-api
WSGIApplicationGroup %{GLOBAL}
<IfVersion >= 2.4>
Require all granted
</IfVersion>
<IfVersion < 2.4>
Order allow,deny
Allow from all
</IfVersion>
</Directory>
</VirtualHost>

View File

@@ -1,3 +1,5 @@
#!/bin/bash
#
# lib/watcher
# Functions to control the configuration and operation of the watcher services
@@ -36,6 +38,7 @@ GITBRANCH["python-watcherclient"]=${WATCHERCLIENT_BRANCH:-master}
GITDIR["python-watcherclient"]=$DEST/python-watcherclient
WATCHER_STATE_PATH=${WATCHER_STATE_PATH:=$DATA_DIR/watcher}
WATCHER_AUTH_CACHE_DIR=${WATCHER_AUTH_CACHE_DIR:-/var/cache/watcher}
WATCHER_CONF_DIR=/etc/watcher
WATCHER_CONF=$WATCHER_CONF_DIR/watcher.conf
@@ -44,10 +47,26 @@ WATCHER_POLICY_YAML=$WATCHER_CONF_DIR/policy.yaml.sample
WATCHER_DEVSTACK_DIR=$WATCHER_DIR/devstack
WATCHER_DEVSTACK_FILES_DIR=$WATCHER_DEVSTACK_DIR/files
NOVA_CONF_DIR=/etc/nova
NOVA_CONF=$NOVA_CONF_DIR/nova.conf
if is_ssl_enabled_service "watcher" || is_service_enabled tls-proxy; then
WATCHER_SERVICE_PROTOCOL="https"
fi
WATCHER_USE_MOD_WSGI=$(trueorfalse True WATCHER_USE_MOD_WSGI)
if is_suse; then
WATCHER_WSGI_DIR=${WATCHER_WSGI_DIR:-/srv/www/htdocs/watcher}
else
WATCHER_WSGI_DIR=${WATCHER_WSGI_DIR:-/var/www/watcher}
fi
# Public facing bits
WATCHER_SERVICE_HOST=${WATCHER_SERVICE_HOST:-$HOST_IP}
WATCHER_SERVICE_PORT=${WATCHER_SERVICE_PORT:-9322}
WATCHER_SERVICE_PORT_INT=${WATCHER_SERVICE_PORT_INT:-19322}
WATCHER_SERVICE_PROTOCOL=${WATCHER_SERVICE_PROTOCOL:-$SERVICE_PROTOCOL}
# Support entry points installation of console scripts
if [[ -d $WATCHER_DIR/bin ]]; then
WATCHER_BIN_DIR=$WATCHER_DIR/bin
@@ -55,17 +74,6 @@ else
WATCHER_BIN_DIR=$(get_python_exec_prefix)
fi
WATCHER_UWSGI=watcher.wsgi.api:application
WATCHER_UWSGI_CONF=$WATCHER_CONF_DIR/watcher-uwsgi.ini
WATCHER_WSGI_DIR=${WATCHER_WSGI_DIR:-/var/www/watcher}
# Public facing bits
WATCHER_SERVICE_HOST=${WATCHER_SERVICE_HOST:-$SERVICE_HOST}
WATCHER_SERVICE_PORT=${WATCHER_SERVICE_PORT:-9322}
WATCHER_SERVICE_PORT_INT=${WATCHER_SERVICE_PORT_INT:-19322}
WATCHER_SERVICE_PROTOCOL=${WATCHER_SERVICE_PROTOCOL:-$SERVICE_PROTOCOL}
WATCHER_API_URL="$WATCHER_SERVICE_PROTOCOL://$WATCHER_SERVICE_HOST/infra-optim"
# Entry Points
# ------------
@@ -87,8 +95,10 @@ function _cleanup_watcher_apache_wsgi {
# cleanup_watcher() - Remove residual data files, anything left over from previous
# runs that a clean run would need to clean up
function cleanup_watcher {
sudo rm -rf $WATCHER_STATE_PATH
remove_uwsgi_config "$WATCHER_UWSGI_CONF" "$WATCHER_UWSGI"
sudo rm -rf $WATCHER_STATE_PATH $WATCHER_AUTH_CACHE_DIR
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
_cleanup_watcher_apache_wsgi
fi
}
# configure_watcher() - Set config files, create data dirs, etc
@@ -132,9 +142,31 @@ function create_watcher_accounts {
"infra-optim" "Watcher Infrastructure Optimization Service")
get_or_create_endpoint $watcher_service \
"$REGION_NAME" \
"$WATCHER_API_URL"\
"$WATCHER_API_URL"\
"$WATCHER_API_URL"
"$WATCHER_SERVICE_PROTOCOL://$WATCHER_SERVICE_HOST:$WATCHER_SERVICE_PORT" \
"$WATCHER_SERVICE_PROTOCOL://$WATCHER_SERVICE_HOST:$WATCHER_SERVICE_PORT" \
"$WATCHER_SERVICE_PROTOCOL://$WATCHER_SERVICE_HOST:$WATCHER_SERVICE_PORT"
}
# _config_watcher_apache_wsgi() - Set WSGI config files of watcher
function _config_watcher_apache_wsgi {
local watcher_apache_conf
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
sudo mkdir -p $WATCHER_WSGI_DIR
sudo cp $WATCHER_DIR/watcher/api/app.wsgi $WATCHER_WSGI_DIR/app.wsgi
watcher_apache_conf=$(apache_site_config_for watcher-api)
sudo cp $WATCHER_DEVSTACK_FILES_DIR/apache-watcher-api.template $watcher_apache_conf
sudo sed -e "
s|%WATCHER_SERVICE_PORT%|$WATCHER_SERVICE_PORT|g;
s|%WATCHER_WSGI_DIR%|$WATCHER_WSGI_DIR|g;
s|%USER%|$STACK_USER|g;
s|%APIWORKERS%|$API_WORKERS|g;
s|%APACHE_NAME%|$APACHE_NAME|g;
" -i $watcher_apache_conf
enable_apache_site watcher-api
tail_log watcher-access /var/log/$APACHE_NAME/watcher-api-access.log
tail_log watcher-api /var/log/$APACHE_NAME/watcher-api.log
fi
}
# create_watcher_conf() - Create a new watcher.conf file
@@ -148,22 +180,26 @@ function create_watcher_conf {
iniset_rpc_backend watcher $WATCHER_CONF
iniset $WATCHER_CONF database connection $(database_connection_url watcher)
iniset $WATCHER_CONF api host "$(ipv6_unquote $WATCHER_SERVICE_HOST)"
iniset $WATCHER_CONF api host "$WATCHER_SERVICE_HOST"
if is_service_enabled tls-proxy; then
iniset $WATCHER_CONF api host "$(ipv6_unquote $WATCHER_SERVICE_HOST)"
iniset $WATCHER_CONF api port "$WATCHER_SERVICE_PORT_INT"
# iniset $WATCHER_CONF api enable_ssl_api "True"
else
iniset $WATCHER_CONF api port "$WATCHER_SERVICE_PORT"
fi
iniset $WATCHER_CONF oslo_policy policy_file $WATCHER_POLICY_YAML
iniset $WATCHER_CONF oslo_messaging_notifications driver "messagingv2"
configure_keystone_authtoken_middleware $WATCHER_CONF watcher
configure_keystone_authtoken_middleware $WATCHER_CONF watcher "watcher_clients_auth"
iniset $NOVA_CONF oslo_messaging_notifications topics "notifications,watcher_notifications"
iniset $NOVA_CONF notifications notify_on_state_change "vm_and_task_state"
if is_fedora; then
configure_auth_token_middleware $WATCHER_CONF watcher $WATCHER_AUTH_CACHE_DIR
configure_auth_token_middleware $WATCHER_CONF watcher $WATCHER_AUTH_CACHE_DIR "watcher_clients_auth"
if is_fedora || is_suse; then
# watcher defaults to /usr/local/bin, but fedora and suse pip like to
# install things in /usr/bin
iniset $WATCHER_CONF DEFAULT bindir "/usr/bin"
@@ -179,10 +215,17 @@ function create_watcher_conf {
fi
# Format logging
setup_logging $WATCHER_CONF
write_uwsgi_config "$WATCHER_UWSGI_CONF" "$WATCHER_UWSGI" "/infra-optim" "" "watcher-api"
if [ "$LOG_COLOR" == "True" ] && [ "$SYSLOG" == "False" ]; then
setup_colorized_logging $WATCHER_CONF DEFAULT
else
# Show user_name and project_name instead of user_id and project_id
iniset $WATCHER_CONF DEFAULT logging_context_format_string "%(asctime)s.%(msecs)03d %(levelname)s %(name)s [%(request_id)s %(project_domain)s %(user_name)s %(project_name)s] %(instance)s%(message)s"
fi
#config apache files
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
_config_watcher_apache_wsgi
fi
# Register SSL certificates if provided
if is_ssl_enabled_service watcher; then
ensure_certificates WATCHER
@@ -192,6 +235,17 @@ function create_watcher_conf {
iniset $WATCHER_CONF DEFAULT enabled_ssl_apis "$WATCHER_ENABLED_APIS"
fi
if is_service_enabled ceilometer; then
iniset $WATCHER_CONF watcher_messaging notifier_driver "messaging"
fi
}
# create_watcher_cache_dir() - Part of the init_watcher() process
function create_watcher_cache_dir {
# Create cache dir
sudo install -d -o $STACK_USER $WATCHER_AUTH_CACHE_DIR
rm -rf $WATCHER_AUTH_CACHE_DIR/*
}
# init_watcher() - Initialize databases, etc.
@@ -205,6 +259,7 @@ function init_watcher {
# Create watcher schema
$WATCHER_BIN_DIR/watcher-db-manage --config-file $WATCHER_CONF upgrade
fi
create_watcher_cache_dir
}
# install_watcherclient() - Collect source and prepare
@@ -213,15 +268,15 @@ function install_watcherclient {
git_clone_by_name "python-watcherclient"
setup_dev_lib "python-watcherclient"
fi
if [[ "$GLOBAL_VENV" == "True" ]]; then
sudo ln -sf /opt/stack/data/venv/bin/watcher /usr/local/bin
fi
}
# install_watcher() - Collect source and prepare
function install_watcher {
git_clone $WATCHER_REPO $WATCHER_DIR $WATCHER_BRANCH
setup_develop $WATCHER_DIR
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
install_apache_wsgi
fi
}
# start_watcher_api() - Start the API process ahead of other things
@@ -230,20 +285,24 @@ function start_watcher_api {
local service_port=$WATCHER_SERVICE_PORT
local service_protocol=$WATCHER_SERVICE_PROTOCOL
local watcher_url
if is_service_enabled tls-proxy; then
service_port=$WATCHER_SERVICE_PORT_INT
service_protocol="http"
fi
run_process "watcher-api" "$(which uwsgi) --procname-prefix watcher-api --ini $WATCHER_UWSGI_CONF"
watcher_url=$service_protocol://$SERVICE_HOST/infra-optim
# TODO(sean-k-mooney): we should probably check that we can hit
# the microversion endpoint and get a valid response.
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
restart_apache_server
else
run_process watcher-api "$WATCHER_BIN_DIR/watcher-api --config-file $WATCHER_CONF"
fi
echo "Waiting for watcher-api to start..."
if ! wait_for_service $SERVICE_TIMEOUT $watcher_url; then
if ! wait_for_service $SERVICE_TIMEOUT $service_protocol://$WATCHER_SERVICE_HOST:$service_port; then
die $LINENO "watcher-api did not start"
fi
# Start proxies if enabled
if is_service_enabled tls-proxy; then
start_tls_proxy watcher '*' $WATCHER_SERVICE_PORT $WATCHER_SERVICE_HOST $WATCHER_SERVICE_PORT_INT
fi
}
# start_watcher() - Start running processes, including screen
@@ -256,25 +315,17 @@ function start_watcher {
# stop_watcher() - Stop running processes (non-screen)
function stop_watcher {
stop_process watcher-api
if [[ "$WATCHER_USE_MOD_WSGI" == "True" ]]; then
disable_apache_site watcher-api
restart_apache_server
else
stop_process watcher-api
fi
for serv in watcher-decision-engine watcher-applier; do
stop_process $serv
done
}
# configure_tempest_for_watcher() - Configure Tempest for watcher
function configure_tempest_for_watcher {
# Set default microversion for watcher-tempest-plugin
# Please make sure to update this when the microversion is updated, otherwise
# new tests may be skipped.
TEMPEST_WATCHER_MIN_MICROVERSION=${TEMPEST_WATCHER_MIN_MICROVERSION:-"1.0"}
TEMPEST_WATCHER_MAX_MICROVERSION=${TEMPEST_WATCHER_MAX_MICROVERSION:-"1.6"}
# Set microversion options in tempest.conf
iniset $TEMPEST_CONFIG optimize min_microversion $TEMPEST_WATCHER_MIN_MICROVERSION
iniset $TEMPEST_CONFIG optimize max_microversion $TEMPEST_WATCHER_MAX_MICROVERSION
}
# Restore xtrace
$_XTRACE_WATCHER

View File

@@ -10,7 +10,6 @@ SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=azertytoken
HOST_IP=192.168.42.2 # Change this to this compute node's IP address
#HOST_IPV6=2001:db8::7
FLAT_INTERFACE=eth0
FIXED_RANGE=10.254.1.0/24 # Change this to whatever your network is
@@ -26,32 +25,25 @@ GLANCE_HOSTPORT=${SERVICE_HOST}:9292
DATABASE_TYPE=mysql
# Enable services (including neutron)
ENABLED_SERVICES=n-cpu,n-api-meta,c-vol,q-agt,placement-client,node-exporter
ENABLED_SERVICES=n-cpu,n-api-meta,c-vol,q-agt,placement-client
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
VNCSERVER_LISTEN=0.0.0.0
VNCSERVER_PROXYCLIENT_ADDRESS=$HOST_IP # or HOST_IPV6
VNCSERVER_PROXYCLIENT_ADDRESS=$HOST_IP
NOVA_INSTANCES_PATH=/opt/stack/data/instances
# Enable the Ceilometer plugin for the compute agent
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
disable_service ceilometer-acentral,ceilometer-collector,ceilometer-api
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
CEILOMETER_BACKEND="none"
CEILOMETER_BACKENDS="none"
enable_plugin devstack-plugin-prometheus https://opendev.org/openstack/devstack-plugin-prometheus
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
notify_on_state_change = vm_and_task_state
[notifications]
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles versioned
# notifications from nova: https://bugs.launchpad.net/ceilometer/+bug/1665449
notification_format=both
notify_on_state_change = vm_and_task_state

View File

@@ -10,7 +10,6 @@ SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=azertytoken
HOST_IP=192.168.42.1 # Change this to your controller node IP address
#HOST_IPV6=2001:db8::7
FLAT_INTERFACE=eth0
FIXED_RANGE=10.254.1.0/24 # Change this to whatever your network is
@@ -18,10 +17,6 @@ NETWORK_GATEWAY=10.254.1.1 # Change this for your network
MULTI_HOST=1
CEILOMETER_ALARM_THRESHOLD="6000000000"
CEILOMETER_BACKENDS="sg-core"
CEILOMETER_PIPELINE_INTERVAL="15"
#Set this to FALSE if do not want to run watcher-api behind mod-wsgi
#WATCHER_USE_MOD_WSGI=TRUE
@@ -30,13 +25,13 @@ CEILOMETER_PIPELINE_INTERVAL="15"
disable_service n-cpu
# Enable the Watcher Dashboard plugin
enable_plugin watcher-dashboard https://opendev.org/openstack/watcher-dashboard
enable_plugin watcher-dashboard https://git.openstack.org/openstack/watcher-dashboard
# Enable the Watcher plugin
enable_plugin watcher https://opendev.org/openstack/watcher
enable_plugin watcher https://git.openstack.org/openstack/watcher
# Enable the Ceilometer plugin
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
# This is the controller node, so disable the ceilometer compute agent
disable_service ceilometer-acompute
@@ -44,10 +39,8 @@ disable_service ceilometer-acompute
# Enable the ceilometer api explicitly(bug:1667678)
enable_service ceilometer-api
enable_service prometheus
enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin devstack-plugin-prometheus https://opendev.org/openstack/devstack-plugin-prometheus
enable_plugin sg-core https://github.com/openstack-k8s-operators/sg-core main
# Enable the Gnocchi plugin
enable_plugin gnocchi https://github.com/gnocchixyz/gnocchi
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
@@ -55,48 +48,6 @@ LOGDAYS=2
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
notify_on_state_change = vm_and_task_state
[notifications]
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles versioned
# notifications from nova: https://bugs.launchpad.net/ceilometer/+bug/1665449
notification_format=both
[[post-config|$WATCHER_CONF]]
[prometheus_client]
host = 127.0.0.1
port = 9090
[watcher_cluster_data_model_collectors.baremetal]
period = 120
[watcher_cluster_data_model_collectors.compute]
period = 120
[watcher_cluster_data_model_collectors.storage]
period = 120
[watcher_datasources]
datasources = prometheus
[[test-config|$TEMPEST_CONFIG]]
[optimize]
datasource = prometheus
[service_available]
sg_core = True
[telemetry]
ceilometer_polling_interval = 15
disable_ssl_certificate_validation = True
[telemetry_services]
metric_backends = prometheus
[compute]
min_compute_nodes = 2
min_microversion = 2.56
[compute-feature-enabled]
block_migration_for_live_migration = True
live_migration = True
notify_on_state_change = vm_and_task_state

View File

@@ -1,53 +0,0 @@
# Sample ``local.conf`` for compute node for Watcher development
# NOTE: Copy this file to the root DevStack directory for it to work properly.
[[local|localrc]]
ADMIN_PASSWORD=nomoresecrete
DATABASE_PASSWORD=stackdb
RABBIT_PASSWORD=stackqueue
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=azertytoken
HOST_IP=192.168.42.2 # Change this to this compute node's IP address
#HOST_IPV6=2001:db8::7
FLAT_INTERFACE=eth0
FIXED_RANGE=10.254.1.0/24 # Change this to whatever your network is
NETWORK_GATEWAY=10.254.1.1 # Change this for your network
MULTI_HOST=1
SERVICE_HOST=192.168.42.1 # Change this to the IP of your controller node
MYSQL_HOST=$SERVICE_HOST
RABBIT_HOST=$SERVICE_HOST
GLANCE_HOSTPORT=${SERVICE_HOST}:9292
DATABASE_TYPE=mysql
# Enable services (including neutron)
ENABLED_SERVICES=n-cpu,n-api-meta,c-vol,q-agt,placement-client
NOVA_VNC_ENABLED=True
NOVNCPROXY_URL="http://$SERVICE_HOST:6080/vnc_auto.html"
VNCSERVER_LISTEN=0.0.0.0
VNCSERVER_PROXYCLIENT_ADDRESS=$HOST_IP # or HOST_IPV6
NOVA_INSTANCES_PATH=/opt/stack/data/instances
# Enable the Ceilometer plugin for the compute agent
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
disable_service ceilometer-acentral,ceilometer-collector,ceilometer-api
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
[notifications]
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles versioned
# notifications from nova: https://bugs.launchpad.net/ceilometer/+bug/1665449
notification_format=both

View File

@@ -1,57 +0,0 @@
# Sample ``local.conf`` for controller node for Watcher development
# NOTE: Copy this file to the root DevStack directory for it to work properly.
[[local|localrc]]
ADMIN_PASSWORD=nomoresecrete
DATABASE_PASSWORD=stackdb
RABBIT_PASSWORD=stackqueue
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=azertytoken
HOST_IP=192.168.42.1 # Change this to your controller node IP address
#HOST_IPV6=2001:db8::7
FLAT_INTERFACE=eth0
FIXED_RANGE=10.254.1.0/24 # Change this to whatever your network is
NETWORK_GATEWAY=10.254.1.1 # Change this for your network
MULTI_HOST=1
#Set this to FALSE if do not want to run watcher-api behind mod-wsgi
#WATCHER_USE_MOD_WSGI=TRUE
# This is the controller node, so disable nova-compute
disable_service n-cpu
# Enable the Watcher Dashboard plugin
enable_plugin watcher-dashboard https://opendev.org/openstack/watcher-dashboard
# Enable the Watcher plugin
enable_plugin watcher https://opendev.org/openstack/watcher
# Enable the Ceilometer plugin
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
# This is the controller node, so disable the ceilometer compute agent
disable_service ceilometer-acompute
# Enable the ceilometer api explicitly(bug:1667678)
enable_service ceilometer-api
# Enable the Gnocchi plugin
enable_plugin gnocchi https://github.com/gnocchixyz/gnocchi
LOGFILE=$DEST/logs/stack.sh.log
LOGDAYS=2
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
[notifications]
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles versioned
# notifications from nova: https://bugs.launchpad.net/ceilometer/+bug/1665449
notification_format=both

View File

@@ -1,9 +0,0 @@
# Plug-in overrides
# https://docs.openstack.org/devstack/latest/plugins.html#plugin-interface
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles
# versioned notifications from nova:
# https://bugs.launchpad.net/ceilometer/+bug/1665449
NOVA_NOTIFICATION_FORMAT=both

View File

@@ -1,3 +1,5 @@
#!/bin/bash
#
# plugin.sh - DevStack plugin script to install watcher
# Save trace setting
@@ -36,9 +38,6 @@ if is_service_enabled watcher-api watcher-decision-engine watcher-applier; then
# Start the watcher components
echo_summary "Starting watcher"
start_watcher
elif [[ "$1" == "stack" && "$2" == "test-config" ]]; then
echo_summary "Configuring tempest for watcher"
configure_tempest_for_watcher
fi
if [[ "$1" == "unstack" ]]; then

View File

@@ -1,16 +0,0 @@
global:
scrape_interval: 10s
scrape_configs:
- job_name: "node"
static_configs:
- targets: ["controller:3000"]
- targets: ["controller:9100"]
labels:
fqdn: "controller" # change the hostname here to your controller hostname
- targets: ["compute-1:9100"]
labels:
fqdn: "compute-1" # change the hostname here to your fist compute hostname
- targets: ["compute-2:9100"]
labels:
fqdn: "compute-2" # change the hostname her to your secondd compute hostname
# add as many blocks as compute nodes you have

View File

@@ -1,13 +0,0 @@
# ``upgrade-watcher``
function configure_watcher_upgrade {
XTRACE=$(set +o | grep xtrace)
set -o xtrace
# Copy release-specific files
sudo cp $TARGET_RELEASE_DIR/watcher/etc/watcher/watcher.conf $WATCHER_CONF_DIR/watcher.conf
sudo cp $TARGET_RELEASE_DIR/watcher/etc/watcher/policy.yaml.sample $WATCHER_CONF_DIR/policy.yaml.sample
# reset to previous state
$XTRACE
}

View File

@@ -1,126 +0,0 @@
#!/bin/bash
set -o errexit
source $GRENADE_DIR/grenaderc
source $GRENADE_DIR/functions
source $TOP_DIR/openrc admin demo
set -o xtrace
function _wait_for_status {
while :
do
state=$("${@:2}" -f value -c State)
[[ $state == "SUCCEEDED" ]] && break
if [ $state == "ERROR" ]; then
die $LINENO "ERROR creating audit"
fi
sleep 10
done
}
function create_audit_template {
at_id=$(openstack optimize audittemplate create d1 dummy -s dummy -f value -c UUID)
resource_save watcher at_id $at_id
}
function create_audit {
audit_id=$(openstack optimize audit create -s dummy -g dummy -f value -c UUID)
resource_save watcher audit_id $audit_id
}
function create_audit_with_autotrigger {
audit_at_id=$(openstack optimize audit create -s dummy -g dummy -f value -c UUID --auto-trigger)
resource_save watcher audit_at_id $audit_at_id
}
function verify_audit_template {
local at_id=$(resource_get watcher at_id)
openstack optimize audittemplate show $at_id
}
function verify_audit_with_autotrigger {
local audit_at_id=$(resource_get watcher audit_at_id)
_wait_for_status "SUCCEEDED" openstack optimize audit show $audit_at_id
local actionplan_at_id=$(openstack optimize actionplan list --audit $audit_at_id -c UUID -f value)
resource_save watcher actionplan_at $actionplan_at_id
actionplan_at_state=$(openstack optimize actionplan show $actionplan_at_id -c State -f value)
if [ $actionplan_at_state != "SUCCEEDED" ]; then
die $LINENO "ERROR executing actionplan"
fi
}
function verify_audit {
local audit_id=$(resource_get watcher audit_id)
_wait_for_status "SUCCEEDED" openstack optimize audit show $audit_id
local actionplan_id=$(openstack optimize actionplan list --audit $audit_id -c UUID -f value)
resource_save watcher actionplan $actionplan_id
actionplan_state=$(openstack optimize actionplan show $actionplan_id -c State -f value)
if [ $actionplan_state != "RECOMMENDED" ]; then
die $LINENO "ERROR creating actionplan"
fi
}
function verify_noapi {
# currently no good way
:
}
function delete_audit {
local audit_id=$(resource_get watcher audit_id)
local actionplan_id=$(resource_get watcher actionplan)
watcher actionplan delete $actionplan_id
openstack optimize audit delete $audit_id
}
function delete_audit_with_autotrigger {
local audit_at_id=$(resource_get watcher audit_at_id)
local actionplan_id=$(resource_get watcher actionplan_at)
watcher actionplan delete $actionplan_id
openstack optimize audit delete $audit_at_id
}
function delete_audit_template {
local at_id=$(resource_get watcher at_id)
openstack optimize audittemplate delete $at_id
}
function create {
create_audit_template
create_audit
create_audit_with_autotrigger
}
function verify {
verify_audit_template
verify_audit
verify_audit_with_autotrigger
}
function destroy {
delete_audit_template
delete_audit
delete_audit_with_autotrigger
}
# Dispatcher
case $1 in
"create")
create
;;
"verify_noapi")
verify_noapi
;;
"verify")
verify
;;
"destroy")
destroy
;;
"force_destroy")
set +o errexit
destroy
;;
esac

View File

@@ -1,18 +0,0 @@
register_project_for_upgrade watcher
register_db_to_save watcher
devstack_localrc base enable_plugin watcher https://opendev.org/openstack/watcher $BASE_DEVSTACK_BRANCH
devstack_localrc target enable_plugin watcher https://opendev.org/openstack/watcher
devstack_localrc base enable_service watcher-api watcher-decision-engine watcher-applier
devstack_localrc target enable_service watcher-api watcher-decision-engine watcher-applier
BASE_RUN_SMOKE=False
TARGET_RUN_SMOKE=False
# Enable both versioned and unversioned notifications. Watcher only
# uses versioned notifications but ceilometer uses unversioned. We
# can change this to just versioned when ceilometer handles
# versioned notifications from nova:
# https://bugs.launchpad.net/ceilometer/+bug/1665449
devstack_localrc base NOVA_NOTIFICATION_FORMAT=both

View File

@@ -1,24 +0,0 @@
#!/bin/bash
set -o errexit
source $GRENADE_DIR/grenaderc
source $GRENADE_DIR/functions
# We need base DevStack functions for this
source $BASE_DEVSTACK_DIR/functions
source $BASE_DEVSTACK_DIR/stackrc # needed for status directory
source $BASE_DEVSTACK_DIR/lib/tls
source $BASE_DEVSTACK_DIR/lib/apache
WATCHER_DEVSTACK_DIR=$(dirname $(dirname $0))
source $WATCHER_DEVSTACK_DIR/settings
source $WATCHER_DEVSTACK_DIR/plugin.sh
source $WATCHER_DEVSTACK_DIR/lib/watcher
set -o xtrace
stop_watcher
# sanity check that service is actually down
ensure_services_stopped watcher-api watcher-decision-engine watcher-applier

View File

@@ -1,83 +0,0 @@
#!/usr/bin/env bash
# ``upgrade-watcher``
echo "*********************************************************************"
echo "Begin $0"
echo "*********************************************************************"
# Clean up any resources that may be in use
cleanup() {
set +o errexit
echo "********************************************************************"
echo "ERROR: Abort $0"
echo "********************************************************************"
# Kill ourselves to signal any calling process
trap 2; kill -2 $$
}
trap cleanup SIGHUP SIGINT SIGTERM
# Keep track of the grenade directory
RUN_DIR=$(cd $(dirname "$0") && pwd)
# Source params
source $GRENADE_DIR/grenaderc
# Import common functions
source $GRENADE_DIR/functions
# This script exits on an error so that errors don't compound and you see
# only the first error that occurred.
set -o errexit
# Upgrade watcher
# ============
# Get functions from current DevStack
source $TARGET_DEVSTACK_DIR/stackrc
source $TARGET_DEVSTACK_DIR/lib/apache
source $TARGET_DEVSTACK_DIR/lib/tls
source $TARGET_DEVSTACK_DIR/lib/keystone
source $TOP_DIR/openrc admin admin
source $(dirname $(dirname $BASH_SOURCE))/settings
source $(dirname $(dirname $BASH_SOURCE))/plugin.sh
# Print the commands being run so that we can see the command that triggers
# an error. It is also useful for following allowing as the install occurs.
set -o xtrace
# Save current config files for posterity
[[ -d $SAVE_DIR/etc.watcher ]] || cp -pr $WATCHER_CONF_DIR $SAVE_DIR/etc.watcher
# Install the target watcher
install_watcher
# calls upgrade-watcher for specific release
upgrade_project watcher $RUN_DIR $BASE_DEVSTACK_BRANCH $TARGET_DEVSTACK_BRANCH
if [[ ! -f "$WATCHER_UWSGI_CONF" ]] && [[ "$WATCHER_USE_WSGI_MODE" == "uwsgi" ]]
then write_uwsgi_config "$WATCHER_UWSGI_CONF" "$WATCHER_UWSGI" "/infra-optim"
endpoints=$(openstack endpoint list --service watcher -c ID -f value)
for id in $endpoints; do
openstack endpoint delete $id
done
create_watcher_accounts
fi
# Migrate the database
$WATCHER_BIN_DIR/watcher-db-manage upgrade || die $LINO "DB migration error"
start_watcher
# Don't succeed unless the services come up
ensure_services_started watcher-api watcher-decision-engine watcher-applier
set +o xtrace
echo "*********************************************************************"
echo "SUCCESS: End $0"
echo "*********************************************************************"

View File

@@ -1,4 +0,0 @@
thirdparty
assertin
notin

View File

@@ -13,6 +13,8 @@
# See the License for the specific language governing permissions and
# limitations under the License.
from __future__ import unicode_literals
import importlib
import inspect
@@ -52,7 +54,7 @@ class BaseWatcherDirective(rst.Directive):
obj_raw_docstring = obj.__init__.__doc__
if not obj_raw_docstring:
# Raise a warning to make the tests fail with doc8
# Raise a warning to make the tests fail wit doc8
raise self.error("No docstring available for %s!" % obj)
obj_docstring = inspect.cleandoc(obj_raw_docstring)

View File

@@ -14,7 +14,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "CANCELLED",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -25,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "CANCELLING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -24,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "FAILED",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -35,7 +34,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "CANCELLING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -14,7 +14,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "CANCELLING",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -25,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "CANCELLING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -13,7 +13,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "PENDING",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -24,7 +23,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -13,7 +13,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "DELETED",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -24,7 +23,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -14,7 +14,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "SUCCEEDED",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -25,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -24,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "FAILED",
"status_message": "Action execution failed",
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -35,7 +34,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -14,7 +14,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -25,7 +24,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -18,12 +18,10 @@
"watcher_object.name": "ActionStateUpdatePayload",
"watcher_object.data": {
"old_state": "PENDING",
"state": "ONGOING",
"status_message": null
"state": "ONGOING"
}
},
"state": "ONGOING",
"status_message": null,
"action_plan": {
"watcher_object.namespace": "watcher",
"watcher_object.version": "1.0",
@@ -34,7 +32,6 @@
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_uuid": "10a47dd1-4874-4298-91cf-eff046dbdb8d",
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"deleted_at": null

View File

@@ -21,7 +21,6 @@
"scope": [],
"audit_type": "ONESHOT",
"state": "SUCCEEDED",
"status_message": null,
"parameters": {},
"interval": null,
"updated_at": null
@@ -30,7 +29,6 @@
"uuid": "76be87bd-3422-43f9-93a0-e85a577e3061",
"fault": null,
"state": "CANCELLED",
"status_message": null,
"global_efficacy": [],
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"strategy": {

View File

@@ -52,15 +52,13 @@
"scope": [],
"updated_at": null,
"audit_type": "ONESHOT",
"status_message": null,
"interval": null,
"deleted_at": null,
"state": "SUCCEEDED"
}
},
"global_efficacy": [],
"state": "CANCELLING",
"status_message": null
"state": "CANCELLING"
}
},
"timestamp": "2016-10-18 09:52:05.219414"

View File

@@ -21,7 +21,6 @@
"scope": [],
"audit_type": "ONESHOT",
"state": "SUCCEEDED",
"status_message": null,
"parameters": {},
"interval": null,
"updated_at": null
@@ -30,7 +29,6 @@
"uuid": "76be87bd-3422-43f9-93a0-e85a577e3061",
"fault": null,
"state": "CANCELLING",
"status_message": null,
"global_efficacy": [],
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"strategy": {

View File

@@ -33,7 +33,6 @@
"interval": null,
"deleted_at": null,
"state": "PENDING",
"status_message": null,
"created_at": "2016-10-18T09:52:05Z",
"updated_at": null
},
@@ -44,7 +43,6 @@
"global_efficacy": {},
"deleted_at": null,
"state": "RECOMMENDED",
"status_message": null,
"updated_at": null
},
"watcher_object.namespace": "watcher",

View File

@@ -18,7 +18,6 @@
"updated_at": null,
"deleted_at": null,
"state": "PENDING",
"status_message": null,
"created_at": "2016-10-18T09:52:05Z",
"parameters": {}
},
@@ -44,8 +43,7 @@
"watcher_object.name": "StrategyPayload",
"watcher_object.namespace": "watcher"
},
"state": "DELETED",
"status_message": null
"state": "DELETED"
},
"watcher_object.version": "1.0",
"watcher_object.name": "ActionPlanDeletePayload",

View File

@@ -22,7 +22,6 @@
"scope": [],
"audit_type": "ONESHOT",
"state": "SUCCEEDED",
"status_message": null,
"parameters": {},
"interval": null,
"updated_at": null
@@ -31,7 +30,6 @@
"uuid": "76be87bd-3422-43f9-93a0-e85a577e3061",
"fault": null,
"state": "ONGOING",
"status_message": null,
"global_efficacy": [],
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"strategy": {

View File

@@ -55,13 +55,11 @@
"audit_type": "ONESHOT",
"interval": null,
"deleted_at": null,
"state": "PENDING",
"status_message": null
"state": "PENDING"
}
},
"global_efficacy": [],
"state": "ONGOING",
"status_message": null
"state": "ONGOING"
}
},
"timestamp": "2016-10-18 09:52:05.219414"

View File

@@ -22,7 +22,6 @@
"scope": [],
"audit_type": "ONESHOT",
"state": "PENDING",
"status_message": null,
"parameters": {},
"interval": null,
"updated_at": null
@@ -31,7 +30,6 @@
"uuid": "76be87bd-3422-43f9-93a0-e85a577e3061",
"fault": null,
"state": "ONGOING",
"status_message": null,
"global_efficacy": [],
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"strategy": {

View File

@@ -16,7 +16,6 @@
"interval": null,
"updated_at": null,
"state": "PENDING",
"status_message": null,
"deleted_at": null,
"parameters": {}
},
@@ -36,7 +35,6 @@
"watcher_object.name": "ActionPlanStateUpdatePayload"
},
"state": "ONGOING",
"status_message": null,
"deleted_at": null,
"strategy_uuid": "cb3d0b58-4415-4d90-b75b-1e96878730e3",
"strategy": {

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "PENDING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"goal_uuid": "bc830f84-8ae3-4fc6-8bc6-e3dd15e8b49a",

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "DELETED",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"goal_uuid": "bc830f84-8ae3-4fc6-8bc6-e3dd15e8b49a",

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": null,

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": {

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": null,

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": null,

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": {

View File

@@ -9,7 +9,6 @@
"para1": 3.2
},
"state": "ONGOING",
"status_message": null,
"updated_at": null,
"deleted_at": null,
"fault": null,

View File

@@ -70,7 +70,6 @@
"interval": null,
"updated_at": null,
"state": "ONGOING",
"status_message": null,
"audit_type": "ONESHOT"
},
"watcher_object.namespace": "watcher",

View File

@@ -1,10 +0,0 @@
sphinx>=2.1.1 # BSD
sphinxcontrib-svg2pdfconverter>=0.1.0 # BSD
sphinxcontrib-pecanwsme>=0.8.0 # Apache-2.0
sphinxcontrib-apidoc>=0.2.0 # BSD
# openstack
os-api-ref>=1.4.0 # Apache-2.0
openstackdocstheme>=2.2.1 # Apache-2.0
# releasenotes
reno>=3.1.0 # Apache-2.0

View File

@@ -44,6 +44,6 @@ Installing API behind mod_wsgi
Fedora/RHEL7/CentOS7:
sudo systemctl reload httpd
Debian/Ubuntu:
sudo a2ensite watcher
sudo service apache2 reload
Debian/Ubuntu:
sudo a2ensite watcher
sudo service apache2 reload

View File

@@ -34,7 +34,7 @@ own sections. However, the base *GMR* consists of several sections:
Package
Shows information about the package to which this process belongs, including
version information.
version informations.
Threads
Shows stack traces and thread ids for each of the threads within this

View File

@@ -8,7 +8,5 @@ Administrator Guide
apache-mod-wsgi
gmr
policy
ways-to-install
../strategies/index
../datasources/index
../contributor/notifications
../contributor/concurrency

View File

@@ -17,14 +17,6 @@
Policies
========
.. warning::
JSON formatted policy file is deprecated since Watcher 6.0.0 (Wallaby).
This `oslopolicy-convert-json-to-yaml`__ tool will migrate your existing
JSON-formatted policy file to YAML in a backward-compatible way.
.. __: https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-convert-json-to-yaml.html
Watcher's public API calls may be restricted to certain sets of users using a
policy configuration file. This document explains exactly how policies are
configured and what they apply to.

View File

@@ -51,7 +51,7 @@ Clone the Watcher repository:
.. code-block:: bash
$ git clone https://opendev.org/openstack/watcher.git
$ git clone https://git.openstack.org/openstack/watcher.git
$ cd watcher
Install the Watcher modules:
@@ -92,7 +92,7 @@ these commands:
By default, this will show logging on the console from which it was started.
Once started, you can use the `Watcher Client`_ to play with Watcher service.
.. _`Watcher Client`: https://opendev.org/openstack/python-watcherclient
.. _`Watcher Client`: https://git.openstack.org/cgit/openstack/python-watcherclient
Installing from packages: PyPI
--------------------------------

8
doc/source/api/index.rst Normal file
View File

@@ -0,0 +1,8 @@
==================================================
OpenStack Infrastructure Optimization Service APIs
==================================================
.. toctree::
:maxdepth: 1
v1

100
doc/source/api/v1.rst Normal file
View File

@@ -0,0 +1,100 @@
..
Except where otherwise noted, this document is licensed under Creative
Commons Attribution 3.0 License. You can view the license at:
https://creativecommons.org/licenses/by/3.0/
====================
RESTful Web API (v1)
====================
Goals
=====
.. rest-controller:: watcher.api.controllers.v1.goal:GoalsController
:webprefix: /v1/goal
.. autotype:: watcher.api.controllers.v1.goal.GoalCollection
:members:
.. autotype:: watcher.api.controllers.v1.goal.Goal
:members:
Strategies
==========
.. rest-controller:: watcher.api.controllers.v1.strategy:StrategiesController
:webprefix: /v1/strategies
.. autotype:: watcher.api.controllers.v1.strategy.StrategyCollection
:members:
.. autotype:: watcher.api.controllers.v1.strategy.Strategy
:members:
Audit Templates
===============
.. rest-controller:: watcher.api.controllers.v1.audit_template:AuditTemplatesController
:webprefix: /v1/audit_templates
.. autotype:: watcher.api.controllers.v1.audit_template.AuditTemplateCollection
:members:
.. autotype:: watcher.api.controllers.v1.audit_template.AuditTemplate
:members:
Audits
======
.. rest-controller:: watcher.api.controllers.v1.audit:AuditsController
:webprefix: /v1/audits
.. autotype:: watcher.api.controllers.v1.audit.AuditCollection
:members:
.. autotype:: watcher.api.controllers.v1.audit.Audit
:members:
Links
=====
.. autotype:: watcher.api.controllers.link.Link
:members:
Action Plans
============
.. rest-controller:: watcher.api.controllers.v1.action_plan:ActionPlansController
:webprefix: /v1/action_plans
.. autotype:: watcher.api.controllers.v1.action_plan.ActionPlanCollection
:members:
.. autotype:: watcher.api.controllers.v1.action_plan.ActionPlan
:members:
Actions
=======
.. rest-controller:: watcher.api.controllers.v1.action:ActionsController
:webprefix: /v1/actions
.. autotype:: watcher.api.controllers.v1.action.ActionCollection
:members:
.. autotype:: watcher.api.controllers.v1.action.Action
:members:
Scoring Engine
==============
.. rest-controller:: watcher.api.controllers.v1.scoring_engine:ScoringEngineController
:webprefix: /v1/scoring_engine
.. autotype:: watcher.api.controllers.v1.scoring_engine.ScoringEngineCollection
:members:
.. autotype:: watcher.api.controllers.v1.scoring_engine.ScoringEngine
:members:

View File

@@ -76,7 +76,6 @@ Watcher Applier
This component is in charge of executing the
:ref:`Action Plan <action_plan_definition>` built by the
:ref:`Watcher Decision Engine <watcher_decision_engine_definition>`.
Taskflow is the default workflow engine for Watcher.
It connects to the :ref:`message bus <amqp_bus_definition>` and launches the
:ref:`Action Plan <action_plan_definition>` whenever a triggering message is
@@ -111,23 +110,6 @@ If the :ref:`Action <action_definition>` fails, the
previous state of the :ref:`Managed resource <managed_resource_definition>`
(i.e. before the command was sent to the underlying OpenStack service).
In Stein, added a new config option 'action_execution_rule' which is a
dict type. Its key field is strategy name and the value is 'ALWAYS' or 'ANY'.
'ALWAYS' means the callback function returns True as usual.
'ANY' means the return depends on the result of previous action execution.
The callback returns True if previous action gets failed, and the engine
continues to run the next action. If previous action executes success,
the callback returns False then the next action will be ignored.
For strategies that aren't in 'action_execution_rule', the callback always
returns True.
Please add the next section in the watcher.conf file
if your strategy needs this feature.
::
[watcher_workflow_engines.taskflow]
action_execution_rule = {'your strategy name': 'ANY'}
.. _archi_watcher_cli_definition:
Watcher CLI
@@ -281,13 +263,11 @@ previously created :ref:`Audit template <audit_template_definition>`:
:width: 100%
The :ref:`Administrator <administrator_definition>` also can specify type of
Audit and interval (in case of CONTINUOUS type). There is three types of Audit:
ONESHOT, CONTINUOUS and EVENT. ONESHOT Audit is launched once and if it
succeeded executed new action plan list will be provided; CONTINUOUS Audit
creates action plans with specified interval (in seconds or cron format, cron
interval can be used like: ``*/5 * * * *``), if action plan
has been created, all previous action plans get CANCELLED state;
EVENT audit is launched when receiving webhooks API.
Audit and interval (in case of CONTINUOUS type). There is two types of Audit:
ONESHOT and CONTINUOUS. Oneshot Audit is launched once and if it succeeded
executed new action plan list will be provided. Continuous Audit creates
action plans with specified interval (in seconds); if action plan
has been created, all previous action plans get CANCELLED state.
A message is sent on the :ref:`AMQP bus <amqp_bus_definition>` which triggers
the Audit in the
@@ -384,9 +364,7 @@ following methods of the :ref:`Action <action_definition>` handler:
- **preconditions()**: this method will make sure that all conditions are met
before executing the action (for example, it makes sure that an instance
still exists before trying to migrate it). If action specific preconditions
are not met in this phase, the Action is set to **SKIPPED** state and will
not be executed.
still exists before trying to migrate it).
- **execute()**: this method is what triggers real commands on other
OpenStack services (such as Nova, ...) in order to change target resource
state. If the action is successfully executed, a notification message is
@@ -481,39 +459,6 @@ change to a new value:
.. image:: ./images/action_plan_state_machine.png
:width: 100%
.. _action_state_machine:
Action State Machine
-------------------------
An :ref:`Action <action_definition>` has a life-cycle and its current state may
be one of the following:
- **PENDING** : the :ref:`Action <action_definition>` has not been executed
yet by the :ref:`Watcher Applier <watcher_applier_definition>`
- **SKIPPED** : the :ref:`Action <action_definition>` will not be executed
because a predefined skipping condition is found by
:ref:`Watcher Applier <watcher_applier_definition>` or is explicitly
skipped by the :ref:`Administrator <administrator_definition>`.
- **ONGOING** : the :ref:`Action <action_definition>` is currently being
processed by the :ref:`Watcher Applier <watcher_applier_definition>`
- **SUCCEEDED** : the :ref:`Action <action_definition>` has been executed
successfully
- **FAILED** : an error occurred while trying to execute the
:ref:`Action <action_definition>`
- **DELETED** : the :ref:`Action <action_definition>` is still stored in the
:ref:`Watcher database <watcher_database_definition>` but is not returned
any more through the Watcher APIs.
- **CANCELLED** : the :ref:`Action <action_definition>` was in **PENDING** or
**ONGOING** state and was cancelled by the
:ref:`Administrator <administrator_definition>`
The following diagram shows the different possible states of an
:ref:`Action <action_definition>` and what event makes the state change
change to a new value:
.. image:: ./images/action_state_machine.png
:width: 100%
.. _Watcher API: https://docs.openstack.org/api-ref/resource-optimization/
.. _Watcher API: webapi/v1.html

64
doc/source/conf.py Normal file → Executable file
View File

@@ -14,6 +14,7 @@
import os
import sys
from watcher import version as watcher_version
from watcher import objects
objects.register_all()
@@ -31,16 +32,17 @@ sys.path.insert(0, os.path.abspath('./'))
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = [
'oslo_config.sphinxext',
'sphinx.ext.autodoc',
'sphinx.ext.viewcode',
'sphinxcontrib.httpdomain',
'sphinxcontrib.pecanwsme.rest',
'stevedore.sphinxext',
'wsmeext.sphinxext',
'ext.term',
'ext.versioned_notifications',
'oslo_config.sphinxconfiggen',
'openstackdocstheme',
'sphinx.ext.napoleon',
'sphinxcontrib.rsvgconverter',
]
wsme_protocols = ['restjson']
@@ -49,6 +51,10 @@ config_generator_config_file = [(
'_static/watcher')]
sample_config_basename = 'watcher'
# autodoc generation is a bit aggressive and a nuisance when doing heavy
# text edit cycles.
# execute "export SPHINX_DEBUG=1" in your terminal to disable
# The suffix of source filenames.
source_suffix = '.rst'
@@ -56,8 +62,18 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
project = 'Watcher'
copyright = 'OpenStack Foundation'
project = u'Watcher'
copyright = u'OpenStack Foundation'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
# The full version, including alpha/beta/rc tags.
release = watcher_version.version_info.release_string()
# The short X.Y version.
version = watcher_version.version_string
# A list of ignored prefixes for module index sorting.
modindex_common_prefix = ['watcher.']
@@ -83,7 +99,7 @@ add_module_names = True
suppress_warnings = ['app.add_directive']
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'native'
pygments_style = 'sphinx'
# -- Options for man page output --------------------------------------------
@@ -91,14 +107,14 @@ pygments_style = 'native'
# List of tuples 'sourcefile', 'target', u'title', u'Authors name', 'manual'
man_pages = [
('man/watcher-api', 'watcher-api', 'Watcher API Server',
['OpenStack'], 1),
('man/watcher-applier', 'watcher-applier', 'Watcher Applier',
['OpenStack'], 1),
('man/watcher-api', 'watcher-api', u'Watcher API Server',
[u'OpenStack'], 1),
('man/watcher-applier', 'watcher-applier', u'Watcher Applier',
[u'OpenStack'], 1),
('man/watcher-db-manage', 'watcher-db-manage',
'Watcher Db Management Utility', ['OpenStack'], 1),
u'Watcher Db Management Utility', [u'OpenStack'], 1),
('man/watcher-decision-engine', 'watcher-decision-engine',
'Watcher Decision Engine', ['OpenStack'], 1),
u'Watcher Decision Engine', [u'OpenStack'], 1),
]
# -- Options for HTML output --------------------------------------------------
@@ -114,34 +130,22 @@ html_theme = 'openstackdocs'
# Output file base name for HTML help builder.
htmlhelp_basename = '%sdoc' % project
html_last_updated_fmt = '%Y-%m-%d %H:%M'
# openstackdocstheme options
openstackdocs_repo_name = 'openstack/watcher'
openstackdocs_pdf_link = True
openstackdocs_auto_name = False
openstackdocs_bug_project = 'watcher'
openstackdocs_bug_tag = ''
#openstackdocstheme options
repository_name = 'openstack/watcher'
bug_project = 'watcher'
bug_tag = ''
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass
# [howto/manual]).
latex_documents = [
('index',
'doc-watcher.tex',
'Watcher Documentation',
'OpenStack Foundation', 'manual'),
'%s.tex' % project,
u'%s Documentation' % project,
u'OpenStack Foundation', 'manual'),
]
# If false, no module index is generated.
latex_domain_indices = False
latex_elements = {
'makeindex': '',
'printindex': '',
'preamble': r'\setcounter{tocdepth}{3}',
}
# Disable usage of xindy https://bugzilla.redhat.com/show_bug.cgi?id=1643664
latex_use_xindy = False
# Example configuration for intersphinx: refer to the Python standard library.
# intersphinx_mapping = {'http://docs.python.org/': None}

View File

@@ -159,7 +159,7 @@ MySQL database that is used by other OpenStack services.
``watcher`` user. Replace WATCHER_DBPASSWORD
with the actual password::
# mysql
$ mysql -u root -p
mysql> CREATE DATABASE watcher CHARACTER SET utf8;
mysql> GRANT ALL PRIVILEGES ON watcher.* TO 'watcher'@'localhost' \
@@ -178,7 +178,7 @@ You can easily generate and update a sample configuration file
named :ref:`watcher.conf.sample <watcher_sample_configuration_files>` by using
these following commands::
$ git clone https://opendev.org/openstack/watcher.git
$ git clone https://git.openstack.org/openstack/watcher
$ cd watcher/
$ tox -e genconfig
$ vi etc/watcher/watcher.conf.sample
@@ -194,14 +194,11 @@ The configuration file is organized into the following sections:
* ``[watcher_applier]`` - Watcher Applier module configuration
* ``[watcher_decision_engine]`` - Watcher Decision Engine module configuration
* ``[oslo_messaging_rabbit]`` - Oslo Messaging RabbitMQ driver configuration
* ``[ceilometer_client]`` - Ceilometer client configuration
* ``[cinder_client]`` - Cinder client configuration
* ``[glance_client]`` - Glance client configuration
* ``[gnocchi_client]`` - Gnocchi client configuration
* ``[ironic_client]`` - Ironic client configuration
* ``[keystone_client]`` - Keystone client configuration
* ``[nova_client]`` - Nova client configuration
* ``[neutron_client]`` - Neutron client configuration
* ``[placement_client]`` - Placement client configuration
The Watcher configuration file is expected to be named
``watcher.conf``. When starting Watcher, you can specify a different
@@ -375,7 +372,7 @@ You can configure and install Ceilometer by following the documentation below :
#. https://docs.openstack.org/ceilometer/latest
The built-in strategy 'basic_consolidation' provided by watcher requires
"**compute.node.cpu.percent**" and "**cpu**" measurements to be collected
"**compute.node.cpu.percent**" and "**cpu_util**" measurements to be collected
by Ceilometer.
The measurements available depend on the hypervisors that OpenStack manages on
the specific implementation.
@@ -406,22 +403,26 @@ Watcher can consume notifications generated by the Nova services, in order to
build or update, in real time, its cluster data model related to computing
resources.
Nova emits unversioned(legacy) and versioned notifications on different
topics. Because legacy notifications will be deprecated, Watcher consumes
Nova versioned notifications.
Nova publishes, by default, notifications on ``notifications`` AMQP queue
(configurable) and ``versioned_notifications`` AMQP queue (not
configurable). ``notifications`` queue is mainly used by ceilometer, so we can
not use it. And some events, related to nova-compute service state, are only
sent into the ``versioned_notifications`` queue.
* In the file ``/etc/nova/nova.conf``, the value of driver in the section
``[oslo_messaging_notifications]`` can't be noop, and the value of
notification_format in the section ``[notifications]``
should be both or versioned ::
By default, Watcher listens to AMQP queues named ``watcher_notifications``
and ``versioned_notifications``. So you have to update the Nova
configuration file on controller and compute nodes, in order
to Watcher receives Nova notifications in ``watcher_notifications`` as well.
* In the file ``/etc/nova/nova.conf``, update the section
``[oslo_messaging_notifications]``, by redefining the list of topics
into which Nova services will publish events ::
[oslo_messaging_notifications]
driver = messagingv2
topics = notifications,watcher_notifications
...
[notifications]
notification_format = both
* Restart the Nova services.
Configure Cinder Notifications
@@ -429,38 +430,20 @@ Configure Cinder Notifications
Watcher can also consume notifications generated by the Cinder services, in
order to build or update, in real time, its cluster data model related to
storage resources.
storage resources. To do so, you have to update the Cinder configuration
file on controller and volume nodes, in order to let Watcher receive Cinder
notifications in a dedicated ``watcher_notifications`` channel.
Cinder emits notifications on the ``notifications`` topic, in the openstack
control exchange (as it can be seen in the `Cinder conf`_).
* In the file ``/etc/cinder/cinder.conf``, the value of driver in the section
``[oslo_messaging_notifications]`` can't be noop.
* In the file ``/etc/cinder/cinder.conf``, update the section
``[oslo_messaging_notifications]``, by redefining the list of topics
into which Cinder services will publish events ::
[oslo_messaging_notifications]
driver = messagingv2
topics = notifications,watcher_notifications
.. _`Cinder conf`: https://docs.openstack.org/cinder/latest/configuration/block-storage/samples/cinder.conf.html
* Restart the Cinder services.
Configure Watcher listening to the Notifications
================================================
To consume either Cinder or Nova notifications, (or both), Watcher must be
configured to listen to the notifications topics that Cinder and Nova emit.
Use the `notification_topics`_ config option to indicate to Watcher that it
should listen to the correct topics. By default, Cinder emits notifications
on ``openstack.notifications``, while Nova emits notifications on
``nova.versioned_notifications``. The Watcher conf should have the topics for
the desired notifications, below is an example for both Cinder and Nova::
[watcher_decision_engine]
...
notification_topics = nova.versioned_notifications,openstack.notifications
.. _`notification_topics`: https://docs.openstack.org/watcher/latest/configuration/watcher.html#watcher_decision_engine.notification_topics
Workers
=======

View File

@@ -1 +0,0 @@
.. include:: ../../../watcher/api/controllers/rest_api_version_history.rst

View File

@@ -1,273 +0,0 @@
===========
Concurrency
===========
Introduction
************
Modern processors typically contain multiple cores all capable of executing
instructions in parallel. Ensuring applications can fully utilize modern
underlying hardware requires developing with these concepts in mind. The
OpenStack foundation maintains a number of libraries to facilitate this
utilization, combined with constructs like CPython's GIL_ the proper use of
these concepts becomes more straightforward compared to other programming
languages.
The primary libraries maintained by OpenStack to facilitate concurrency are
futurist_ and taskflow_. Here futurist is a more straightforward and
lightweight library while taskflow is more advanced supporting features like
rollback mechanisms. Within Watcher both libraries are used to facilitate
concurrency.
.. _GIL: https://wiki.python.org/moin/GlobalInterpreterLock
.. _futurist: https://docs.openstack.org/futurist/latest/
.. _taskflow: https://docs.openstack.org/taskflow/latest/
Threadpool
**********
A threadpool is a collection of one or more threads typically called *workers*
to which tasks can be submitted. These submitted tasks will be scheduled by a
threadpool and subsequently executed. In the case of Python tasks typically are
bounded or unbounded methods while other programming languages like Java
require implementing an interface.
The order and amount of concurrency with which these tasks are executed is up
to the threadpool to decide. Some libraries like taskflow allow for either
strong or loose ordering of tasks while others like futurist might only support
loose ordering. Taskflow supports building tree-based hierarchies of dependent
tasks for example.
Upon submission of a task to a threadpool a so called future_ is returned.
These objects allow to determine information about the task such as if it is
currently being executed or if it has finished execution. When the task has
finished execution the future can also be used to retrieve what was returned by
the method.
Some libraries like futurist provide synchronization primitives for collections
of futures such as wait_for_any_. The following sections will cover different
types of concurrency used in various services of Watcher.
.. _future: https://docs.python.org/3/library/concurrent.futures.html
.. _wait_for_any: https://docs.openstack.org/futurist/latest/reference/index.html#waiters
Concurrency modes
#################
Evenlet has been the main concurrency library within the OpenStack community
for the last 10 years since the removal of twisted. Over the last few years,
the maintenance of eventlet has decreased and the efforts to remove the GIL
from Python (PEP 703), have fundamentally changed how concurrency is making
eventlet no longer viable. While transitioning to a new native thread
solution, Watcher services will be supporting both modes, with the usage of
native threading mode initially classified as ``experimental``.
It is possible to enable the new native threading mode by setting the following
environment variable in the corresponding service configuration:
.. code:: bash
OS_WATCHER_DISABLE_EVENTLET_PATCHING=true
.. note::
The only service that supports two different concurrency modes is the
``decision engine``.
Decision engine concurrency
***************************
The concurrency in the decision engine is governed by two independent
threadpools. These threadpools can be configured as GreenThreadPoolExecutor_
or ThreadPoolExecutor_, both from the futurist_ library, depending on the
service configuration. One of these is used automatically and most contributors
will not interact with it while developing new features. The other threadpool
can frequently be used while developing new features or updating existing ones.
It is known as the DecisionEngineThreadpool and allows to achieve performance
improvements in network or I/O bound operations.
.. _GreenThreadPoolExecutor: https://docs.openstack.org/futurist/latest/reference/index.html#futurist.GreenThreadPoolExecutor
.. _ThreadPoolExecutor: https://docs.openstack.org/futurist/latest/reference/index.html#futurist.ThreadPoolExecutor
AuditEndpoint
#############
The first threadpool is used to allow multiple audits to be run in parallel.
In practice, however, only one audit can be run in parallel. This is due to
the data model used by audits being a singleton. To prevent audits destroying
each others data model one must wait for the other to complete before being
allowed to access this data model. A performance improvement could be achieved
by being more intelligent in the use, caching and construction of these
data models.
DecisionEngineThreadPool
########################
The second threadpool is used for generic tasks, typically networking and I/O
could benefit the most of this threadpool. Upon execution of an audit this
threadpool can be utilized to retrieve information from the Nova compute
service for instance. This second threadpool is a singleton and is shared
amongst concurrently running audits as a result the amount of workers is static
and independent from the amount of workers in the first threadpool. The use of
the :class:`~.DecisionEngineThreadpool` while building the Nova compute data
model is demonstrated to show how it can effectively be used.
In the following example a reference to the
:class:`~.DecisionEngineThreadpool` is stored in ``self.executor``. Here two
tasks are submitted one with function ``self._collect_aggregates`` and the
other function ``self._collect_zones``. With both ``self.executor.submit``
calls subsequent arguments are passed to the function. All subsequent arguments
are passed to the function being submitted as task following the common
``(fn, *args, **kwargs)`` signature. One of the original signatures would be
``def _collect_aggregates(host_aggregates, compute_nodes)`` for example.
.. code-block:: python
zone_aggregate_futures = {
self.executor.submit(
self._collect_aggregates, host_aggregates, compute_nodes),
self.executor.submit(
self._collect_zones, availability_zones, compute_nodes)
}
waiters.wait_for_all(zone_aggregate_futures)
The last statement of the example above waits on all futures to complete.
Similarly, ``waiters.wait_for_any`` will wait for any future of the specified
collection to complete. To simplify the usage of ``wait_for_any`` the
:class:`~.DecisiongEngineThreadpool` defines a ``do_while_futures`` method.
This method will iterate in a do_while loop over a collection of futures until
all of them have completed. The advantage of ``do_while_futures`` is that it
allows to immediately call a method as soon as a future finishes. The arguments
for this callback method can be supplied when calling ``do_while_futures``,
however, the first argument to the callback is always the future itself! If
the collection of futures can safely be modified ``do_while_futures_modify``
can be used and should have slightly better performance. The following example
will show how ``do_while_futures`` is used in the decision engine.
.. code-block:: python
# For every compute node from compute_nodes submit a task to gather the node it's information.
# List comprehension is used to store all the futures of the submitted tasks in node_futures.
node_futures = [self.executor.submit(
self.nova_helper.get_compute_node_by_name,
node, servers=True, detailed=True)
for node in compute_nodes]
LOG.debug("submitted {0} jobs".format(len(compute_nodes)))
future_instances = []
# do_while iterate over node_futures and upon completion of a future call
# self._compute_node_future with the future and future_instances as arguments.
self.executor.do_while_futures_modify(
node_futures, self._compute_node_future, future_instances)
# Wait for all instance jobs to finish
waiters.wait_for_all(future_instances)
Finally, let's demonstrate how powerful this ``do_while_futures`` can be by
showing what the ``compute_node_future`` callback does. First, it retrieves the
result from the future and adds the compute node to the data model. Afterwards,
it checks if the compute node has any associated instances and if so it submits
an additional task to the :class:`~.DecisionEngineThreadpool`. The future is
appended to the ``future_instances`` so ``waiters.wait_for_all`` can be called
on this list. This is important as otherwise the building of the data model
might return before all tasks for instances have finished.
.. code-block:: python
# Get the result from the future.
node_info = future.result()[0]
# Filter out baremetal nodes.
if node_info.hypervisor_type == 'ironic':
LOG.debug("filtering out baremetal node: %s", node_info)
return
# Add the compute node to the data model.
self.add_compute_node(node_info)
# Get the instances from the compute node.
instances = getattr(node_info, "servers", None)
# Do not submit job if there are no instances on compute node.
if instances is None:
LOG.info("No instances on compute_node: {0}".format(node_info))
return
# Submit a job to retrieve detailed information about the instances.
future_instances.append(
self.executor.submit(
self.add_instance_node, node_info, instances)
)
Without ``do_while_futures`` an additional ``waiters.wait_for_all`` would be
required in between the compute node tasks and the instance tasks. This would
cause the progress of the decision engine to stall as less and less tasks
remain active before the instance tasks could be submitted. This demonstrates
how ``do_while_futures`` can be used to achieve more constant utilization of
the underlying hardware.
Applier concurrency
*******************
The applier does not use the futurist_ GreenThreadPoolExecutor_ directly but
instead uses taskflow_. However, taskflow still utilizes a greenthreadpool.
This threadpool is initialized in the workflow engine called
:class:`~.DefaultWorkFlowEngine`. Currently Watcher supports one workflow
engine but the base class allows contributors to develop other workflow engines
as well. In taskflow tasks are created using different types of flows such as a
linear, unordered or a graph flow. The linear and graph flow allow for strong
ordering between individual tasks and it is for this reason that the workflow
engine utilizes a graph flow. The creation of tasks, subsequently linking them
into a graph like structure and submitting them is shown below.
.. code-block:: python
self.execution_rule = self.get_execution_rule(actions)
flow = gf.Flow("watcher_flow")
actions_uuid = {}
for a in actions:
task = TaskFlowActionContainer(a, self)
flow.add(task)
actions_uuid[a.uuid] = task
for a in actions:
for parent_id in a.parents:
flow.link(actions_uuid[parent_id], actions_uuid[a.uuid],
decider=self.decider)
e = engines.load(
flow, executor='greenthreaded', engine='parallel',
max_workers=self.config.max_workers)
e.run()
return flow
In the applier tasks are contained in a :class:`~.TaskFlowActionContainer`
which allows them to trigger events in the workflow engine. This way the
workflow engine can halt or take other actions while the action plan is being
executed based on the success or failure of individual actions. However, the
base workflow engine simply uses these notifies to store the result of
individual actions in the database. Additionally, since taskflow uses a graph
flow if any of the tasks would fail all children of this tasks not be executed
while ``do_revert`` will be triggered for all parents.
.. code-block:: python
class TaskFlowActionContainer(...):
...
def do_execute(self, *args, **kwargs):
...
result = self.action.execute()
if result is True:
return self.engine.notify(self._db_action,
objects.action.State.SUCCEEDED)
else:
self.engine.notify(self._db_action,
objects.action.State.FAILED)
class BaseWorkFlowEngine(...):
...
def notify(self, action, state):
db_action = objects.Action.get_by_uuid(self.context, action.uuid,
eager=True)
db_action.state = state
db_action.save()
return db_action

View File

@@ -1,111 +1,72 @@
============================
So You Want to Contribute...
============================
..
Except where otherwise noted, this document is licensed under Creative
Commons Attribution 3.0 License. You can view the license at:
For general information on contributing to OpenStack, please check out the
`contributor guide <https://docs.openstack.org/contributors/>`_ to get started.
It covers all the basics that are common to all OpenStack projects:
the accounts you need, the basics of interacting with our Gerrit review system,
how we communicate as a community, etc.
https://creativecommons.org/licenses/by/3.0/
Below will cover the more project specific information you need to get started
with Watcher.
.. _contributing:
Communication
~~~~~~~~~~~~~~
.. This would be a good place to put the channel you chat in as a project; when/
where your meeting is, the tags you prepend to your ML threads, etc.
=======================
Contributing to Watcher
=======================
If you're interested in contributing to the Watcher project,
the following will help get you started.
Contributor License Agreement
-----------------------------
.. index::
single: license; agreement
In order to contribute to the Watcher project, you need to have
signed OpenStack's contributor's agreement.
.. seealso::
* https://docs.openstack.org/infra/manual/developers.html
* https://wiki.openstack.org/CLA
LaunchPad Project
-----------------
Most of the tools used for OpenStack depend on a launchpad.net ID for
authentication. After signing up for a launchpad account, join the
"openstack" team to have access to the mailing list and receive
notifications of important events.
.. seealso::
* https://launchpad.net
* https://launchpad.net/watcher
* https://launchpad.net/openstack
Project Hosting Details
-----------------------
Bug tracker
https://launchpad.net/watcher
Mailing list (prefix subjects with ``[watcher]`` for faster responses)
http://lists.openstack.org/pipermail/openstack-dev/
Wiki
https://wiki.openstack.org/Watcher
Code Hosting
https://git.openstack.org/cgit/openstack/watcher
Code Review
https://review.openstack.org/#/q/status:open+project:openstack/watcher,n,z
IRC Channel
``#openstack-watcher`` (changelog_)
Mailing list(prefix subjects with ``[watcher]``)
http://lists.openstack.org/pipermail/openstack-discuss/
Weekly Meetings
Bi-weekly, on Wednesdays at 08:00 UTC on odd weeks in the
``#openstack-meeting-alt`` IRC channel (`meetings logs`_)
Meeting Agenda
https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda
On Wednesdays at 14:00 UTC on even weeks in the ``#openstack-meeting-4``
IRC channel, 08:00 UTC on odd weeks in the ``#openstack-meeting-alt``
IRC channel (`meetings logs`_)
.. _changelog: http://eavesdrop.openstack.org/irclogs/%23openstack-watcher/
.. _meetings logs: http://eavesdrop.openstack.org/meetings/watcher/
Contacting the Core Team
~~~~~~~~~~~~~~~~~~~~~~~~~
.. This section should list the core team, their irc nicks, emails, timezones etc.
If all this info is maintained elsewhere (i.e. a wiki), you can link to that
instead of enumerating everyone here.
+--------------------+---------------+------------------------------------+
| Name | IRC | Email |
+====================+===============+====================================+
| `Li Canwei`_ | licanwei | li.canwei2@zte.com.cn |
+--------------------+---------------+------------------------------------+
| `chen ke`_ | chenke | chen.ke14@zte.com.cn |
+--------------------+---------------+------------------------------------+
| `Corne Lukken`_ | dantalion | info@dantalion.nl |
+--------------------+---------------+------------------------------------+
| `su zhengwei`_ | suzhengwei | sugar-2008@163.com |
+--------------------+---------------+------------------------------------+
| `Yumeng Bao`_ | Yumeng | yumeng_bao@yahoo.com |
+--------------------+---------------+------------------------------------+
.. _Corne Lukken: https://launchpad.net/~dantalion
.. _Li Canwei: https://launchpad.net/~li-canwei2
.. _su zhengwei: https://launchpad.net/~sue.sam
.. _Yumeng Bao: https://launchpad.net/~yumeng-bao
.. _chen ke: https://launchpad.net/~chenker
New Feature Planning
~~~~~~~~~~~~~~~~~~~~
.. This section is for talking about the process to get a new feature in. Some
projects use blueprints, some want specs, some want both! Some projects
stick to a strict schedule when selecting what new features will be reviewed
for a release.
New feature will be discussed via IRC or ML (with [Watcher] prefix).
Watcher team uses blueprints in `Launchpad`_ to manage the new features.
.. _Launchpad: https://launchpad.net/watcher
Task Tracking
~~~~~~~~~~~~~~
.. This section is about where you track tasks- launchpad? storyboard?
is there more than one launchpad project? what's the name of the project
group in storyboard?
We track our tasks in Launchpad.
If you're looking for some smaller, easier work item to pick up and get started
on, search for the 'low-hanging-fruit' tag.
.. NOTE: If your tag is not 'low-hanging-fruit' please change the text above.
Reporting a Bug
~~~~~~~~~~~~~~~
.. Pretty self explanatory section, link directly to where people should report bugs for
your project.
You found an issue and want to make sure we are aware of it? You can do so
`HERE`_.
.. _HERE: https://bugs.launchpad.net/watcher
Getting Your Patch Merged
~~~~~~~~~~~~~~~~~~~~~~~~~
.. This section should have info about what it takes to get something merged.
Do you require one or two +2's before +W? Do some of your repos require
unit test changes with all patches? etc.
Due to the small number of core reviewers of the Watcher project,
we only need one +2 before +W (merge). All patches excepting for documentation
or typos fixes must have unit test.
Project Team Lead Duties
------------------------
.. this section is where you can put PTL specific duties not already listed in
the common PTL guide (linked below) or if you already have them written
up elsewhere, you can link to that doc here.
All common PTL duties are enumerated here in the `PTL guide <https://docs.openstack.org/project-team-guide/ptl.html>`_.

View File

@@ -16,10 +16,10 @@ multinode environment to use.
You can set up the Watcher services quickly and easily using a Watcher
DevStack plugin. See `PluginModelDocs`_ for information on DevStack's plugin
model. To enable the Watcher plugin with DevStack, add the following to the
``[[local|localrc]]`` section of your controller's ``local.conf`` to enable the
`[[local|localrc]]` section of your controller's `local.conf` to enable the
Watcher plugin::
enable_plugin watcher https://opendev.org/openstack/watcher
enable_plugin watcher https://git.openstack.org/openstack/watcher
For more detailed instructions, see `Detailed DevStack Instructions`_. Check
out the `DevStack documentation`_ for more information regarding DevStack.
@@ -27,108 +27,38 @@ out the `DevStack documentation`_ for more information regarding DevStack.
.. _PluginModelDocs: https://docs.openstack.org/devstack/latest/plugins.html
.. _DevStack documentation: https://docs.openstack.org/devstack/latest
Quick Devstack Instructions with Datasources
============================================
Watcher requires a datasource to collect metrics from compute nodes and
instances in order to execute most strategies. To enable this two possible
examples of ``[[local|localrc]]`` to setup DevStack for some of the
supported datasources is provided. These examples specify the minimal
configuration parameters to get both Watcher and the datasource working
but can be expanded is desired.
The first example configures watcher to user prometheus as a datasource, while
the second example show how to use gnocchi as the datasource. The procedure is
equivalent, it just requires using the ``local.conf.controller`` and
``local.conf.compute`` in the first example and
``local_gnocchi.conf.controller`` and ``local_gnocchi.conf.compute`` in the
second.
Prometheus
----------
With the Prometheus datasource most of the metrics for compute nodes and
instances will work with the provided configuration but metrics that
require Ironic such as ``host_airflow and`` ``host_power`` will still be
unavailable as well as ``instance_l3_cpu_cache``
.. code-block:: ini
[[local|localrc]]
enable_plugin watcher https://opendev.org/openstack/watcher
enable_plugin watcher-dashboard https://opendev.org/openstack/watcher-dashboard
enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git
enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin devstack-plugin-prometheus https://opendev.org/openstack/devstack-plugin-prometheus
enable_plugin sg-core https://github.com/openstack-k8s-operators/sg-core main
CEILOMETER_BACKEND=sg-core
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
Gnocchi
-------
With the Gnocchi datasource most of the metrics for compute nodes and
instances will work with the provided configuration but metrics that
require Ironic such as ``host_airflow and`` ``host_power`` will still be
unavailable as well as ``instance_l3_cpu_cache``
.. code-block:: ini
[[local|localrc]]
enable_plugin watcher https://opendev.org/openstack/watcher
enable_plugin watcher-dashboard https://opendev.org/openstack/watcher-dashboard
enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git
enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin panko https://opendev.org/openstack/panko
CEILOMETER_BACKEND=gnocchi
[[post-config|$NOVA_CONF]]
[DEFAULT]
compute_monitors=cpu.virt_driver
Detailed DevStack Instructions
==============================
#. Obtain N (where N >= 1) servers (virtual machines preferred for DevStack).
One of these servers will be the controller node while the others will be
compute nodes. N is preferably >= 3 so that you have at least 2 compute
nodes, but in order to stand up the Watcher services only 1 server is
needed (i.e., no computes are needed if you want to just experiment with
the Watcher services). These servers can be VMs running on your local
machine via VirtualBox if you prefer. DevStack currently recommends that
you use Ubuntu 16.04 LTS. The servers should also have connections to the
same network such that they are all able to communicate with one another.
#. Obtain N (where N >= 1) servers (virtual machines preferred for DevStack).
One of these servers will be the controller node while the others will be
compute nodes. N is preferably >= 3 so that you have at least 2 compute
nodes, but in order to stand up the Watcher services only 1 server is
needed (i.e., no computes are needed if you want to just experiment with
the Watcher services). These servers can be VMs running on your local
machine via VirtualBox if you prefer. DevStack currently recommends that
you use Ubuntu 16.04 LTS. The servers should also have connections to the
same network such that they are all able to communicate with one another.
#. For each server, clone the DevStack repository and create the stack user
#. For each server, clone the DevStack repository and create the stack user::
.. code-block:: bash
sudo apt-get update
sudo apt-get install git
git clone https://opendev.org/openstack/devstack.git
sudo ./devstack/tools/create-stack-user.sh
sudo apt-get update
sudo apt-get install git
git clone https://git.openstack.org/openstack-dev/devstack
sudo ./devstack/tools/create-stack-user.sh
Now you have a stack user that is used to run the DevStack processes. You
may want to give your stack user a password to allow SSH via a password
may want to give your stack user a password to allow SSH via a password::
.. code-block:: bash
sudo passwd stack
sudo passwd stack
#. Switch to the stack user and clone the DevStack repo again::
#. Switch to the stack user and clone the DevStack repo again
sudo su stack
cd ~
git clone https://git.openstack.org/openstack-dev/devstack
.. code-block:: bash
sudo su stack
cd ~
git clone https://opendev.org/openstack/devstack.git
#. For each compute node, copy the provided `local.conf.compute`_
(`local_gnocchi.conf.compute`_ if deploying with gnocchi) example file
#. For each compute node, copy the provided `local.conf.compute`_ example file
to the compute node's system at ~/devstack/local.conf. Make sure the
HOST_IP and SERVICE_HOST values are changed appropriately - i.e., HOST_IP
is set to the IP address of the compute node and SERVICE_HOST is set to the
@@ -144,47 +74,29 @@ Detailed DevStack Instructions
to configure similar configuration options for the projects providing those
metrics.
#. For the controller node, copy the provided `local.conf.controller`_
(`local_gnocchi.conf.controller`_ if deploying with gnocchi) example
#. For the controller node, copy the provided `local.conf.controller`_ example
file to the controller node's system at ~/devstack/local.conf. Make sure
the HOST_IP value is changed appropriately - i.e., HOST_IP is set to the IP
address of the controller node.
.. NOTE::
if you want to use another Watcher git repository (such as a local
one), then change the enable plugin line
.. code-block:: bash
enable_plugin watcher <your_local_git_repo> [optional_branch]
Note: if you want to use another Watcher git repository (such as a local
one), then change the enable plugin line::
enable_plugin watcher <your_local_git_repo> [optional_branch]
If you do this, then the Watcher DevStack plugin will try to pull the
python-watcherclient repo from ``<your_local_git_repo>/../``, so either make
sure that is also available or specify WATCHERCLIENT_REPO in the ``local.conf``
python-watcherclient repo from <your_local_git_repo>/../, so either make
sure that is also available or specify WATCHERCLIENT_REPO in the local.conf
file.
.. NOTE::
if you want to use a specific branch, specify WATCHER_BRANCH in the
local.conf file. By default it will use the master branch.
Note: if you want to use a specific branch, specify WATCHER_BRANCH in the
local.conf file. By default it will use the master branch.
.. Note::
watcher-api will default run under apache/httpd, set the variable
WATCHER_USE_MOD_WSGI=FALSE if you do not wish to run under apache/httpd.
For development environment it is suggested to set WATHCER_USE_MOD_WSGI
to FALSE. For Production environment it is suggested to keep it at the
default TRUE value.
#. If you want to use prometheus as a datasource, you need to provide a
Prometheus configuration with the compute nodes set as targets, so
it can consume their node-exporter metrics (if you are deploying watcher
with gnocchi as datasource you can skip this step altogether). Copy the
provided `prometheus.yml`_ example file and set the appropriate hostnames
for all the compute nodes (the example configures 2 of them plus the
controller, but you should add all of them if using more than 2 compute
nodes). Set the value of ``PROMETHEUS_CONFIG_FILE`` to the path of the
file you created in the local.conf file (the sample local.conf file uses
``$DEST`` as the default value for the prometheus config path).
Note: watcher-api will default run under apache/httpd, set the variable
WATCHER_USE_MOD_WSGI=FALSE if you do not wish to run under apache/httpd.
For development environment it is suggested to set WATHCER_USE_MOD_WSGI
to FALSE. For Production environment it is suggested to keep it at the
default TRUE value.
#. Start stacking from the controller node::
@@ -192,15 +104,11 @@ Detailed DevStack Instructions
#. Start stacking on each of the compute nodes using the same command.
.. seealso::
Configure the environment for live migration via NFS. See the
`Multi-Node DevStack Environment`_ section for more details.
#. Configure the environment for live migration via NFS. See the
`Multi-Node DevStack Environment`_ section for more details.
.. _local.conf.controller: https://github.com/openstack/watcher/tree/master/devstack/local.conf.controller
.. _local.conf.compute: https://github.com/openstack/watcher/tree/master/devstack/local.conf.compute
.. _local_gnocchi.conf.controller: https://github.com/openstack/watcher/tree/master/devstack/local_gnocchi.conf.controller
.. _local_gnocchi.conf.compute: https://github.com/openstack/watcher/tree/master/devstack/local_gnocchi.conf.compute
.. _prometheus.yml: https://github.com/openstack/watcher/tree/master/devstack/prometheus.yml
Multi-Node DevStack Environment
===============================
@@ -209,19 +117,60 @@ Since deploying Watcher with only a single compute node is not very useful, a
few tips are given here for enabling a multi-node environment with live
migration.
.. NOTE::
Configuring NFS Server
----------------------
Nova supports live migration with local block storage so by default NFS
is not required and is considered an advance configuration.
The minimum requirements for live migration are:
If you would like to use live migration for shared storage, then the controller
can serve as the NFS server if needed::
- all hostnames are resolvable on each host
- all hosts have a passwordless ssh key that is trusted by the other hosts
- all hosts have a known_hosts file that lists each hosts
sudo apt-get install nfs-kernel-server
sudo mkdir -p /nfs/instances
sudo chown stack:stack /nfs/instances
If these requirements are met live migration will be possible.
Shared storage such as ceph, booting form cinder volume or nfs are recommend
when testing evacuate if you want to preserve vm data.
Add an entry to `/etc/exports` with the appropriate gateway and netmask
information::
/nfs/instances <gateway>/<netmask>(rw,fsid=0,insecure,no_subtree_check,async,no_root_squash)
Export the NFS directories::
sudo exportfs -ra
Make sure the NFS server is running::
sudo service nfs-kernel-server status
If the server is not running, then start it::
sudo service nfs-kernel-server start
Configuring NFS on Compute Node
-------------------------------
Each compute node needs to use the NFS server to hold the instance data::
sudo apt-get install rpcbind nfs-common
mkdir -p /opt/stack/data/instances
sudo mount <nfs-server-ip>:/nfs/instances /opt/stack/data/instances
If you would like to have the NFS directory automatically mounted on reboot,
then add the following to `/etc/fstab`::
<nfs-server-ip>:/nfs/instances /opt/stack/data/instances nfs auto 0 0
Edit `/etc/libvirt/libvirtd.conf` to make sure the following values are set::
listen_tls = 0
listen_tcp = 1
auth_tcp = "none"
Edit `/etc/default/libvirt-bin`::
libvirtd_opts="-d -l"
Restart the libvirt service::
sudo service libvirt-bin restart
Setting up SSH keys between compute nodes to enable live migration
------------------------------------------------------------------
@@ -250,91 +199,22 @@ must exist in every other compute node's stack user's authorized_keys file and
every compute node's public ECDSA key needs to be in every other compute
node's root user's known_hosts file.
Configuring NFS Server (ADVANCED)
---------------------------------
Disable serial console
----------------------
If you would like to use live migration for shared storage, then the controller
can serve as the NFS server if needed
Serial console needs to be disabled for live migration to work.
.. code-block:: bash
On both the controller and compute node, in /etc/nova/nova.conf
sudo apt-get install nfs-kernel-server
sudo mkdir -p /nfs/instances
sudo chown stack:stack /nfs/instances
[serial_console]
enabled = False
Add an entry to ``/etc/exports`` with the appropriate gateway and netmask
information
Alternatively, in devstack's local.conf:
[[post-config|$NOVA_CONF]]
[serial_console]
#enabled=false
.. code-block:: bash
/nfs/instances <gateway>/<netmask>(rw,fsid=0,insecure,no_subtree_check,async,no_root_squash)
Export the NFS directories
.. code-block:: bash
sudo exportfs -ra
Make sure the NFS server is running
.. code-block:: bash
sudo service nfs-kernel-server status
If the server is not running, then start it
.. code-block:: bash
sudo service nfs-kernel-server start
Configuring NFS on Compute Node (ADVANCED)
------------------------------------------
Each compute node needs to use the NFS server to hold the instance data
.. code-block:: bash
sudo apt-get install rpcbind nfs-common
mkdir -p /opt/stack/data/instances
sudo mount <nfs-server-ip>:/nfs/instances /opt/stack/data/instances
If you would like to have the NFS directory automatically mounted on reboot,
then add the following to ``/etc/fstab``
.. code-block:: bash
<nfs-server-ip>:/nfs/instances /opt/stack/data/instances nfs auto 0 0
Configuring libvirt to listen on tcp (ADVANCED)
-----------------------------------------------
.. NOTE::
By default nova will use ssh as a transport for live migration
if you have a low bandwidth connection you can use tcp instead
however this is generally not recommended.
Edit ``/etc/libvirt/libvirtd.conf`` to make sure the following values are set
.. code-block:: ini
listen_tls = 0
listen_tcp = 1
auth_tcp = "none"
Edit ``/etc/default/libvirt-bin``
.. code-block:: ini
libvirtd_opts="-d -l"
Restart the libvirt service
.. code-block:: bash
sudo service libvirt-bin restart
VNC server configuration
------------------------
@@ -342,18 +222,13 @@ VNC server configuration
The VNC server listening parameter needs to be set to any address so
that the server can accept connections from all of the compute nodes.
On both the controller and compute node, in ``/etc/nova/nova.conf``
On both the controller and compute node, in /etc/nova/nova.conf
.. code-block:: ini
vncserver_listen = 0.0.0.0
[vnc]
server_listen = "0.0.0.0"
Alternatively, in devstack's local.conf:
Alternatively, in devstack's ``local.conf``:
.. code-block:: bash
VNCSERVER_LISTEN="0.0.0.0"
VNCSERVER_LISTEN=0.0.0.0
Environment final checkup

View File

@@ -16,7 +16,7 @@ for development purposes.
To install Watcher from packaging, refer instead to Watcher `User
Documentation`_.
.. _`Git Repository`: https://opendev.org/openstack/watcher
.. _`Git Repository`: https://git.openstack.org/cgit/openstack/watcher
.. _`User Documentation`: https://docs.openstack.org/watcher/latest/
Prerequisites
@@ -43,11 +43,11 @@ different version of the above, please document your configuration here!
Getting the latest code
=======================
Make a clone of the code from our ``Git repository``:
Make a clone of the code from our `Git repository`:
.. code-block:: bash
$ git clone https://opendev.org/openstack/watcher.git
$ git clone https://git.openstack.org/openstack/watcher.git
When that is complete, you can:
@@ -72,9 +72,9 @@ These dependencies can be installed from PyPi_ using the Python tool pip_.
.. _PyPi: https://pypi.org/
.. _pip: https://pypi.org/project/pip
However, your system *may* need additional dependencies that ``pip`` (and by
However, your system *may* need additional dependencies that `pip` (and by
extension, PyPi) cannot satisfy. These dependencies should be installed
prior to using ``pip``, and the installation method may vary depending on
prior to using `pip`, and the installation method may vary depending on
your platform.
* Ubuntu 16.04::
@@ -99,7 +99,7 @@ useful to keep a clean environment for working on Watcher.
.. code-block:: bash
$ mkvirtualenv watcher
$ git clone https://opendev.org/openstack/watcher.git
$ git clone https://git.openstack.org/openstack/watcher
# Use 'python setup.py' to link Watcher into Python's site-packages
$ cd watcher && python setup.py install
@@ -141,7 +141,7 @@ forget to activate it:
$ workon watcher
You should then be able to ``import watcher`` using Python without issue:
You should then be able to `import watcher` using Python without issue:
.. code-block:: bash

View File

@@ -1,13 +1,8 @@
==================
Contribution Guide
==================
.. toctree::
:maxdepth: 2
:maxdepth: 1
contributing
environment
devstack
notifications
testing
rally_link
release-guide

View File

@@ -1,7 +1,3 @@
============
Plugin Guide
============
.. toctree::
:maxdepth: 1

View File

@@ -56,6 +56,9 @@ Here is an example showing how you can write a plugin called ``NewStrategy``:
# filepath: thirdparty/new.py
# import path: thirdparty.new
import abc
import six
from watcher._i18n import _
from watcher.decision_engine.strategy.strategies import base
@@ -242,16 +245,15 @@ Querying metrics
A large set of metrics, generated by OpenStack modules, can be used in your
strategy implementation. To collect these metrics, Watcher provides a
`DataSourceManager`_ for two data sources which are `Ceilometer`_
(with `Gnocchi`_ as API) and `Monasca`_. If you wish to query metrics from a
different data source, you can implement your own and use it via
DataSourceManager from within your new strategy. Indeed, strategies in Watcher
have the cluster data models decoupled from the data sources which means that
you may keep the former while changing the latter. The recommended way for you
to support a new data source is to implement a new helper that would
encapsulate within separate methods the queries you need to perform. To then
use it, you would just have to add it to appropriate watcher_strategies.*
section in config file.
`Helper`_ for two data sources which are `Ceilometer`_ and `Monasca`_. If you
wish to query metrics from a different data source, you can implement your own
and directly use it from within your new strategy. Indeed, strategies in
Watcher have the cluster data models decoupled from the data sources which
means that you may keep the former while changing the latter.
The recommended way for you to support a new data source is to implement a new
helper that would encapsulate within separate methods the queries you need to
perform. To then use it, you would just have to instantiate it within your
strategy.
If you want to use Ceilometer but with your own metrics database backend,
please refer to the `Ceilometer developer guide`_. The list of the available
@@ -261,45 +263,52 @@ requires new metrics not covered by Ceilometer, you can add them through a
`Ceilometer plugin`_.
.. _`DataSourceManager`: https://github.com/openstack/watcher/blob/master/watcher/datasource/manager.py
.. _`Helper`: https://github.com/openstack/watcher/blob/master/watcher/datasource/ceilometer.py
.. _`Ceilometer developer guide`: https://docs.openstack.org/ceilometer/latest/contributor/architecture.html#storing-accessing-the-data
.. _`Ceilometer`: https://docs.openstack.org/ceilometer/latest
.. _`Monasca`: https://github.com/openstack/monasca-api/blob/master/docs/monasca-api-spec.md
.. _`here`: https://docs.openstack.org/ceilometer/latest/contributor/install/dbreco.html#choosing-a-database-backend
.. _`Ceilometer plugin`: https://docs.openstack.org/ceilometer/latest/contributor/plugins.html
.. _`Ceilosca`: https://github.com/openstack/monasca-ceilometer/blob/master/ceilosca/ceilometer/storage/impl_monasca.py
.. _`Gnocchi`: https://gnocchi.xyz/
Read usage metrics using the Watcher Datasource Helper
------------------------------------------------------
The following code snippet shows how datasource_backend is defined:
The following code snippet shows how to invoke a Datasource Helper class:
.. code-block:: py
from watcher.datasource import manager as ds_manager
from watcher.datasource import ceilometer as ceil
from watcher.datasource import monasca as mon
@property
def datasource_backend(self):
if not self._datasource_backend:
def ceilometer(self):
if self._ceilometer is None:
self._ceilometer = ceil.CeilometerHelper(osc=self.osc)
return self._ceilometer
# Load the global preferred datasources order but override it
# if the strategy has a specific datasources config
datasources = CONF.watcher_datasources
if self.config.datasources:
datasources = self.config
self._datasource_backend = ds_manager.DataSourceManager(
config=datasources,
osc=self.osc
).get_backend(self.DATASOURCE_METRICS)
return self._datasource_backend
@property
def monasca(self):
if self._monasca is None:
self._monasca = mon.MonascaHelper(osc=self.osc)
return self._monasca
Using that you can now query the values for that specific metric:
.. code-block:: py
avg_meter = self.datasource_backend.statistic_aggregation(
instance.uuid, 'instance_cpu_usage', self.periods['instance'],
self.granularity,
aggregation=self.aggregation_method['instance'])
if self.config.datasource == "ceilometer":
resource_id = "%s_%s" % (node.uuid, node.hostname)
return self.ceilometer.statistic_aggregation(
resource_id=resource_id,
meter_name='compute.node.cpu.percent',
period="7200",
aggregate='avg',
)
elif self.config.datasource == "monasca":
statistics = self.monasca.statistic_aggregation(
meter_name='compute.node.cpu.percent',
dimensions=dict(hostname=node.uuid),
period=7200,
aggregate='avg'
)

View File

@@ -1,462 +0,0 @@
..
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Chronological Release Liaison Guide
====================================
This is a reference guide that a release liaison may use as an aid, if
they choose.
Watcher uses the `Distributed Project Leadership (DPL)`__ model where
traditional release liaison responsibilities are distributed among various
liaisons. The release liaison is responsible for requesting releases,
reviewing Feature Freeze Exception (FFE) requests, and coordinating
release-related activities with the team.
.. __: https://governance.openstack.org/tc/reference/distributed-project-leadership.html
How to Use This Guide
---------------------
This guide is organized chronologically to follow the OpenStack release
cycle from PTG planning through post-release activities. You can use it
in two ways:
**For New Release Liaisons**
Read through the entire guide to understand the full release cycle,
then bookmark it for reference during your term.
**For Experienced Release Liaisons**
Jump directly to the relevant section for your current phase in the
release cycle. Each major section corresponds to a specific time period.
**Key Navigation Tips**
* The :ref:`glossary` defines all acronyms and terminology used
* Time-sensitive activities are clearly marked by milestone phases
* DPL coordination notes indicate when team collaboration is required
DPL Liaison Coordination
-------------------------
Under the DPL model, the release liaison coordinates with other project
liaisons and the broader team for effective release management. The release
liaison has authority for release-specific decisions (FFE approvals, release
timing, etc.) while major process changes and strategic decisions require
team consensus.
This coordination approach ensures that:
* Release activities are properly managed by a dedicated liaison
* Team input is gathered for significant decisions
* Other liaisons are informed of release-related developments that may
affect their areas
* Release processes remain responsive while maintaining team alignment
Project Context
---------------
* Coordinate with the watcher meeting (chair rotates each meeting, with
volunteers requested at the end of each meeting)
* Meeting etherpad: https://etherpad.opendev.org/p/openstack-watcher-irc-meeting
* IRC channel: #openstack-watcher
* Get acquainted with the release schedule
* Example: https://releases.openstack.org/<current-release>/schedule.html
* Familiarize with Watcher project repositories and tracking:
Watcher Main Repository
`Primary codebase for the Watcher service <https://opendev.org/openstack/watcher>`__
Watcher Dashboard
`Horizon plugin for Watcher UI <https://opendev.org/openstack/watcher-dashboard>`__
Watcher Tempest Plugin
`Integration tests <https://opendev.org/openstack/watcher-tempest-plugin>`__ (follows tempest cycle)
Python Watcher Client
`Command-line client and Python library <https://opendev.org/openstack/python-watcherclient>`__
Watcher Specifications
`Design specifications <https://opendev.org/openstack/watcher-specs>`__ (not released)
Watcher Launchpad (Main)
`Primary bug and feature tracking <https://launchpad.net/watcher>`__
Watcher Dashboard Launchpad
`Dashboard-specific tracking <https://launchpad.net/watcher-dashboard/>`__
Watcher Tempest Plugin Launchpad
`Test plugin tracking <https://launchpad.net/watcher-tempest-plugin>`__
Python Watcher Client Launchpad
`Client library tracking <https://launchpad.net/python-watcherclient>`__
Project Team Gathering
----------------------
Event Liaison Coordination
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Work with the project team to select an event liaison for PTG coordination.
The event liaison is responsible for:
* Reserving sufficient space at PTG for the project team's meetings
* Putting out an agenda for team meetings
* Ensuring meetings are organized and facilitated
* Documenting meeting results
* If no event liaison is selected, these duties revert to the release liaison.
* Monitor for OpenStack Events team queries on the mailing list requesting
event liaison volunteers - teams not responding may lose event
representation.
PTG Planning and Execution
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Create PTG planning etherpad, retrospective etherpad and alert about it in
watcher meeting and dev mailing list
* Example: https://etherpad.opendev.org/p/apr2025-ptg-watcher
* Run sessions at the PTG (if no event liaison is selected)
* Do a retro of the previous cycle
* Coordinate with team to establish agreement on the agenda for this release:
Review Days Planning
Determine number of review days allocated for specs and implementation work
Freeze Dates Coordination
Define Spec approval and Feature freeze dates through team collaboration
Release Schedule Modifications
Modify the OpenStack release schedule if needed by proposing new dates
(Example: https://review.opendev.org/c/openstack/releases/+/877094)
* Discuss the implications of the `SLURP or non-SLURP`__ current release
.. __: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
* Sign up for group photo at the PTG (if applicable)
After PTG
---------
* Send PTG session summaries to the dev mailing list
* Add `RFE bugs`__ if you have action items that are simple to do but
without a owner yet.
* Update IRC #openstack-watcher channel topic to point to new
development-planning etherpad.
.. __: https://bugs.launchpad.net/watcher/+bugs?field.tag=rfe
A few weeks before milestone 1
------------------------------
* Plan a spec review day
* Periodically check the series goals others have proposed in the “Set series
goals” link:
* Example: https://blueprints.launchpad.net/watcher/<current-release>/+setgoals
Milestone 1
-----------
* Release watcher and python-watcherclient via the openstack/releases repo.
Watcher follows the `cycle-with-intermediary`__ release model:
.. __: https://releases.openstack.org/reference/release_models.html#cycle-with-intermediary
* Create actual releases (not just launchpad bookkeeping) at milestone points
* No launchpad milestone releases are created for intermediary releases
* When releasing the first version of a library for the cycle,
bump
the minor version to leave room for future stable branch
releases
* Release stable branches of watcher
Stable Branch Release Process
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prepare the stable branch for evaluation:
.. code-block:: bash
git checkout <stable branch>
git log --no-merges <last tag>..
Analyze commits to determine version bump according to semantic versioning.
Semantic Versioning Guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Choose version bump based on changes since last release:
Major Version (X)
Backward-incompatible changes that break existing APIs
Minor Version (Y)
New features that maintain backward compatibility
Patch Version (Z)
Bug fixes that maintain backward compatibility
Release Command Usage
~~~~~~~~~~~~~~~~~~~~~
Generate the release using OpenStack tooling:
* Use the `new-release command
<https://releases.openstack.org/reference/using.html#using-new-release-command>`__
* Propose the release with version according to chosen semver format
(x.y.z)
Summit
------
``Responsibility Precedence for Summit Activities:``
1. ``Project Update/Onboarding Liaisons`` (if appointed):
* ``Project Update Liaison``: responsible for giving the project update
showcasing team's achievements for the cycle to the community
* ``Project Onboarding Liaison``: responsible for giving/facilitating
onboarding sessions during events for the project's community
2. ``Event Liaison`` (if no Project Update/Onboarding liaisons exist):
* Coordinates all Summit activities including project updates and onboarding
3. ``Release Liaison`` (if no Event Liaison is appointed):
* Work with the team to ensure Summit activities are properly handled:
* Prepare the project update presentation
* Prepare the on-boarding session materials
* Prepare the operator meet-and-greet session
.. note::
The team can choose to not have a Summit presence if desired.
A few weeks before milestone 2
------------------------------
* Plan a spec review day (optional)
Milestone 2
-----------
* Spec freeze (unless changed by team agreement at PTG)
* Release watcher and python-watcherclient (if needed)
* Stable branch releases of watcher
Shortly after spec freeze
-------------------------
* Create a blueprint status etherpad to help track, especially non-priority
blueprint work, to help things get done by Feature Freeze (FF). Example:
* https://etherpad.opendev.org/p/watcher-<release>-blueprint-status
* Create or review a patch to add the next releases specs directory so people
can propose specs for next release after spec freeze for current release
Milestone 3
-----------
* Feature freeze day
* Client library freeze, release python-watcherclient
* Close out all blueprints, including “catch all” blueprints like mox,
versioned notifications
* Stable branch releases of watcher
* Start writing the `cycle highlights
<https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights>`__
Week following milestone 3
--------------------------
* If warranted, announce the FFE (feature freeze exception process) to
have people propose FFE requests to a special etherpad where they will
be reviewed.
FFE requests should first be discussed in the IRC meeting with the
requester present.
The release liaison has final decision on granting exceptions.
.. note::
if there is only a short time between FF and RC1 (lately its been 2
weeks), then the only likely candidates will be low-risk things that are
almost done. In general Feature Freeze exceptions should not be granted,
instead features should be deferred and reproposed for the next
development
cycle. FFE never extend beyond RC1.
* Mark the max microversion for the release in the
:doc:`/contributor/api_microversion_history`
A few weeks before RC
---------------------
* Update the release status etherpad with RC1 todos and keep track
of them in meetings
* Go through the bug list and identify any rc-potential bugs and tag them
RC
--
* Follow the standard OpenStack release checklist process
* If we want to drop backward-compat RPC code, we have to do a major RPC
version bump and coordinate it just before the major release:
* https://wiki.openstack.org/wiki/RpcMajorVersionUpdates
* Example: https://review.opendev.org/541035
* “Merge latest translations" means translation patches
* Check for translations with:
* https://review.opendev.org/#/q/status:open+project:openstack/watcher+branch:master+topic:zanata/translations
* Should NOT plan to have more than one RC if possible. RC2 should only happen
if there was a mistake and something was missed for RC, or a new regression
was discovered
* Write the reno prelude for the release GA
* Example: https://review.opendev.org/644412
* Push the cycle-highlights in marketing-friendly sentences and propose to the
openstack/releases repo. Usually based on reno prelude but made more readable
and friendly
* Example: https://review.opendev.org/644697
Immediately after RC
--------------------
* Look for bot proposed changes to reno and stable/<cycle>
* Create the launchpad series for the next cycle
* Set the development focus of the project to the new cycle series
* Set the status of the new series to “active development”
* Set the last series status to “current stable branch release”
* Set the previous to last series status to “supported”
* Repeat launchpad steps ^ for all watcher deliverables.
* Make sure the specs directory for the next cycle gets created so people can
start proposing new specs
* Make sure to move implemented specs from the previous release
* Move implemented specs manually (TODO: add tox command in future)
* Remove template files:
.. code-block:: bash
rm doc/source/specs/<release>/index.rst
rm doc/source/specs/<release>/template.rst
* Ensure liaison handoff: either transition to new release liaison or confirm
reappointment for next cycle
.. _glossary:
Glossary
--------
DPL
Distributed Project Leadership - A governance model where traditional PTL
responsibilities are distributed among various specialized liaisons.
FFE
Feature Freeze Exception - A request to add a feature after the feature
freeze deadline. Should be used sparingly for low-risk, nearly
complete features.
GA
General Availability - The final release of a software version for
production use.
PTG
Project Team Gathering - A collaborative event where OpenStack project
teams meet to plan and coordinate development activities.
RC
Release Candidate - A pre-release version that is potentially the final
version, pending testing and bug fixes.
RFE
Request for Enhancement - A type of bug report requesting a new feature
or enhancement to existing functionality.
SLURP
Skip Level Upgrade Release Process - An extended maintenance release
that allows skipping intermediate versions during upgrades.
Summit
OpenStack Summit - A conference where the OpenStack community gathers
for presentations, discussions, and project updates.
Miscellaneous Notes
-------------------
How to track launchpad blueprint approvals
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Core team approves blueprints through team consensus. The release liaison
ensures launchpad status is updated correctly after core team approval:
* Set the approver as the core team member who approved the spec
* Set the Direction => Approved and Definition => Approved and make sure the
Series goal is set to the current release. If code is already proposed, set
Implementation => Needs Code Review
* Optional: add a comment to the Whiteboard explaining the approval,
with a date
(launchpad does not record approval dates). For example: “We discussed this
in the team meeting and agreed to approve this for <release>. -- <nick>
<YYYYMMDD>”
How to complete a launchpad blueprint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Set Implementation => Implemented. The completion date will be recorded by
launchpad

Some files were not shown because too many files have changed in this diff Show More