Health_probe for neutron pods accomplish both liveness and
readiness probe.
Neutron DHCP/L3/OVS agents:
Sends an RPC call with a non-existence method to agent’s queue.
Assumes no other agent subscribed to tunnel-update queue other
than OVS. Probe is success if agent returns with NoSuchMethod
error.
Neutron Metadata agent:
Sends a message to Unix Domain Socket opened by Metadata agent.
Probe is success if agent returns with HTTP status 404.
In both the cases, if agent is not reachable or fails to
respond in time, returns failure to probe.
Readiness probe for Neutron L3/DHCP/Metadata/SRIOV agents
Following are the operations executed on the pod as part of
readiness probe on the neutron agents:
- Check if the agent process is up and running.
- Retrieve the sockets associated with the process from the /proc fs.
- Check the status of tcp sockets related to Rabbitmq communication.
- Check the reachability of the rabbitmq message bus from the agent.
- For SRIOV Agent, check if VFs are configured properly for the
configured NICs in sriov_agent.ini conf file
Change-Id: Ib99ceaabbad1d1e0faf34cc74314da9aa688fa0a
Health probe for Nova pods is used for both liveness
and readiness probe.
nova-compute, nova-conductor, nova-consoleauth and nova-scheduler:
Check if the rpc socket status on the nova pods to rabbitmq and
database are in established state.
sends an RPC call with a non-existence method to component's queue.
Probe is success if agent returns with NoSuchMethod error.
If agent is not reachable or fails to respond in time,
returns failure to probe.
novnc/spice proxy: uses Kubernetes tcp probe on corresponding ports
they expose.
Added code to catch nova config file not present exception.
Change-Id: Ib8e4b93486588320fd2d562c3bc90b65844e52e5
Currently, ceilometer is not listening to the notifications which
sent from the openstack services as the messaging_urls isn't configured
properly. The commit updates the messaging_urls with the correct type
and the default value.
The configuration for the cache server is also added. With the cache
server configured, ceilometer will not update the resource metadata
through gnocchi client if the resource is not changed.
Change-Id: I77e5acf3da31e211c444032f26d7625e51d8b0a9
Story: 2005019
Task: 29746
Signed-off-by: Angie Wang <angie.wang@windriver.com>
- pass new pool replication&crush ruleset parameter to the
storage init script
- set images pool replication&crush ruleset in the storage init script
Change-Id: Idd883d4348a292c0de54c7ee47da98f11f36306f
Story: 2004921
Task: 29282
Signed-off-by: Irina Mihai <irina.mihai@windriver.com>
This commit adds the ability to deploy a polling process with ipmi
functionality to pull ipmi samples.
Story: 2005019
Task: 29819
Signed-off-by: Angie Wang <angie.wang@windriver.com>
Change-Id: Ib61d65f9ab815faa0d750422ffb0e36406dd3ccd
During the Stein development cycle, Cinder removed the deprecated
query_volume_filters configuration option with
Icd311db7f88c3c274d9a362eb96519e46c7e4d17.
This chart update will add resource_filters.json to the configmap and
provides the default values for the filter keys to enable filtering in
the list APIs.
Change-Id: I31263e9ce06d31773e961ae5d1252e062a38a4e5
Signed-off-by: Robert Church <robert.church@windriver.com>
This commit adds two missing definition files which are
meters.yaml and polling.yaml.
meters.yaml is the meter definition file that used for
ceilometer notification agent to convert meters.
polling.yaml is the polling definition file that used for
ceilometer polling agents to pull meters.
Change-Id: I6b9b7543aa1a77661d6a86166af59fde85085513
Story: 2005019
Task: 29811
Signed-off-by: Angie Wang <angie.wang@windriver.com>
Upgrade the default images from newton to ocata and update
the following configuration files to align with ocata.
event_definitions.yaml
pipeline.yaml
policy.json
api_paste.ini
Story: 2005019
Task: 29773
Change-Id: Ib0ba502215aa0fe959606f15dacf39e2cdd06fe6
Signed-off-by: Angie Wang <angie.wang@windriver.com>
The current ceilometer upgrade command "ceilometer-dbsync" was
deprecated since newton and was removed since ocata. The commit
updates to use the replaced command.
Story: 2005019
Task: 29727
Change-Id: I06afb2cc99726991d6941aabb039379dc78c5d66
Signed-off-by: Angie Wang <angie.wang@windriver.com>
To use RBD devices with CentOS system, multinode deployment script has
already been modifed.
Change-Id: I8a1ac13b0ec124b14b2bdd06ea3b0a9c081d468c
Story:2004640
Task:28577
.Values.network.auto_bridge_add is a global config. So in multi nodes
deployment, it requires that all hosts have the same nic names. This is
a strict limit.
This patch is to support per-host auto_bridge_add, so that we can define
different auto_bridge_add for hosts.
Also, this patch move .network.auto_bridge_add to .conf.auto_bridge_add
Change-Id: I4a4d6efbbfe073d035bc5c03700fbe998e708d0f
Story: 2005059
Task: 29601
Specs are not ordered currently, and every rst file inside the
specs folder is included in the TOC tree, but manually.
This is a problem as:
- the current readability of the specs was reduced due to inclusion
of non-specs files
- the process of writing a spec was more tedious, due to the
update of the specs/index.rst.
This fixes it by removing the extra files included by mistake in
the middle of the specs (the template for spec writing, and
the specs purpose/process), and automatically load all the
remaining files using a glob.
The content of the files removed is not lost: The template was
simply renamed COPYME to clearly state a spec writer should
copy the file (and will understand it needs to be named .rst)
with the other files present. The specs process/purpose is
now part of the main page of specs, which therefore doesn't need
extra including.
Change-Id: I8aa15c8a8f2d8b3ffb764c3fb2411eb27477d0b6
This changes the gate check for bandit to only run when either python
or templated python files are edited. This will cause the check
to only be ran when those specific file types are edited, and to
skip the check when not needed.
Change-Id: I149ef6827ca10e32492f2b05beb8a13af5a03fc5
The current helm chart defaults drops logs of any warnings
(and above) for any logger outside of the namespace
of the deployed chart.
This is a problem, as logging could reveal important information for
operators. While this could be done with a value override, there
is no reason to hide warning, errors, or critical information that
are happening in the cycle of the operation of the software
deployed with the helm charts. For example, nothing would get
logged in oslo_service, which is a very important part of running
OpenStack.
This fixes it by logging to stdout all the warnings (and above)
for OpenStack apps.
Change-Id: I16f77f4cc64caf21b21c8519e6da34eaf5d31498
Adding this parameter to Cinder, Heat, Glance,and Neutron
config. Adding this parameter allows proper handling to resource
links in response using API services behind https proxy.
Change-Id: Ib99a16b6252b15d9f138417485731ec401cb8f81
the defaults in Python [0] and oslo.log [1] are such that when using
separate config file for logging configuration (log-config-append)
the log fomat of dates containes miliseconds twice (as in sec,ms.ms)
which is exactly what is currently seen in logs of OpenStack services
deployed by openstack-helm.
When not provided with datefmt log formatter option, Python effectively
uses '%Y-%m-%d %H:%M:%S,%f' [0] as a default time formatting string to
render `%(asctime)s`, but the defaults in oslo.log add another `.%f`
to it [1].
Since `log-date-format` oslo.log option has no effect when using
log-config-append, we need to explicitly set date format to avoid double
miliseconds rendering in date of log entries.
[0] 6ee41793d2/Lib/logging/__init__.py (L427-L428)
[1] http://git.openstack.org/cgit/openstack/oslo.log/tree/oslo_log/_options.py?id=7c5f8362b26313217b6c248e77be3dc8e2ef74a5#n148
Change-Id: I47aa7ce96770d94b905b56d6fe4abad428f01047
This patch set adds "startingDeadlineSeconds" field to cronJobs.
When the field is not set, the controller counts how many missed
jobs occured from the last scheduled time till now. And if it happends
more than 100 time the job will not be scheduled. To avoid this
the "startingDeadlineSeconds" field should be set to sufficient period
of time. In this case the controller counts how many missed jobs occured
during this period of time. The value of the field should be less than
time (in seconds) needed for running >100 jobs (according to schedule).
Change-Id: I3bf7c7077b55ca5a3421052bd0b59b70c9bbcf24
