* sync charm-helpers to classic charms
* change openstack-origin/source default to zed
* align testing with zed
* add new zed bundles
* add zed bundles to tests.yaml
* add zed tests to osci.yaml and .zuul.yaml
* update build-on and run-on bases
* add bindep.txt for py310
* sync tox.ini and requirements.txt for ruamel
* use charmcraft_channel 2.0/stable
* drop reactive plugin overrides
* move interface/layer env vars to charmcraft.yaml
Change-Id: Ida68ffdab34c3136f3acf98629e4be6fda3bcea2
- Add 22.04 to charmcraft.yaml
- Update metadata to include jammy
- Remove impish from metadata
- Update osci.yaml to include py3.10 default job
- Modify tox.ini to remove py35,py36,py37 tox target and add py310
target.
- ensure that the openstack-origin is yoga
- charmhelpers sync
func-test-pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/747
Change-Id: I8bd5e6f5d002fbd1118f2c7fa54e50f1b31fc722
The neutron-gateway uses the firewall driver just as other nodes
do when running neutron-openvswitch-agent. It is currently
hardcoded to the deprecated iptables_hybrid driver. This patch
allows the driver to be changed to openvswitch same as with the
neutron-openvswitch driver with a firewall-driver config option
that defaults to iptables_hybrid so as to maintain backwards
compatibility.
Change-Id: I4f5482425c91b5ad556c384abba7c27137c1948f
VRRP healthchecks were enabled by default starting in the 19.07 charm
release for network deployments which utilize l3ha or dvr+snat. The VRRP
healthchecks have specific expectations that may not be satisfied in
various data centers. This leads to problems with networks as failed
healthchecks lead to router failovers.
This change alters the default config option to disable the vrrp
healthchecks by default and require users to opt in to using them. The
description around the option has been updated to indicate that doing so
may lead to routers failing over if ICMP pings are missed.
Closes-Bug: #192101
Change-Id: Ie0ebb8072fa802dc8c2478a0b3ca38202d49c85f
Update docs to clarify that manual removing of previous
values are required if the config changes.
Change-Id: Ia13b5e2a9b38a8a9e4e2d6cb38d308a114c3cbc2
Related-bug: #1915967
This patchset updates the configure_ovs() function in
hooks/neutron_utils.py such that ports and bridges in OVS are marked as
being managed by this charm. This will allow us to clean up obsolete
managed bridges and ports in a later patchset. (On configuration change
new ports and bridges might be created and former ones might become
obsolete.)
This patchset also fully deprecates the 'ext-port' config option such
that if both 'data-port' and 'ext-port' config options are set, the unit
is blocked. The README and config.yaml are updated to reflect this
change.
This patchset also fixes and removes a few dead links.
Relies on a charm-helpers version containing these patchsets:
https://github.com/juju/charm-helpers/pull/443https://github.com/juju/charm-helpers/pull/447https://github.com/juju/charm-helpers/pull/449
Related documentation:
* Deployment guide / Upgrades / Known issues: https://review.opendev.org/630290
* Release notes: https://review.opendev.org/742660
Change-Id: I8b459135d131e16865de40ff3eae16ea3bc7195e
Partial-Bug: #1809190
Defaults to 30s (i.e. enabled) but also allows disabling
healthchecks by setting to 0.
Change-Id: I49603c22d8085aabd6085058e4d4eb9c74e84a20
Closes-Bug: #1890900
The nf_conntrack module is not loaded early enough on boot,
thus when sysctl options are applied, its settings are not.
This results in the correct sysctl settings seen on deploy
time (because nf_conntrack was loaded previously by others)
but not after reboot, despite configured in /etc/sysctl.d/.
So, insert it in /etc/modules for module auto-load on boot
(available on Trusty via /etc/init/kmod.conf, then Xenial+
via systemd-sysctl.service).
Since users can configure the sysctl option and thus need
more modules, introduce the config option 'kernel-modules'
(with 'nf_conntrack' as default.)
It's handled before sysctl in the config-changed hook in
case some sysctl option(s) needs not yet loaded module(s).
In case of failure to load modules, log a warning message.
Closes-Bug: #1885192
Change-Id: I661a4fe2d9284455e536b073dc93696355baf122
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
Since Rocky, Octavia is a valid alternative as LBaaS.
If enabled, we should not configure Neutron LBaaS(v2)
agent at the same time.
The fact that we configure both means neutron-lbaas-agent
will generate messages on rabbitmq which never gets consumed
and creating alarms on NRPE without any actual issues.
This change introduces an option to disable neutron LBaaS
solution. Once activated, it masks lbaas agent service.
Change-Id: I10c4cc2983245efb5bef3d7cbc8e3b6963448a7d
Closes-Bug: #1825906
ovsdb-timeout sets ovsdb_timeout in openvswitch_agent.ini, this option
is used to determine when ovsdb commands should be marked as fail. This
is helpful for large clouds or where the node is under pressure.
Change-Id: I0b0e397691c49d3fcebdd30bbe9b160789acf3c3
Closes-Bug: #1849732
Enable support for configuration of FWaaS v2 firewall group
logging.
Configuration options mirror those for neutron-openvswitch
for security group logging.
This feature is currently only enabled for FWaaS v2 at Stein
for the charms (but is supported back to Queens in Neutron).
Change-Id: If1b332eb0f581e9acba111f79ba578a0b7081dd2
Partial-Bug: 1831972
When clouds have a large number of hosts, the default size of the ARP
cache is too small. The cache can overflow, which means that the
system has no way to reach some ip addresses.
Setting the threshold limits higher addresses the situation, in a
reasonably safe way (the maximum impact is 5MB or so of additional RAM
used). Docs on ARP at http://man7.org/linux/man-pages/man7/arp.7.html,
and more discussion of the issue in the bug.
Change-Id: I701141784224f5f870f6da73a24bed8015694409
Closes-Bug: 1780348
The change adds an option to the charm to use JUJU_AVAILABILITY_ZONE
environment variable set by Juju for the hook environment based on the
underlying provider's availability zone information for a given machine.
This information is used to configure the availability_zone setting for
Neutron DHCP and L3 agents specifically because they support it
and for other agents (because both neutron.conf and agent-specific
configuration files are loaded) such as metadata agents and lbaas
agents.
Additionally, a setting is added to allow changing the default
availability zone because 'nova' is a default value coming from the
Neutron defaults for agents.
Change-Id: I94303aa70ee3adc6ace0f9af1e7c4f5c0edbcdb5
Closes-Bug: #1796068
The change turns off the local nova metadata service and uses
endpoint data recieved from the quantum-network-service relation
to point the neutron metadata service at the nova metadata service
on the nova cloud controller for Queens+.
Depends-On: I5ad15ba782cb87b6fdb3c0941a6482d201670bff
Change-Id: I7037a20feac73f3a3f1ed1b8b1b70d0fa534bc46
Using vendor metadata helps alleviate the need to spin custom images
for things like package mirrors, timezones, or network proxies.
Adds new config option 'vendor-data' which takes a JSON formated
string to be used as static vendor metadata.
Adds new config option 'vendor-data-url' which takes a URL which
serves dynamic JSON formatted vendor metadata.
Adds new NovaMetadataContext class which writes
/etc/nova/vendor_data.json and enables it via nova.conf.
Closes-Bug: 1777714
Change-Id: I1d70804e59d42b0651a462c81e01d9c95626f27d
Adds a config option and calls to enable IPFIX exporting on all OVS
bridges created on a system by the NGW charm.
Closes-Bug: 1768016
Change-Id: I8db6577037d81c4b4bc4720026a57f02585d9770
Drop support for deployment from Git repositories, as deprecated
in the 17.02 charm release. This feature is unmaintained and has
no known users.
Change-Id: I0abe07721bedfd8b80c7c590bc646abfc822bbfa
Adds a dns-servers config option for specifying the forwarding
dns servers to be used by the dnsmasq services on the neutron
dhcp agent. This enables services using internal dns to also
specify the forwarding dns servers in order to resolve hosts
outside of the neutron network space.
Change-Id: I3cd608b1491a45f565d5147894b8285e638eeaa7
Implements: blueprint internal-dns
Closes-Bug: #1713721
Resync charm-helpers to pickup the capped worker-multiplier
changes when deploying in containers.
Drop the default value for worker-multiplier of 2.0; this
is now handled from within the codebase rather than via a
default configuration value, reflecting the differing
behaviours between container and non-container deployments.
Change-Id: Idb10dc73b357cc3ed774365bae92962b8dfd0bfb
Closes-Bug: 1665270
Expose the 'enable_metadata_network' and 'enable_isolated_metadata'
configuration options. enable_isolated_metadata enables metadata the
metadata service on networks with no router port.
Change-Id: If773109007a456385adebf295d044247417135db
Closes-Bug: 1514901
- Remove Precise-Icehouse Amulet test definitions if they exist.
- Add Xenial-Newton Amulet test definitions.
- Add Yakkety-Newton Amulet test definitions.
- Use the percona-cluster charm in tests instead of the mysql charm.
Change-Id: I69b4e3c38b7b24c4ef93010e5612faf377d7a67a
Add support for application of apparmor profiles to
neutron and nova daemons that run on neutron-gateway
units.
By default this is disabled but may be enabled by setting
the aa-profile-mode option to ether 'complain' or 'enforce'.
Note that the apparmor profiles do not try to reproduce the
permissions required for all operations that may be undertaken
using oslo.rootwrap; daemons are granted permission to run
'sudo' without any apparmor based restrictions.
Change-Id: Ibe568a46ee4c1f1148c162f0f0b2907153770efe
Charm was missing this functionality and this patch is to add
this feature. We were trying to deploy this charm on bare metal
host machine with 72 cores. In end up creating 144 processes for
nova-metadata-api, and neutron.
This patch will provide the option to limit the number of worker
process in case of high number of cores in a host.
Enable it for icehouse, kilo, liberty and mitaka.
Partial-Bug: 1600482
Change-Id: Iedcbe6c53746a203937b78dd00e83fda7681bd8f
* openstack-origin is no longer required when using openstack-origin-git.
* Drop kilo from openstack-origin-git default values because upper
constraints doesn't work in kilo for openstack-dashboard and glance.
* Add flag to allow for disabling upper constraints when using
openstack-origin-git with user-specified git repositories.
Change-Id: I37a1cc5f767cbc4d035ee534437ff66ca7100751
openstack-origin-git currently only supports YAML that specifies
the git repositories to deploy from.
This adds support for default openstack-origin-git values. The
default values supported are: icehouse, kilo, liberty, mitaka,
and master. For example: openstack-origin-git=master.
Change-Id: Ib2e0224f70e51d2686b6bb1f28e6ad528621eafb
Switch the generated configuration to use "new" style external
networks when ext-port is not set. In this case we configure
external_network_bridge = (intentionally blank),
gateway_external_network_id = (blank) and update the README with
information on using this new style of configuration.
The current template configures external networks by using the default
external_network_bridge=br-ex (implied when not set). This activates
legacy code which assumes that a single external network exists on
that bridge and the L3 Agent directly plugs itself in.
provider:network_type, provider:physical_network and
provider:segmentation_id are ignored. You cannot create multiple
networks and you cannot use segmented networks (e.g. VLAN)
By setting external_network_bridge = (intentionally blank) the L2
Agent handles the configuration instead, this allows us to create
multiple networks and also to use more complex network configurations
such as VLAN. It is also possible to use the same physical connection
with different segmentation IDs for both internal and external
networks, as well as multiple external networks.
Legacy/existing configurations where ext-port is set generate the same
configuration as previous and should continue to work as before. I do
not believe it to be easy to migrate existing setups to the "new"
style configuration automatically as changes to the neutron network
configuration may be required (specifically: provider:physical_network
will now be used when it was not before, and may not be correct) and
the physical port needs to be moved from br-ex to br-data which the
charm does not currently handle and is likely to error as it does not
attempt removal first. Further work may be possible in this area.
For information about this new style of configuration being preferred,
see discussions in LP#1491668, LP#1525059 and
http://docs.openstack.org/liberty/networking-guide/scenario-classic-ovs.html
Change-Id: I8d2bb8098e080969e0445293b1ed79714b2c964f
Related-Bug: #1491668
Related-Bug: #1525059
Closes-Bug: #1536768
Add charmhelpers.contrib.hardening and calls to install,
config-changed, upgrade-charm and update-status hooks.
Also add new config option to allow one or more hardening
modules to be applied at runtime.
Change-Id: I0f3035c8f8feae90ad3572297fab0ac28e7d97e2
Includes dropping support for quantum, nvp plugin (renamed
nsx long ago) and generally refactoring the unit tests
around no longer having to deal with neutron and quantum in
the same codebase.
Drop support for database connections - these are no longer
required as all DB access is now via RPC to nova-conductor
or neutron-server.
Roll-up configuration file templates < icehouse, remove any
that are no longer required.
Refactor basic_deployment a bit as it was using the shared-db
relation to retrieve the n-gateway units private-address.
Change-Id: I22957c0e21c4dd49e5aa74795173b4fc8f043f55
Corey Bryant