{"id":20111290,"url":"https://github.com/openstack/charm-neutron-openvswitch","last_synced_at":"2025-11-08T05:03:17.995Z","repository":{"id":48277407,"uuid":"52858841","full_name":"openstack/charm-neutron-openvswitch","owner":"openstack","description":"Juju Charm - Neutron Open vSwitch. Mirror of code maintained at opendev.org.","archived":false,"fork":false,"pushed_at":"2024-10-16T15:38:12.000Z","size":2370,"stargazers_count":13,"open_issues_count":0,"forks_count":23,"subscribers_count":7,"default_branch":"master","last_synced_at":"2024-10-18T13:34:25.051Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://opendev.org/openstack/charm-neutron-openvswitch","language":"Python","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openstack.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-03-01T07:55:53.000Z","updated_at":"2024-10-16T15:38:16.000Z","dependencies_parsed_at":"2023-11-07T09:30:35.136Z","dependency_job_id":"921246ff-ae3f-4ed4-a727-c87fb8b6deb7","html_url":"https://github.com/openstack/charm-neutron-openvswitch","commit_stats":null,"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack%2Fcharm-neutron-openvswitch","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack%2Fcharm-neutron-openvswitch/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack%2Fcharm-neutron-openvswitch/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack%2Fcharm-neutron-openvswitch/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openstack","download_url":"https://codeload.github.com/openstack/charm-neutron-openvswitch/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":224499855,"owners_count":17321605,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-13T18:15:15.094Z","updated_at":"2025-11-08T05:03:17.935Z","avatar_url":"https://github.com/openstack.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Overview\n\nThis subordinate charm provides the Neutron OpenvSwitch configuration for a compute node.\n\nOnce deployed it takes over the management of the Neutron base and plugin configuration on the compute node.\n\n# Usage\n\nTo deploy (partial deployment of linked charms only):\n\n    juju deploy rabbitmq-server\n    juju deploy neutron-api\n    juju deploy nova-compute\n    juju deploy neutron-openvswitch\n    juju add-relation neutron-openvswitch nova-compute\n    juju add-relation neutron-openvswitch neutron-api\n    juju add-relation neutron-openvswitch rabbitmq-server\n\nNote that the rabbitmq-server can optionally be a different instance of the rabbitmq-server charm than used by OpenStack Nova:\n\n    juju deploy rabbitmq-server rmq-neutron\n    juju add-relation neutron-openvswitch rmq-neutron\n    juju add-relation neutron-api rmq-neutron\n\nThe neutron-api and neutron-openvswitch charms must be related to the same instance of the rabbitmq-server charm.\n\n# Restrictions\n\nIt should only be used with OpenStack Icehouse and above and requires a separate neutron-api service to have been deployed.\n\n# Disabling security group management\n\nWARNING: this feature allows you to effectively disable security on your cloud!\n\nThis charm has a configuration option to allow users to disable any per-instance security group management; this must used with neutron-security-groups enabled in the neutron-api charm and could be used to turn off security on selected set of compute nodes:\n\n    juju deploy neutron-openvswitch neutron-openvswitch-insecure\n    juju config neutron-openvswitch-insecure disable-security-groups=True prevent-arp-spoofing=False\n    juju deploy nova-compute nova-compute-insecure\n    juju add-relation nova-compute-insecure neutron-openvswitch-insecure\n    ...\n\nThese compute nodes could then be accessed by cloud users via use of host aggregates with specific flavors to target instances to hypervisors with no per-instance security.\n\n# Network Spaces support\n\nThis charm supports the use of Juju Network Spaces, allowing the charm to be bound to network space configurations managed directly by Juju.  This is only supported with Juju 2.0 and above.\n\nOpen vSwitch endpoints can be configured using the 'data' extra-binding, ensuring that tunnel traffic is routed across the correct host network interfaces:\n\n    juju deploy neutron-openvswitch --bind \"data=data-space\"\n\nalternatively these can also be provided as part of a juju native bundle configuration:\n\n    neutron-openvswitch:\n      charm: cs:xenial/neutron-openvswitch\n      bindings:\n        data: data-space\n\nNOTE: Spaces must be configured in the underlying provider prior to attempting to use them.\n\nNOTE: Existing deployments using os-data-network configuration options will continue to function; this option is preferred over any network space binding provided if set.\n\n# DPDK fast packet processing support\n\nFor OpenStack Mitaka running on Ubuntu 16.04, it's possible to use experimental DPDK userspace network acceleration with Open vSwitch and OpenStack.\n\nCurrently, this charm supports use of DPDK enabled devices in bridges supporting connectivity to provider networks.\n\nTo use DPDK, you'll need to have supported network cards in your server infrastructure (see [dpdk-nics][DPDK documentation]);  DPDK must be enabled and configured during deployment of the charm, for example:\n\n    neutron-openvswitch:\n        enable-dpdk: True\n        data-port: \"br-phynet1:a8:9d:21:cf:93:fc br-phynet2:a8:9d:21:cf:93:fd br-phynet3:a8:9d:21:cf:93:fe\"\n\nAs devices are not typically named consistently across servers, multiple instances of each bridge -\u003e mac address mapping can be provided; the charm deals with resolution of the set of bridge -\u003e port mappings that are required for each individual unit of the charm.\n\nDPDK requires the use of hugepages, which is not directly configured in the neutron-openvswitch charm; Hugepage configuration can either be done by providing kernel boot command line options for individual servers using MAAS or using the 'hugepages' configuration option of the nova-compute charm:\n\n    nova-compute:\n        hugepages: 50%\n\nBy default, the charm will configure Open vSwitch/DPDK to consume a processor core + 1G of RAM from each NUMA node on the unit being deployed; this can be tuned using the dpdk-socket-memory and dpdk-socket-cores configuration options of the charm.  The userspace kernel driver can be configured using the dpdk-driver option.  See config.yaml for more details.\n\n**NOTE:** Changing dpdk-socket-\\* configuration options will trigger a restart of Open vSwitch, which currently causes connectivity to running instances to be lost - connectivity can only be restored with a stop/start of each instance.\n\n**NOTE:** Enabling DPDK support automatically disables security groups for instances.\n\n[dpdk-nics]: http://dpdk.org/doc/nics\n\n# DPDK bonding\n\nFor deployments using Open vSwitch 2.6.0 or later (OpenStack Ocata on Ubuntu 16.04 onwards), it's also possible to use native Open vSwitch DPDK bonding to provide increased resilience for DPDK based deployments.\n\nThis feature is configured using the `dpdk-bond-mappings` and `dpdk-bond-config` options of this charm, for example:\n\n    neutron-openvswitch:\n        enable-dpdk: True\n        data-port: \"br-phynet1:dpdk-bond0\"\n        dpdk-bond-mappings: \"dpdk-bond0:a8:9d:21:cf:93:fc dpdk-bond0:a8:9d:21:cf:93:fd\"\n        dpdk-bond-config: \":balance-slb:off:fast\"\n\nIn this example, the PCI devices associated with the two MAC addresses provided will be configured as an OVS DPDK bond device named `dpdk-bond0`; this bond device is then used in br-phynet1 to provide resilient connectivity to the underlying network fabric.\n\nThe charm will automatically detect which PCI devices are on each unit of the application based on the `dpdk-bond-mappings` configuration provided, supporting use in environments where network device naming may not be consistent across units.\n\n# Port Configuration\n\n\u003e **Note**: External port configuration only applies when DVR mode is enabled.\n  This may not work when `neutron-openvswitch` is deployed in a LXD container.\n  If your deployment requires mixed placement of `neutron-openvswitch` units,\n  add multiple application instances with different names to your model to\n  allow for separate configuration. You can view examples of this configuration\n  in the [Octavia Charm](https://jaas.ai/octavia) functional test gate\n  [bundles](https://opendev.org/openstack/charm-octavia/src/branch/master/src/tests/bundles).\n\nAll network types (internal, external) are configured with bridge-mappings and\ndata-port and the flat-network-providers configuration option of the\nneutron-api charm.  Once deployed, you can configure the network specifics\nusing neutron net-create.\n\nIf the device name is not consistent between hosts, you can specify the same\nbridge multiple times with MAC addresses instead of interface names.  The charm\nwill loop through the list and configure the first matching interface.\n\nBasic configuration of a single external network, typically used as floating IP\naddresses combined with a GRE private network:\n\n    neutron-openvswitch:\n        bridge-mappings:         physnet1:br-ex\n        data-port:               br-ex:eth1\n    neutron-api:\n        flat-network-providers:  physnet1\n\n    neutron net-create --provider:network_type flat \\\n        --provider:physical_network physnet1 --router:external=true \\\n        external\n    neutron router-gateway-set provider external\n\nAlternative configuration with two networks, where the internal private\nnetwork is directly connected to the gateway with public IP addresses but a\nfloating IP address range is also offered.\n\n    neutron-openvswitch:\n        bridge-mappings:         physnet1:br-data external:br-ex\n        data-port:               br-data:eth1 br-ex:eth2\n    neutron-api:\n        flat-network-providers:  physnet1 external\n\nAlternative configuration with two external networks, one for public instance\naddresses and one for floating IP addresses.  Both networks are on the same\nphysical network connection (but they might be on different VLANs, that is\nconfigured later using neutron net-create).\n\n    neutron-openvswitch:\n        bridge-mappings:         physnet1:br-data\n        data-port:               br-data:eth1\n    neutron-api:\n        flat-network-providers:  physnet1\n\n    neutron net-create --provider:network_type vlan \\\n        --provider:segmentation_id 400 \\\n        --provider:physical_network physnet1 --shared external\n    neutron net-create --provider:network_type vlan \\\n        --provider:segmentation_id 401 \\\n        --provider:physical_network physnet1 --shared --router:external=true \\\n        floating\n    neutron router-gateway-set provider floating\n\nThis replaces the previous system of using ext-port, which always created a bridge\ncalled br-ex for external networks which was used implicitly by external router\ninterfaces.\n\nNote: If data-port is specified, the value of ext-port is ignored. This\nprevents misconfiguration of the charm. Aditionaly, in this scenario an error\nmessage is logged and the unit is marked as blocked in order to notify about\nthe misconfiguration.\n\n# Deferred service events\n\nOperational or maintenance procedures applied to a cloud often lead to the\nrestarting of various OpenStack services and/or the calling of certain charm\nhooks. Although normal, such events can be undesirable due to the service\ninterruptions they can cause.\n\nThe deferred service events feature provides the operator the choice of\npreventing these service restarts and hook calls from occurring, which can then\nbe resolved at a more opportune time.\n\nSee the [Deferred service events][cdg-deferred-service-events] page in the\n[OpenStack Charms Deployment Guide][cdg] for an in-depth treatment of this\nfeature.\n\n\u003c!-- LINKS --\u003e\n\n[cdg]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide\n[cdg-deferred-service-events]: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/deferred-events.html\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenstack%2Fcharm-neutron-openvswitch","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenstack%2Fcharm-neutron-openvswitch","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenstack%2Fcharm-neutron-openvswitch/lists"}