From 5517a878009e238f11d20b7d840572c4ba1f33ca Mon Sep 17 00:00:00 2001 From: OpenStack Proposal Bot Date: Thu, 19 Mar 2020 07:21:48 +0000 Subject: [PATCH] Imported Translations from Zanata For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I7ad4efed2850e64942f7237a4d0516a05e0fc0f6 --- .../locale/en_GB/LC_MESSAGES/doc-devref.po | 1180 +++++++++++++++++ 1 file changed, 1180 insertions(+) create mode 100644 doc/source/locale/en_GB/LC_MESSAGES/doc-devref.po diff --git a/doc/source/locale/en_GB/LC_MESSAGES/doc-devref.po b/doc/source/locale/en_GB/LC_MESSAGES/doc-devref.po new file mode 100644 index 0000000000..da00d7b56e --- /dev/null +++ b/doc/source/locale/en_GB/LC_MESSAGES/doc-devref.po @@ -0,0 +1,1180 @@ +# Andi Chandler , 2019. #zanata +# Andi Chandler , 2020. #zanata +msgid "" +msgstr "" +"Project-Id-Version: openstack-helm\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2020-03-19 00:43+0000\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"PO-Revision-Date: 2020-03-18 12:02+0000\n" +"Last-Translator: Andi Chandler \n" +"Language-Team: English (United Kingdom)\n" +"Language: en_GB\n" +"X-Generator: Zanata 4.3.3\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +msgid "" +"**Note:** The values defined in a PodDisruptionBudget may conflict with " +"other values that have been provided if an operator chooses to leverage " +"Rolling Updates for deployments. In the case where an operator defines a " +"``maxUnavailable`` and ``maxSurge`` within an update strategy that is higher " +"than a ``minAvailable`` within a pod disruption budget, a scenario may occur " +"where pods fail to be evicted from a deployment." +msgstr "" +"**Note:** The values defined in a PodDisruptionBudget may conflict with " +"other values that have been provided if an operator chooses to leverage " +"Rolling Updates for deployments. In the case where an operator defines a " +"``maxUnavailable`` and ``maxSurge`` within an update strategy that is higher " +"than a ``minAvailable`` within a pod disruption budget, a scenario may occur " +"where pods fail to be evicted from a deployment." + +msgid "" +":code:`neutron/templates/bin/_neutron-linuxbridge-agent-init.sh.tpl` is " +"configuring the tunnel IP, external bridge and all bridge mappings defined " +"in config. It is done in init container, and the IP for tunneling is shared " +"using file :code:`/tmp/pod-shared/ml2-local-ip.ini` with main linuxbridge " +"container." +msgstr "" +":code:`neutron/templates/bin/_neutron-linuxbridge-agent-init.sh.tpl` is " +"configuring the tunnel IP, external bridge and all bridge mappings defined " +"in config. It is done in init container, and the IP for tunnelling is shared " +"using file :code:`/tmp/pod-shared/ml2-local-ip.ini` with main linuxbridge " +"container." + +msgid "" +"A detail worth mentioning is that ovs is configured to use sockets, rather " +"than the default loopback mechanism." +msgstr "" +"A detail worth mentioning is that OVS is configured to use sockets, rather " +"than the default loopback mechanism." + +msgid "" +"A long-term goal, besides being image agnostic, is to also be able to " +"support any of the container runtimes that Kubernetes supports, even those " +"that might not use Docker's own packaging format. This will allow the " +"project to continue to offer maximum flexibility with regard to operator " +"choice." +msgstr "" +"A long-term goal, besides being image agnostic, is to also be able to " +"support any of the container runtimes that Kubernetes supports, even those " +"that might not use Docker's own packaging format. This will allow the " +"project to continue to offer maximum flexibility with regard to operator " +"choice." + +msgid "" +"A typical Helm daemonset may leverage a secret to store configuration data. " +"However, there are cases where the same secret document can't be used for " +"the entire daemonset, because there are node-specific differences." +msgstr "" +"A typical Helm daemonset may leverage a secret to store configuration data. " +"However, there are cases where the same secret document can't be used for " +"the entire daemonset, because there are node-specific differences." + +msgid "Adapting your daemonset to support node/nodelabel overrides" +msgstr "Adapting your daemonset to support node/nodelabel overrides" + +msgid "" +"All ``Deployment`` chart components are outfitted by default with rolling " +"update strategies:" +msgstr "" +"All ``Deployment`` chart components are outfitted by default with rolling " +"update strategies:" + +msgid "All dependencies described in neutron-dhcp-agent are valid here." +msgstr "All dependencies described in neutron-dhcp-agent are valid here." + +msgid "" +"All of the above configs are endpoints or path to the specific class " +"implementing the interface. You can see the endpoints to class mapping in " +"`setup.cfg `_." +msgstr "" +"All of the above configs are endpoints or path to the specific class " +"implementing the interface. You can see the endpoints to class mapping in " +"`setup.cfg `_." + +msgid "" +"Also note that other non-overridden values are inherited by hosts and labels " +"with overrides. The following shows a set of example hosts and the values " +"fed into each:" +msgstr "" +"Also note that other non-overridden values are inherited by hosts and labels " +"with overrides. The following shows a set of example hosts and the values " +"fed into each:" + +msgid "" +"An illustrative example of an ``images:`` section taken from the heat chart:" +msgstr "" +"An illustrative example of an ``images:`` section taken from the heat chart:" + +msgid "" +"Another place where the DHCP agent is dependent on L2 agent is the " +"dependency for the L2 agent daemonset:" +msgstr "" +"Another place where the DHCP agent is dependent on L2 agent is the " +"dependency for the L2 agent daemonset:" + +msgid "" +"As Helm stands today, several issues exist when you update images within " +"charts that might have been used by jobs that already ran to completion or " +"are still in flight. OpenStack-Helm developers will continue to work with " +"the Helm community or develop charts that will support job removal prior to " +"an upgrade, which will recreate services with updated images. An example of " +"where this behavior would be desirable is when an updated db\\_sync image " +"has updated to point from a Mitaka image to a Newton image. In this case, " +"the operator will likely want a db\\_sync job, which was already run and " +"completed during site installation, to run again with the updated image to " +"bring the schema inline with the Newton release." +msgstr "" +"As Helm stands today, several issues exist when you update images within " +"charts that might have been used by jobs that already ran to completion or " +"are still in flight. OpenStack-Helm developers will continue to work with " +"the Helm community or develop charts that will support job removal prior to " +"an upgrade, which will recreate services with updated images. An example of " +"where this behaviour would be desirable is when an updated db\\_sync image " +"has updated to point from a Mitaka image to a Newton image. In this case, " +"the operator will likely want a db\\_sync job, which was already run and " +"completed during site installation, to run again with the updated image to " +"bring the schema inline with the Newton release." + +msgid "" +"As an example, this line uses the ``endpoints.keystone_endpoint_uri_lookup`` " +"macro in the ``helm-toolkit`` chart (since it is used by all charts). Note " +"that there is a second convention here. All ``{{ define }}`` macros in " +"charts should be pre-fixed with the chart that is defining them. This allows " +"developers to easily identify the source of a Helm macro and also avoid " +"namespace collisions. In the example above, the macro ``endpoints." +"keystone_endpoint_uri_lookup`` is defined in the ``helm-toolkit`` chart. " +"This macro is passing three parameters (aided by the ``tuple`` method built " +"into the go/sprig templating library used by Helm):" +msgstr "" +"As an example, this line uses the ``endpoints.keystone_endpoint_uri_lookup`` " +"macro in the ``helm-toolkit`` chart (since it is used by all charts). Note " +"that there is a second convention here. All ``{{ define }}`` macros in " +"charts should be pre-fixed with the chart that is defining them. This allows " +"developers to easily identify the source of a Helm macro and also avoid " +"namespace collisions. In the example above, the macro ``endpoints." +"keystone_endpoint_uri_lookup`` is defined in the ``helm-toolkit`` chart. " +"This macro is passing three parameters (aided by the ``tuple`` method built " +"into the go/sprig templating library used by Helm):" + +msgid "" +"As part of Neutron chart, this daemonset is running Neutron OVS agent. It is " +"dependent on having :code:`openvswitch-db` and :code:`openvswitch-vswitchd` " +"deployed and ready. Since its the default choice of the networking backend, " +"all configuration is in place in `neutron/values.yaml`. :code:`neutron-ovs-" +"agent` should not be deployed when another SDN is used in `network.backend`." +msgstr "" +"As part of Neutron chart, this daemonset is running Neutron OVS agent. It is " +"dependent on having :code:`openvswitch-db` and :code:`openvswitch-vswitchd` " +"deployed and ready. Since its the default choice of the networking backend, " +"all configuration is in place in `neutron/values.yaml`. :code:`neutron-ovs-" +"agent` should not be deployed when another SDN is used in `network.backend`." + +msgid "Assume the chart name is ``mychart``." +msgstr "Assume the chart name is ``mychart``." + +msgid "" +"By default, each endpoint is located in the same namespace as the current " +"service's helm chart. To connect to a service which is running in a " +"different Kubernetes namespace, a ``namespace`` can be provided for each " +"individual endpoint." +msgstr "" +"By default, each endpoint is located in the same namespace as the current " +"service's helm chart. To connect to a service which is running in a " +"different Kubernetes namespace, a ``namespace`` can be provided for each " +"individual endpoint." + +msgid "" +"Charts should not use hard coded values such as ``http://keystone-api:5000`` " +"because these are not compatible with operator overrides and do not support " +"spreading components out over various namespaces." +msgstr "" +"Charts should not use hard coded values such as ``http://keystone-api:5000`` " +"because these are not compatible with operator overrides and do not support " +"spreading components out over various namespaces." + +msgid "" +"Configuration of OVS bridges can be done via `neutron/templates/bin/_neutron-" +"openvswitch-agent-init.sh.tpl`. The script is configuring the external " +"network bridge and sets up any bridge mappings defined in :code:`conf." +"auto_bridge_add`. These values should align with :code:`conf.plugins." +"openvswitch_agent.ovs.bridge_mappings`." +msgstr "" +"Configuration of OVS bridges can be done via `neutron/templates/bin/_neutron-" +"openvswitch-agent-init.sh.tpl`. The script is configuring the external " +"network bridge and sets up any bridge mappings defined in :code:`conf." +"auto_bridge_add`. These values should align with :code:`conf.plugins." +"openvswitch_agent.ovs.bridge_mappings`." + +msgid "" +"Configure neutron-server with SDN specific core_plugin/mechanism_drivers." +msgstr "" +"Configure neutron-server with SDN specific core_plugin/mechanism_drivers." + +msgid "Configuring network plugin" +msgstr "Configuring network plugin" + +msgid "" +"Consider the following (simplified) secret and daemonset pairing example:" +msgstr "" +"Consider the following (simplified) secret and daemonset pairing example:" + +msgid "Contents:" +msgstr "Contents:" + +msgid "Create separate chart with new SDN deployment method." +msgstr "Create separate chart with new SDN deployment method." + +msgid "" +"Currently OpenStack-Helm supports OpenVSwitch and LinuxBridge as a network " +"virtualization engines. In order to support many possible backends (SDNs), " +"modular architecture of Neutron chart was developed. OpenStack-Helm can " +"support every SDN solution that has Neutron plugin, either core_plugin or " +"mechanism_driver." +msgstr "" +"Currently OpenStack-Helm supports OpenVSwitch and LinuxBridge as a network " +"virtualisation engines. In order to support many possible backends (SDNs), " +"modular architecture of Neutron chart was developed. OpenStack-Helm can " +"support every SDN solution that has Neutron plugin, either core_plugin or " +"mechanism_driver." + +msgid "DHCP - auto-assign IP address and DNS info" +msgstr "DHCP - auto-assign IP address and DNS info" + +msgid "" +"DHCP agent is running dnsmasq process which is serving the IP assignment and " +"DNS info. DHCP agent is dependent on the L2 agent wiring the interface. So " +"one should be aware that when changing the L2 agent, it also needs to be " +"changed in the DHCP agent. The configuration of the DHCP agent includes " +"option `interface_driver`, which will instruct how the tap interface created " +"for serving the request should be wired." +msgstr "" +"DHCP agent is running dnsmasq process which is serving the IP assignment and " +"DNS info. DHCP agent is dependent on the L2 agent wiring the interface. So " +"one should be aware that when changing the L2 agent, it also needs to be " +"changed in the DHCP agent. The configuration of the DHCP agent includes " +"option `interface_driver`, which will instruct how the tap interface created " +"for serving the request should be wired." + +msgid "Developer References" +msgstr "Developer References" + +msgid "" +"EFK (Elasticsearch, Fluent-bit & Fluentd, Kibana) based Logging Mechanism" +msgstr "" +"EFK (Elasticsearch, Fluent-bit & Fluentd, Kibana) based Logging Mechanism" + +msgid "Endpoints" +msgstr "Endpoints" + +msgid "Exercising node/nodelabel overrides" +msgstr "Exercising node/nodelabel overrides" + +msgid "" +"Fluent-bit, Fluentd meet OpenStack-Helm's logging requirements for " +"gathering, aggregating, and delivering of logged events. Fluent-bit runs as " +"a daemonset on each node and mounts the `/var/lib/docker/containers` " +"directory. The Docker container runtime engine directs events posted to " +"stdout and stderr to this directory on the host. Fluent-bit then forward the " +"contents of that directory to Fluentd. Fluentd runs as deployment at the " +"designated nodes and expose service for Fluent-bit to forward logs. Fluentd " +"should then apply the Logstash format to the logs. Fluentd can also write " +"kubernetes and OpenStack metadata to the logs. Fluentd will then forward the " +"results to Elasticsearch and to optionally Kafka. Elasticsearch indexes the " +"logs in a logstash-* index by default. Kafka stores the logs in a ``logs`` " +"topic by default. Any external tool can then consume the ``logs`` topic." +msgstr "" +"Fluent-bit, Fluentd meet OpenStack-Helm's logging requirements for " +"gathering, aggregating, and delivering of logged events. Fluent-bit runs as " +"a daemonset on each node and mounts the `/var/lib/docker/containers` " +"directory. The Docker container runtime engine directs events posted to " +"stdout and stderr to this directory on the host. Fluent-bit then forward the " +"contents of that directory to Fluentd. Fluentd runs as deployment at the " +"designated nodes and expose service for Fluent-bit to forward logs. Fluentd " +"should then apply the Logstash format to the logs. Fluentd can also write " +"kubernetes and OpenStack metadata to the logs. Fluentd will then forward the " +"results to Elasticsearch and to optionally Kafka. Elasticsearch indexes the " +"logs in a logstash-* index by default. Kafka stores the logs in a ``logs`` " +"topic by default. Any external tool can then consume the ``logs`` topic." + +msgid "" +"For example, if you have some special conf setting that should be applied to " +"``host1.fqdn``, and another special conf setting that should be applied to " +"nodes labeled with ``someNodeLabel``, then three secret/daemonset pairs will " +"be generated and registered with kubernetes: one for ``host1.fqdn``, one for " +"``someNodeLabel``, and one for ``default``." +msgstr "" +"For example, if you have some special conf setting that should be applied to " +"``host1.fqdn``, and another special conf setting that should be applied to " +"nodes labeled with ``someNodeLabel``, then three secret/daemonset pairs will " +"be generated and registered with Kubernetes: one for ``host1.fqdn``, one for " +"``someNodeLabel``, and one for ``default``." + +msgid "" +"For instance, in the Neutron chart ``values.yaml`` the following endpoints " +"are defined:" +msgstr "" +"For instance, in the Neutron chart ``values.yaml`` the following endpoints " +"are defined:" + +msgid "Host overrides supercede label overrides" +msgstr "Host overrides supersede label overrides" + +msgid "" +"If :code:`.Values.manifests.daemonset_ovs_agent` will be set to false, " +"neutron ovs agent would not be launched. In that matter, other type of L2 or " +"L3 agent on compute node can be run." +msgstr "" +"If :code:`.Values.manifests.daemonset_ovs_agent` will be set to false, " +"Neutron OVS agent would not be launched. In that matter, other type of L2 or " +"L3 agent on compute node can be run." + +msgid "" +"If a node matches more than one nodelabel, only the last matching nodelabel " +"will apply (last in terms of the order the overrides are defined in the " +"YAML)." +msgstr "" +"If a node matches more than one nodelabel, only the last matching nodelabel " +"will apply (last in terms of the order the overrides are defined in the " +"YAML)." + +msgid "If required, add new networking agent label type." +msgstr "If required, add new networking agent label type." + +msgid "" +"If the SDN implements its own version of L3 networking, neutron-l3-agent " +"should not be started." +msgstr "" +"If the SDN implements its own version of L3 networking, neutron-l3-agent " +"should not be started." + +msgid "" +"If the SDN of your choice is using the ML2 core plugin, then the extra " +"options in `neutron/ml2/plugins/ml2_conf.ini` should be configured:" +msgstr "" +"If the SDN of your choice is using the ML2 core plugin, then the extra " +"options in `neutron/ml2/plugins/ml2_conf.ini` should be configured:" + +msgid "" +"If there is no matching FQDN and no matching nodelabel, then the default " +"daemonset/secret (with no overrides applied) is used." +msgstr "" +"If there is no matching FQDN and no matching nodelabel, then the default " +"daemonset/secret (with no overrides applied) is used." + +msgid "Images" +msgstr "Images" + +msgid "Implementation details of node/nodelabel overrides" +msgstr "Implementation details of node/nodelabel overrides" + +msgid "" +"In ``values.yaml`` in each chart, the same defaults are supplied in every " +"chart, which allows the operator to override at upgrade or deployment time." +msgstr "" +"In ``values.yaml`` in each chart, the same defaults are supplied in every " +"chart, which allows the operator to override at upgrade or deployment time." + +msgid "" +"In order to add support for more SDNs, these steps need to be performed:" +msgstr "" +"In order to add support for more SDNs, these steps need to be performed:" + +msgid "" +"In order to meet modularity criteria of Neutron chart, section `manifests` " +"in :code:`neutron/values.yaml` contains boolean values describing which " +"Neutron's Kubernetes resources should be deployed:" +msgstr "" +"In order to meet modularity criteria of Neutron chart, section `manifests` " +"in :code:`neutron/values.yaml` contains boolean values describing which " +"Neutron's Kubernetes resources should be deployed:" + +msgid "" +"In order to use linuxbridge in your OpenStack-Helm deployment, you need to " +"label the compute and controller/network nodes with `linuxbridge=enabled` " +"and use this `neutron/values.yaml` override:" +msgstr "" +"In order to use linuxbridge in your OpenStack-Helm deployment, you need to " +"label the compute and controller/network nodes with `linuxbridge=enabled` " +"and use this `neutron/values.yaml` override:" + +msgid "" +"Instead of having one daemonset with one monolithic secret, this helm-" +"toolkit feature permits a common daemonset and secret template, from which " +"daemonset and secret pairings are auto-generated. It supports establishing " +"value overrides for nodes with specific label value pairs and for targeting " +"nodes with specific hostnames and hostlabels. The overridden configuration " +"is merged with the normal config data, with the override data taking " +"precedence." +msgstr "" +"Instead of having one daemonset with one monolithic secret, this helm-" +"toolkit feature permits a common daemonset and secret template, from which " +"daemonset and secret pairings are auto-generated. It supports establishing " +"value overrides for nodes with specific label value pairs and for targeting " +"nodes with specific hostnames and hostlabels. The overridden configuration " +"is merged with the normal config data, with the override data taking " +"precedence." + +msgid "" +"Introducing a new SDN solution should consider how the above services are " +"provided. It maybe required to disable built-in Neutron functionality." +msgstr "" +"Introducing a new SDN solution should consider how the above services are " +"provided. It maybe required to disable built-in Neutron functionality." + +msgid "" +"L3 agent is serving the routing capabilities for Neutron networks. It is " +"also dependent on the L2 agent wiring the tap interface for the routers." +msgstr "" +"L3 agent is serving the routing capabilities for Neutron networks. It is " +"also dependent on the L2 agent wiring the tap interface for the routers." + +msgid "L3 routing - creation of routers" +msgstr "L3 routing - creation of routers" + +msgid "Linuxbridge" +msgstr "Linuxbridge" + +msgid "" +"Linuxbridge is the second type of Neutron reference architecture L2 agent. " +"It is running on nodes labeled `linuxbridge=enabled`. As mentioned before, " +"all nodes that are requiring the L2 services need to be labeled with " +"linuxbridge. This includes both the compute and controller/network nodes. It " +"is not possible to label the same node with both openvswitch and linuxbridge " +"(or any other network virtualization technology) at the same time." +msgstr "" +"Linuxbridge is the second type of Neutron reference architecture L2 agent. " +"It is running on nodes labeled `linuxbridge=enabled`. As mentioned before, " +"all nodes that are requiring the L2 services need to be labelled with " +"linuxbridge. This includes both the compute and controller/network nodes. It " +"is not possible to label the same node with both openvswitch and linuxbridge " +"(or any other network virtualisation technology) at the same time." + +msgid "Logging Mechanism" +msgstr "Logging Mechanism" + +msgid "Logging Requirements" +msgstr "Logging Requirements" + +msgid "Metadata - Provide proxy for Nova metadata service" +msgstr "Metadata - Provide proxy for Nova metadata service" + +msgid "" +"Metadata-agent is a proxy to nova-metadata service. This one provides " +"information about public IP, hostname, ssh keys, and any tenant specific " +"information. The same dependencies apply for metadata as it is for DHCP and " +"L3 agents. Other SDNs may require to force the config driver in nova, since " +"the metadata service is not exposed by it." +msgstr "" +"Metadata-agent is a proxy to nova-metadata service. This one provides " +"information about public IP, hostname, ssh keys, and any tenant specific " +"information. The same dependencies apply for metadata as it is for DHCP and " +"L3 agents. Other SDNs may require to force the config driver in Nova, since " +"the metadata service is not exposed by it." + +msgid "Networking" +msgstr "Networking" + +msgid "Neutron architecture" +msgstr "Neutron architecture" + +msgid "Neutron chart includes the following services:" +msgstr "Neutron chart includes the following services:" + +msgid "" +"Neutron-server service is scheduled on nodes with `openstack-control-" +"plane=enabled` label." +msgstr "" +"Neutron-server service is scheduled on nodes with `openstack-control-" +"plane=enabled` label." + +msgid "Node and node label specific daemonset configurations" +msgstr "Node and node label specific daemonset configurations" + +msgid "Note that only one set of overrides is applied per node, such that:" +msgstr "Note that only one set of overrides is applied per node, such that:" + +msgid "" +"Note that some additional values have been injected into the config file, " +"this is performed via statements in the configmap template, which also calls " +"the ``helm-toolkit.utils.to_oslo_conf`` to convert the yaml to the required " +"layout:" +msgstr "" +"Note that some additional values have been injected into the config file, " +"this is performed via statements in the configmap template, which also calls " +"the ``helm-toolkit.utils.to_oslo_conf`` to convert the yaml to the required " +"layout:" + +msgid "" +"Note: Rolling update values can conflict with values defined in each " +"service's PodDisruptionBudget. See `here `_ for more " +"information." +msgstr "" +"Note: Rolling update values can conflict with values defined in each " +"service's PodDisruptionBudget. See `here `_ for more " +"information." + +msgid "Nova config dependency" +msgstr "Nova config dependency" + +msgid "Nova vcpu example" +msgstr "Nova vCPU example" + +msgid "" +"Now we can wrap the existing YAML to make it support node and nodelabel " +"overrides, with minimal changes to the existing YAML (note where $secretName " +"has been substituted):" +msgstr "" +"Now we can wrap the existing YAML to make it support node and nodelabel " +"overrides, with minimal changes to the existing YAML (note where $secretName " +"has been substituted):" + +msgid "OSLO-Config Values" +msgstr "OSLO-Config Values" + +msgid "" +"OpenStack-Helm defines a centralized logging mechanism to provide insight " +"into the state of the OpenStack services and infrastructure components as " +"well as underlying Kubernetes platform. Among the requirements for a logging " +"platform, where log data can come from and where log data need to be " +"delivered are very variable. To support various logging scenarios, OpenStack-" +"Helm should provide a flexible mechanism to meet with certain operation " +"needs." +msgstr "" +"OpenStack-Helm defines a centralized logging mechanism to provide insight " +"into the state of the OpenStack services and infrastructure components as " +"well as underlying Kubernetes platform. Among the requirements for a logging " +"platform, where log data can come from and where log data need to be " +"delivered are very variable. To support various logging scenarios, OpenStack-" +"Helm should provide a flexible mechanism to meet with certain operation " +"needs." + +msgid "" +"OpenStack-Helm generates oslo-config compatible formatted configuration " +"files for services dynamically from values specified in a yaml tree. This " +"allows operators to control any and all aspects of an OpenStack services " +"configuration. An example snippet for an imaginary Keystone configuration is " +"described here:" +msgstr "" +"OpenStack-Helm generates oslo-config compatible formatted configuration " +"files for services dynamically from values specified in a yaml tree. This " +"allows operators to control any and all aspects of an OpenStack services " +"configuration. An example snippet for an imaginary Keystone configuration is " +"described here:" + +msgid "" +"OpenStack-Helm leverages PodDisruptionBudgets to enforce quotas that ensure " +"that a certain number of replicas of a pod are available at any given time. " +"This is particularly important in the case when a Kubernetes node needs to " +"be drained." +msgstr "" +"OpenStack-Helm leverages PodDisruptionBudgets to enforce quotas that ensure " +"that a certain number of replicas of a pod are available at any given time. " +"This is particularly important in the case when a Kubernetes node needs to " +"be drained." + +msgid "" +"OpenStack-Helm provides fast and lightweight log forwarder and full featured " +"log aggregator complementing each other providing a flexible and reliable " +"solution. Especially, Fluent-bit is used as a log forwarder and Fluentd is " +"used as a main log aggregator and processor." +msgstr "" +"OpenStack-Helm provides fast and lightweight log forwarder and full featured " +"log aggregator complementing each other providing a flexible and reliable " +"solution. Especially, Fluent-bit is used as a log forwarder and Fluentd is " +"used as a main log aggregator and processor." + +msgid "OpenVSwitch" +msgstr "OpenVSwitch" + +msgid "Other SDNs" +msgstr "Other SDNs" + +msgid "Other networking services provided by Neutron are:" +msgstr "Other networking services provided by Neutron are:" + +msgid "Pod Disruption Budgets" +msgstr "Pod Disruption Budgets" + +msgid "" +"SDNs implementing ML2 driver can add extra/plugin-specific configuration " +"options in `neutron/ml2/plugins/ml2_conf.ini`. Or define its own " +"`ml2_conf_.ini` file where configs specific to the SDN would be placed." +msgstr "" +"SDNs implementing ML2 driver can add extra/plugin-specific configuration " +"options in `neutron/ml2/plugins/ml2_conf.ini`. Or define its own " +"`ml2_conf_.ini` file where configs specific to the SDN would be placed." + +msgid "" +"Script in :code:`neutron/templates/bin/_neutron-openvswitch-agent-init.sh." +"tpl` is responsible for determining the tunnel interface and its IP for " +"later usage by :code:`neutron-ovs-agent`. The IP is set in init container " +"and shared between init container and main container with :code:`neutron-ovs-" +"agent` via file :code:`/tmp/pod-shared/ml2-local-ip.ini`." +msgstr "" +"Script in :code:`neutron/templates/bin/_neutron-openvswitch-agent-init.sh." +"tpl` is responsible for determining the tunnel interface and its IP for " +"later usage by :code:`neutron-ovs-agent`. The IP is set in init container " +"and shared between init container and main container with :code:`neutron-ovs-" +"agent` via file :code:`/tmp/pod-shared/ml2-local-ip.ini`." + +msgid "" +"Some nodes may have a different vcpu_pin_set in nova.conf due to differences " +"in CPU hardware." +msgstr "" +"Some nodes may have a different vcpu_pin_set in nova.conf due to differences " +"in CPU hardware." + +msgid "" +"Specify if new SDN would like to use existing services from Neutron: L3, " +"DHCP, metadata." +msgstr "" +"Specify if new SDN would like to use existing services from Neutron: L3, " +"DHCP, metadata." + +msgid "" +"The Neutron reference architecture provides mechanism_drivers :code:" +"`OpenVSwitch` (OVS) and :code:`linuxbridge` (LB) with ML2 :code:" +"`core_plugin` framework." +msgstr "" +"The Neutron reference architecture provides mechanism_drivers :code:" +"`OpenVSwitch` (OVS) and :code:`linuxbridge` (LB) with ML2 :code:" +"`core_plugin` framework." + +msgid "" +"The OpenStack-Helm project also implements annotations across all chart " +"configmaps so that changing resources inside containers, such as " +"configuration files, triggers a Kubernetes rolling update. This means that " +"those resources can be updated without deleting and redeploying the service " +"and can be treated like any other upgrade, such as a container image change." +msgstr "" +"The OpenStack-Helm project also implements annotations across all chart " +"configmaps so that changing resources inside containers, such as " +"configuration files, triggers a Kubernetes rolling update. This means that " +"those resources can be updated without deleting and redeploying the service " +"and can be treated like any other upgrade, such as a container image change." + +msgid "" +"The OpenStack-Helm project assumes all upgrades will be done through Helm. " +"This includes handling several different resource types. First, changes to " +"the Helm chart templates themselves are handled. Second, all of the " +"resources layered on top of the container image, such as ``ConfigMaps`` " +"which includes both scripts and configuration files, are updated during an " +"upgrade. Finally, any image references will result in rolling updates of " +"containers, replacing them with the updating image." +msgstr "" +"The OpenStack-Helm project assumes all upgrades will be done through Helm. " +"This includes handling several different resource types. First, changes to " +"the Helm chart templates themselves are handled. Second, all of the " +"resources layered on top of the container image, such as ``ConfigMaps`` " +"which includes both scripts and configuration files, are updated during an " +"upgrade. Finally, any image references will result in rolling updates of " +"containers, replacing them with the updating image." + +msgid "" +"The OpenStack-Helm project today uses a mix of Docker images from " +"Stackanetes and Kolla, but will likely standardize on a default set of " +"images for all charts without any reliance on image-specific utilities." +msgstr "" +"The OpenStack-Helm project today uses a mix of Docker images from " +"Stackanetes and Kolla, but will likely standardise on a default set of " +"images for all charts without any reliance on image-specific utilities." + +msgid "" +"The ``hash`` function defined in the ``helm-toolkit`` chart ensures that any " +"change to any file referenced by configmap-bin.yaml or configmap-etc.yaml " +"results in a new hash, which will then trigger a rolling update." +msgstr "" +"The ``hash`` function defined in the ``helm-toolkit`` chart ensures that any " +"change to any file referenced by configmap-bin.yaml or configmap-etc.yaml " +"results in a new hash, which will then trigger a rolling update." + +msgid "The above configuration options are handled by `neutron/values.yaml`:" +msgstr "The above configuration options are handled by `neutron/values.yaml`:" + +msgid "" +"The chart will then generate one daemonset for each host and label override, " +"in addition to a default daemonset for which no overrides are applied. Each " +"daemonset generated will also exclude from its scheduling criteria all other " +"hosts and labels defined in other overrides for the same daemonset, to " +"ensure that there is no overlap of daemonsets (i.e., one and only one " +"daemonset of a given type for each node)." +msgstr "" +"The chart will then generate one daemonset for each host and label override, " +"in addition to a default daemonset for which no overrides are applied. Each " +"daemonset generated will also exclude from its scheduling criteria all other " +"hosts and labels defined in other overrides for the same daemonset, to " +"ensure that there is no overlap of daemonsets (i.e., one and only one " +"daemonset of a given type for each node)." + +msgid "" +"The farther down the list the label appears, the greater precedence it has. " +"e.g., \"another-label\" overrides will apply to a node containing both " +"labels." +msgstr "" +"The farther down the list the label appears, the greater precedence it has. " +"e.g., \"another-label\" overrides will apply to a node containing both " +"labels." + +msgid "" +"The following example demonstrates how to exercise the node/nodelabel " +"overrides:" +msgstr "" +"The following example demonstrates how to exercise the node/nodelabel " +"overrides:" + +msgid "" +"The following standards are in use today, in addition to any components " +"defined by the service itself:" +msgstr "" +"The following standards are in use today, in addition to any components " +"defined by the service itself:" + +msgid "" +"The macros that help translate these into the actual URLs necessary are " +"defined in the ``helm-toolkit`` chart. For instance, the cinder chart " +"defines a ``glance_api_servers`` definition in the ``cinder.conf`` template:" +msgstr "" +"The macros that help translate these into the actual URLs necessary are " +"defined in the ``helm-toolkit`` chart. For instance, the Cinder chart " +"defines a ``glance_api_servers`` definition in the ``cinder.conf`` template:" + +msgid "" +"The order of precedence for matches is FQDN, node label, and then default. " +"If a node matches both a FQDN and a nodelabel, then only the FQDN override " +"is applied. Pay special attention to adding FQDN overrides for nodes that " +"match a nodelabel override, as you would need to duplicate the nodelabel " +"overrides for that node in the FQDN overrides for them to still apply." +msgstr "" +"The order of precedence for matches is FQDN, node label, and then default. " +"If a node matches both a FQDN and a nodelabel, then only the FQDN override " +"is applied. Pay special attention to adding FQDN overrides for nodes that " +"match a nodelabel override, as you would need to duplicate the nodelabel " +"overrides for that node in the FQDN overrides for them to still apply." + +msgid "" +"The ovs set of daemonsets are running on the node labeled " +"`openvswitch=enabled`. This includes the compute and controller/network " +"nodes. For more flexibility, OpenVSwitch as a tool was split out of Neutron " +"chart, and put in separate chart dedicated OpenVSwitch. Neutron OVS agent " +"remains in Neutron chart. Splitting out the OpenVSwitch creates " +"possibilities to use it with different SDNs, adjusting the configuration " +"accordingly." +msgstr "" +"The OVS set of daemonsets are running on the node labeled " +"`openvswitch=enabled`. This includes the compute and controller/network " +"nodes. For more flexibility, OpenVSwitch as a tool was split out of Neutron " +"chart, and put in separate chart dedicated OpenVSwitch. Neutron OVS agent " +"remains in Neutron chart. Splitting out the OpenVSwitch creates " +"possibilities to use it with different SDNs, adjusting the configuration " +"accordingly." + +msgid "" +"The project's core philosophy regarding images is that the toolsets required " +"to enable the OpenStack services should be applied by Kubernetes itself. " +"This requires OpenStack-Helm to develop common and simple scripts with " +"minimal dependencies that can be overlaid on any image that meets the " +"OpenStack core library requirements. The advantage of this is that the " +"project can be image agnostic, allowing operators to use Stackanetes, Kolla, " +"LOCI, or any image flavor and format they choose and they will all function " +"the same." +msgstr "" +"The project's core philosophy regarding images is that the toolsets required " +"to enable the OpenStack services should be applied by Kubernetes itself. " +"This requires OpenStack-Helm to develop common and simple scripts with " +"minimal dependencies that can be overlaid on any image that meets the " +"OpenStack core library requirements. The advantage of this is that the " +"project can be image agnostic, allowing operators to use Stackanetes, Kolla, " +"LOCI, or any image flavour and format they choose and they will all function " +"the same." + +msgid "" +"The project's goal is to provide a consistent mechanism for endpoints. " +"OpenStack is a highly interconnected application, with various components " +"requiring connectivity details to numerous services, including other " +"OpenStack components and infrastructure elements such as databases, queues, " +"and memcached infrastructure. The project's goal is to ensure that it can " +"provide a consistent mechanism for defining these \"endpoints\" across all " +"charts and provide the macros necessary to convert those definitions into " +"usable endpoints. The charts should consistently default to building " +"endpoints that assume the operator is leveraging all charts to build their " +"OpenStack cloud. Endpoints should be configurable if an operator would like " +"a chart to work with their existing infrastructure or run elements in " +"different namespaces." +msgstr "" +"The project's goal is to provide a consistent mechanism for endpoints. " +"OpenStack is a highly interconnected application, with various components " +"requiring connectivity details to numerous services, including other " +"OpenStack components and infrastructure elements such as databases, queues, " +"and memcached infrastructure. The project's goal is to ensure that it can " +"provide a consistent mechanism for defining these \"endpoints\" across all " +"charts and provide the macros necessary to convert those definitions into " +"usable endpoints. The charts should consistently default to building " +"endpoints that assume the operator is leveraging all charts to build their " +"OpenStack cloud. Endpoints should be configurable if an operator would like " +"a chart to work with their existing infrastructure or run elements in " +"different namespaces." + +msgid "" +"The resulting logs can then be queried directly through Elasticsearch, or " +"they can be viewed via Kibana. Kibana offers a dashboard that can create " +"custom views on logged events, and Kibana integrates well with Elasticsearch " +"by default." +msgstr "" +"The resulting logs can then be queried directly through Elasticsearch, or " +"they can be viewed via Kibana. Kibana offers a dashboard that can create " +"custom views on logged events, and Kibana integrates well with Elasticsearch " +"by default." + +msgid "" +"There is also a need for DHCP agent to pass ovs agent config file (in :code:" +"`neutron/templates/bin/_neutron-dhcp-agent.sh.tpl`):" +msgstr "" +"There is also a need for DHCP agent to pass OVS agent config file (in :code:" +"`neutron/templates/bin/_neutron-dhcp-agent.sh.tpl`):" + +msgid "" +"These quotas are configurable by modifying the ``minAvailable`` field within " +"each PodDisruptionBudget manifest, which is conveniently mapped to a " +"templated variable inside the ``values.yaml`` file. The ``min_available`` " +"within each service's ``values.yaml`` file can be represented by either a " +"whole number, such as ``1``, or a percentage, such as ``80%``. For example, " +"when deploying 5 replicas of a pod (such as keystone-api), using " +"``min_available: 3`` would enforce policy to ensure at least 3 replicas were " +"running, whereas using ``min_available: 80%`` would ensure that 4 replicas " +"of that pod are running." +msgstr "" +"These quotas are configurable by modifying the ``minAvailable`` field within " +"each PodDisruptionBudget manifest, which is conveniently mapped to a " +"templated variable inside the ``values.yaml`` file. The ``min_available`` " +"within each service's ``values.yaml`` file can be represented by either a " +"whole number, such as ``1``, or a percentage, such as ``80%``. For example, " +"when deploying 5 replicas of a pod (such as keystone-api), using " +"``min_available: 3`` would enforce policy to ensure at least 3 replicas were " +"running, whereas using ``min_available: 80%`` would ensure that 4 replicas " +"of that pod are running." + +msgid "" +"These values define all the endpoints that the Neutron chart may need in " +"order to build full URL compatible endpoints to various services. Long-term, " +"these will also include database, memcached, and rabbitmq elements in one " +"place. Essentially, all external connectivity can be defined centrally." +msgstr "" +"These values define all the endpoints that the Neutron chart may need in " +"order to build full URL compatible endpoints to various services. Long-term, " +"these will also include database, memcached, and rabbitmq elements in one " +"place. Essentially, all external connectivity can be defined centrally." + +msgid "" +"This daemonset includes the linuxbridge Neutron agent with bridge-utils and " +"ebtables utilities installed. This is all that is needed, since linuxbridge " +"uses native kernel libraries." +msgstr "" +"This daemonset includes the linuxbridge Neutron agent with bridge-utils and " +"ebtables utilities installed. This is all that is needed, since linuxbridge " +"uses native kernel libraries." + +msgid "This is accomplished with the following annotation:" +msgstr "This is accomplished with the following annotation:" + +msgid "" +"This option will allow to configure the Neutron services in proper way, by " +"checking what is the actual backed set in :code:`neutron/values.yaml`." +msgstr "" +"This option will allow to configure the Neutron services in proper way, by " +"checking what is the actual backed set in :code:`neutron/values.yaml`." + +msgid "" +"This requirement is OVS specific, the `ovsdb_connection` string is defined " +"in `openvswitch_agent.ini` file, specifying how DHCP agent can connect to " +"ovs. When using other SDNs, running the DHCP agent may not be required. When " +"the SDN solution is addressing the IP assignments in another way, neutron's " +"DHCP agent should be disabled." +msgstr "" +"This requirement is OVS specific, the `ovsdb_connection` string is defined " +"in `openvswitch_agent.ini` file, specifying how DHCP agent can connect to " +"ovs. When using other SDNs, running the DHCP agent may not be required. When " +"the SDN solution is addressing the IP assignments in another way, neutron's " +"DHCP agent should be disabled." + +msgid "" +"This runs the OVS tool and database. OpenVSwitch chart is not Neutron " +"specific, it may be used with other technologies that are leveraging the OVS " +"technology, such as OVN or ODL." +msgstr "" +"This runs the OVS tool and database. OpenVSwitch chart is not Neutron " +"specific, it may be used with other technologies that are leveraging the OVS " +"technology, such as OVN or ODL." + +msgid "" +"This will be consumed by the templated ``configmap-etc.yaml`` manifest to " +"produce the following config file:" +msgstr "" +"This will be consumed by the templated ``configmap-etc.yaml`` manifest to " +"produce the following config file:" + +msgid "" +"To address this use-case, the ``helm-toolkit.utils.daemonset_overrides`` " +"template was added in helm-toolkit. This was created with the intention that " +"it should be straightforward to convert (wrap) a pre-existing daemonset with " +"the functionality to override secret parameters on a per-node or per-" +"nodelabel basis." +msgstr "" +"To address this use-case, the ``helm-toolkit.utils.daemonset_overrides`` " +"template was added in helm-toolkit. This was created with the intention that " +"it should be straightforward to convert (wrap) a pre-existing daemonset with " +"the functionality to override secret parameters on a per-node or per-" +"nodelabel basis." + +msgid "" +"To address this, we can specify overrides in the values fed to the chart. Ex:" +msgstr "" +"To address this, we can specify overrides in the values fed to the chart. Ex:" + +msgid "" +"To be able to configure multiple networking plugins inside of OpenStack-" +"Helm, a new configuration option is added:" +msgstr "" +"To be able to configure multiple networking plugins inside of OpenStack-" +"Helm, a new configuration option is added:" + +msgid "" +"To enable new SDN solution, there should be separate chart created, which " +"would handle the deployment of service, setting up the database and any " +"related networking functionality that SDN is providing." +msgstr "" +"To enable new SDN solution, there should be separate chart created, which " +"would handle the deployment of service, setting up the database and any " +"related networking functionality that SDN is providing." + +msgid "" +"To that end, all charts provide an ``images:`` section that allows operators " +"to override images. Also, all default image references should be fully " +"spelled out, even those hosted by Docker or Quay. Further, no default image " +"reference should use ``:latest`` but rather should be pinned to a specific " +"version to ensure consistent behavior for deployments over time." +msgstr "" +"To that end, all charts provide an ``images:`` section that allows operators " +"to override images. Also, all default image references should be fully " +"spelled out, even those hosted by Docker or Quay. Further, no default image " +"reference should use ``:latest`` but rather should be pinned to a specific " +"version to ensure consistent behaviour for deployments over time." + +msgid "" +"To use other Neutron reference architecture types of SDN, these options " +"should be configured in :code:`neutron.conf`:" +msgstr "" +"To use other Neutron reference architecture types of SDN, these options " +"should be configured in :code:`neutron.conf`:" + +msgid "" +"Today, the ``images:`` section has several common conventions. Most " +"OpenStack services require a database initialization function, a database " +"synchronization function, and a series of steps for Keystone registration " +"and integration. Each component may also have a specific image that composes " +"an OpenStack service. The images may or may not differ, but regardless, " +"should all be defined in ``images``." +msgstr "" +"Today, the ``images:`` section has several common conventions. Most " +"OpenStack services require a database initialization function, a database " +"synchronization function, and a series of steps for Keystone registration " +"and integration. Each component may also have a specific image that composes " +"an OpenStack service. The images may or may not differ, but regardless, " +"should all be defined in ``images``." + +msgid "Typical networking API request is an operation of create/update/delete:" +msgstr "" +"Typical networking API request is an operation of create/update/delete:" + +msgid "Upgrades and Reconfiguration" +msgstr "Upgrades and Reconfiguration" + +msgid "" +"Whenever we change the L2 agent, it should be reflected in `nova/values." +"yaml` in dependency resolution for nova-compute." +msgstr "" +"Whenever we change the L2 agent, it should be reflected in `nova/values." +"yaml` in dependency resolution for nova-compute." + +msgid "" +"Your daemonset should now support node and nodelabl level overrides. (Note " +"that you will also need your chart to have helm-toolkit listed as a " +"dependency.)" +msgstr "" +"Your daemonset should now support node and nodelabel level overrides. (Note " +"that you will also need your chart to have helm-toolkit listed as a " +"dependency.)" + +msgid "" +"``host1.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" +msgstr "" +"``host1.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" + +msgid "" +"``host2.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" +msgstr "" +"``host2.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" + +msgid "" +"``host3.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" +msgstr "" +"``host3.fqdn`` with labels ``compute-type: dpdk, sriov`` and ``another-" +"label: another-value``:" + +msgid "``host4.fqdn`` with labels ``compute-type: dpdk, sriov``:" +msgstr "``host4.fqdn`` with labels ``compute-type: dpdk, sriov``:" + +msgid "``host5.fqdn`` with no labels:" +msgstr "``host5.fqdn`` with no labels:" + +msgid "" +"api: This is the port to map to for the service. Some components, such as " +"glance, provide an ``api`` port and a ``registry`` port, for example." +msgstr "" +"api: This is the port to map to for the service. Some components, such as " +"glance, provide an ``api`` port and a ``registry`` port, for example." + +msgid "" +"db\\_drop: The image that will perform database deletion operations for the " +"OpenStack service." +msgstr "" +"db\\_drop: The image that will perform database deletion operations for the " +"OpenStack service." + +msgid "" +"db\\_init: The image that will perform database creation operations for the " +"OpenStack service." +msgstr "" +"db\\_init: The image that will perform database creation operations for the " +"OpenStack service." + +msgid "" +"db\\_sync: The image that will perform database sync (schema initialization " +"and migration) for the OpenStack service." +msgstr "" +"db\\_sync: The image that will perform database sync (schema initialisation " +"and migration) for the OpenStack service." + +msgid "" +"dep\\_check: The image that will perform dependency checking in an init-" +"container." +msgstr "" +"dep\\_check: The image that will perform dependency checking in an init-" +"container." + +msgid "" +"image: This is the OpenStack service that the endpoint is being built for. " +"This will be mapped to ``glance`` which is the image service for OpenStack." +msgstr "" +"image: This is the OpenStack service that the endpoint is being built for. " +"This will be mapped to ``glance`` which is the image service for OpenStack." + +msgid "" +"internal: This is the OpenStack endpoint type we are looking for - valid " +"values would be ``internal``, ``admin``, and ``public``" +msgstr "" +"internal: This is the OpenStack endpoint type we are looking for - valid " +"values would be ``internal``, ``admin``, and ``public``" + +msgid "" +"ks\\_endpoints: The image that will perform keystone endpoint registration " +"for the service." +msgstr "" +"ks\\_endpoints: The image that will perform Keystone endpoint registration " +"for the service." + +msgid "" +"ks\\_service: The image that will perform keystone service registration for " +"the service." +msgstr "" +"ks\\_service: The image that will perform Keystone service registration for " +"the service." + +msgid "" +"ks\\_user: The image that will perform keystone user creation for the " +"service." +msgstr "" +"ks\\_user: The image that will perform Keystone user creation for the " +"service." + +msgid "network" +msgstr "network" + +msgid "neutron-dhcp-agent" +msgstr "neutron-dhcp-agent" + +msgid "" +"neutron-dhcp-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." +msgstr "" +"neutron-dhcp-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." + +msgid "neutron-l3-agent" +msgstr "neutron-l3-agent" + +msgid "" +"neutron-l3-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." +msgstr "" +"neutron-l3-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." + +msgid "neutron-lb-agent" +msgstr "neutron-lb-agent" + +msgid "neutron-metadata-agent" +msgstr "neutron-metadata-agent" + +msgid "" +"neutron-metadata-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." +msgstr "" +"neutron-metadata-agent service is scheduled to run on nodes with the label " +"`openstack-control-plane=enabled`." + +msgid "neutron-ovs-agent" +msgstr "neutron-ovs-agent" + +msgid "neutron-server" +msgstr "neutron-server" + +msgid "" +"neutron-server is serving the networking REST API for operator and other " +"OpenStack services usage. The internals of Neutron are highly flexible, " +"providing plugin mechanisms for all networking services exposed. The " +"consistent API is exposed to the user, but the internal implementation is up " +"to the chosen SDN." +msgstr "" +"neutron-server is serving the networking REST API for operator and other " +"OpenStack services usage. The internals of Neutron are highly flexible, " +"providing plugin mechanisms for all networking services exposed. The " +"consistent API is exposed to the user, but the internal implementation is up " +"to the chosen SDN." + +msgid "openvswitch-db and openvswitch-vswitchd" +msgstr "openvswitch-db and openvswitch-vswitchd" + +msgid "port" +msgstr "port" + +msgid "" +"pull\\_policy: The image pull policy, one of \"Always\", \"IfNotPresent\", " +"and \"Never\" which will be used by all containers in the chart." +msgstr "" +"pull\\_policy: The image pull policy, one of \"Always\", \"IfNotPresent\", " +"and \"Never\" which will be used by all containers in the chart." + +msgid "subnet" +msgstr "subnet"