diff --git a/doc/admin-guide-cloud-rst/source/locale/admin-guide-cloud-rst.pot b/doc/admin-guide-cloud-rst/source/locale/admin-guide-cloud-rst.pot index 0eb8ce6203..c6b1f1bafc 100644 --- a/doc/admin-guide-cloud-rst/source/locale/admin-guide-cloud-rst.pot +++ b/doc/admin-guide-cloud-rst/source/locale/admin-guide-cloud-rst.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Cloud Administrator Guide 0.9\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-08-16 06:16+0000\n" +"POT-Creation-Date: 2015-08-19 06:15+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -511,6 +511,12 @@ msgstr "" msgid "**Description of VNC configuration options**" msgstr "" +#: ../objectstorage-troubleshoot.rst:0 +msgid "" +"**Description of configuration options for [drive-audit] in drive-audit." +"conf**" +msgstr "" + #: ../compute-security.rst:0 msgid "**Description of trusted computing configuration options**" msgstr "" @@ -2324,6 +2330,11 @@ msgid "" "can see the ``br-int`` integration bridge." msgstr "" +#: ../objectstorage-troubleshoot.rst:158 +msgid "" +"After it validates, save the builder and create a new ``account.builder``:" +msgstr "" + #: ../compute-node-down.rst:183 msgid "After power is recovered and all hardware components have restarted:" msgstr "" @@ -3761,6 +3772,12 @@ msgstr "" msgid "Capacity weigher" msgstr "" +#: ../objectstorage-troubleshoot.rst:77 +msgid "" +"Caps the length of log lines to the value given; no limit if set to 0, the " +"default." +msgstr "" + #: ../identity_concepts.rst:48 msgid "Captures the operations that a user can perform in a given tenant." msgstr "" @@ -4170,8 +4187,10 @@ msgstr "" # #-#-#-#-# compute-networking-nova.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# compute-remote-console-access.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# compute-security.pot (Cloud Administrator Guide 0.9) #-#-#-#-# +# #-#-#-#-# objectstorage-troubleshoot.pot (Cloud Administrator Guide 0.9) #-#-#-#-# #: ../compute-networking-nova.rst:309 ../compute-networking-nova.rst:507 #: ../compute-remote-console-access.rst:152 ../compute-security.rst:103 +#: ../objectstorage-troubleshoot.rst:61 msgid "Configuration option = Default value" msgstr "" @@ -5395,6 +5414,7 @@ msgstr "" # #-#-#-#-# networking_arch.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# networking_introduction.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# networking_multi-dhcp-agents.pot (Cloud Administrator Guide 0.9) #-#-#-#-# +# #-#-#-#-# objectstorage-troubleshoot.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# telemetry-measurements.pot (Cloud Administrator Guide 0.9) #-#-#-#-# #: ../compute-flavors.rst:37 ../compute-manage-volumes.rst:14 #: ../compute-networking-nova.rst:310 ../compute-networking-nova.rst:508 @@ -5404,7 +5424,7 @@ msgstr "" #: ../networking_adv-features.rst:130 ../networking_adv-features.rst:693 #: ../networking_arch.rst:29 ../networking_introduction.rst:29 #: ../networking_introduction.rst:122 ../networking_multi-dhcp-agents.rst:40 -#: ../telemetry-measurements.rst:31 +#: ../objectstorage-troubleshoot.rst:62 ../telemetry-measurements.rst:31 msgid "Description" msgstr "" @@ -5432,6 +5452,10 @@ msgstr "" msgid "Detect drive failures preempting data corruption." msgstr "" +#: ../objectstorage-troubleshoot.rst:49 +msgid "Detect failed drives" +msgstr "" + #: ../orchestration-stack-domain-users.rst:16 msgid "" "Detect signal completion of some action, typically configuration of software " @@ -5484,6 +5508,14 @@ msgstr "" msgid "Direct object access" msgstr "" +#: ../objectstorage-troubleshoot.rst:64 +msgid "Directory devices are mounted under" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:84 +msgid "Directory where stats for a few items will be stored" +msgstr "" + #: ../compute-live-migration-usage.rst:112 msgid "Disabled Reason" msgstr "" @@ -5603,6 +5635,10 @@ msgstr "" msgid "Drive auditing" msgstr "" +#: ../objectstorage-troubleshoot.rst:11 +msgid "Drive failure" +msgstr "" + #: ../blockstorage_over_subscription.rst:52 msgid "Drivers can report the following capabilities for a back end or a pool:" msgstr "" @@ -5804,6 +5840,10 @@ msgstr "" msgid "Element" msgstr "" +#: ../objectstorage-troubleshoot.rst:96 +msgid "Emergency recovery of ring builder files" +msgstr "" + #: ../compute-networking-nova.rst:622 msgid "Enable IP forwarding" msgstr "" @@ -6666,6 +6706,14 @@ msgid "" "on the host running the L3 agent." msgstr "" +#: ../objectstorage-troubleshoot.rst:5 +msgid "" +"For Object Storage, everything is logged in :file:`/var/log/syslog` (or :" +"file:`messages` on some distros). Several settings enable further " +"customization of logging, such as ``log_name``, ``log_facility``, and " +"``log_level``, within the object server configuration files." +msgstr "" + # #-#-#-#-# keystone_integrate_assignment_backend_ldap.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# keystone_integrate_with_ldap.pot (Cloud Administrator Guide 0.9) #-#-#-#-# #: ../keystone_integrate_assignment_backend_ldap.rst:21 @@ -6698,6 +6746,12 @@ msgid "" "admin password on boot by installing an agent such as `cloudbase-init`_." msgstr "" +#: ../objectstorage-troubleshoot.rst:144 +msgid "" +"For ``min_part_hours`` you either have to remember what the value you used " +"was, or just make up a new one:" +msgstr "" + #: ../compute-manage-the-cloud.rst:69 msgid "" "For a complete list of ``nova`` commands and parameters, see the `OpenStack " @@ -7832,6 +7886,13 @@ msgid "" "immediately usable location." msgstr "" +#: ../objectstorage-troubleshoot.rst:31 +msgid "" +"If a server is having hardware issues, it is a good idea to make sure the " +"Object Storage services are not running. This will allow Object Storage to " +"work around the failure while you troubleshoot." +msgstr "" + #: ../blockstorage_multi_backend.rst:158 msgid "" "If a volume type points to a ``volume_backend_name`` that does not exist in " @@ -7968,6 +8029,25 @@ msgid "" "type`` and meter name should be matched accordingly." msgstr "" +#: ../objectstorage-troubleshoot.rst:41 +msgid "" +"If the server has more serious issues, then it is probably best to remove " +"all of the server's devices from the ring. Once the server has been repaired " +"and is back online, the server's devices can be added back into the ring. It " +"is important that the devices are reformatted before putting them back into " +"the ring as it is likely to be responsible for a different set of partitions " +"than before." +msgstr "" + +#: ../objectstorage-troubleshoot.rst:35 +msgid "" +"If the server just needs a reboot, or a small amount of work that should " +"only last a couple of hours, then it is probably best to let Object Storage " +"work around the failure and get the machine fixed and back online. When the " +"machine comes back online, replication will make sure that anything that is " +"missing during the downtime will get updated." +msgstr "" + #: ../cross_project_cors.rst:169 msgid "" "If the service does not return any access control headers, check the service " @@ -8132,6 +8212,14 @@ msgstr "" msgid "If you cannot reach your instances through the floating IP address:" msgstr "" +#: ../objectstorage-troubleshoot.rst:19 +msgid "" +"If you cannot replace the drive immediately, then it is best to leave it " +"unmounted, and remove the drive from the ring. This will allow all the " +"replicas that were on that drive to be replicated elsewhere until the drive " +"is replaced. Once the drive is replaced, it can be re-added to the ring." +msgstr "" + #: ../blockstorage_backup_disks.rst:139 msgid "" "If you created more than one partition on that volume, you see several " @@ -8762,6 +8850,15 @@ msgid "" "definition looks like the following::" msgstr "" +#: ../objectstorage-troubleshoot.rst:13 +msgid "" +"In the event that a drive has failed, the first step is to make sure the " +"drive is unmounted. This will make it easier for Object Storage to work " +"around the failure until it has been resolved. If the drive is going to be " +"replaced immediately, then it is just best to replace the drive, format it, " +"remount it, and let replication fill it up." +msgstr "" + #: ../compute-networking-nova.rst:938 msgid "" "In the first terminal, on the host running ``nova-network``, use ``tcpdump`` " @@ -9160,6 +9257,16 @@ msgid "" "kafka_broker_port?topic=kafka_topic &option1=value1``." msgstr "" +#: ../objectstorage-troubleshoot.rst:51 +msgid "" +"It has been our experience that when a drive is about to fail, error " +"messages appear in :file:`/var/log/kern.log`. There is a script called " +"``swift-drive-audit`` that can be run via cron to watch for bad drives. If " +"errors are detected, it will unmount the bad drive, so that Object Storage " +"can work around it. The script takes a configuration file with the following " +"settings:" +msgstr "" + #: ../telemetry-events.rst:24 msgid "" "It is advisable to set ``disable_non_metric_meters`` to ``True`` when " @@ -9593,6 +9700,10 @@ msgstr "" msgid "Lists the value of created metering label rules." msgstr "" +#: ../objectstorage-troubleshoot.rst:112 +msgid "Load the ring and a new ringbuilder object in a Python REPL:" +msgstr "" + #: ../telemetry-measurements.rst:1049 msgid "Load-Balancer-as-a-Service (LBaaS)" msgstr "" @@ -9651,12 +9762,22 @@ msgid "" "ssl/private/signing_key.pem`." msgstr "" +#: ../objectstorage-troubleshoot.rst:72 +msgid "" +"Location of the log file with globbing pattern to check against device " +"errors locate device blocks with errors in the log file" +msgstr "" + #: ../keystone_certificates_for_pki.rst:46 msgid "" "Location of the private key used by the CA. Default is :file:`/etc/keystone/" "ssl/private/cakey.pem`." msgstr "" +#: ../objectstorage-troubleshoot.rst:68 +msgid "Location where syslog sends the logs to" +msgstr "" + #: ../networking_use.rst:15 msgid "Log files are in the :file:`/var/log/neutron` directory." msgstr "" @@ -9708,6 +9829,10 @@ msgstr "" msgid "Logging in Telemetry" msgstr "" +#: ../objectstorage-troubleshoot.rst:75 +msgid "Logging level" +msgstr "" + #: ../compute-manage-logs.rst:8 msgid "Logging module" msgstr "" @@ -10240,6 +10365,11 @@ msgstr "" msgid "No central database" msgstr "" +#: ../objectstorage-troubleshoot.rst:80 ../objectstorage-troubleshoot.rst:86 +#: ../objectstorage-troubleshoot.rst:88 +msgid "No help text available for this option." +msgstr "" + #: ../objectstorage_features.rst:12 msgid "No lock-in, lower price/GB." msgstr "" @@ -10481,6 +10611,10 @@ msgstr "" msgid "Number of delet\\ es on the image" msgstr "" +#: ../objectstorage-troubleshoot.rst:66 +msgid "Number of errors to find before a device is unmounted" +msgstr "" + #: ../telemetry-measurements.rst:1081 msgid "Number of incom\\ ing Bytes" msgstr "" @@ -10501,6 +10635,10 @@ msgstr "" msgid "Number of indices created in a table" msgstr "" +#: ../objectstorage-troubleshoot.rst:82 +msgid "Number of minutes to look back in :file:`/var/log/kern.log`" +msgstr "" + #: ../telemetry-measurements.rst:750 msgid "Number of objec\\ ts" msgstr "" @@ -12111,6 +12249,12 @@ msgstr "" msgid "Repeat all steps for the :file:`libvirt-qemu` files, if required." msgstr "" +#: ../objectstorage-troubleshoot.rst:175 +msgid "" +"Repeat the procedure for :file:`container.ring.gz` and :file:`object.ring." +"gz`, and you might get usable builder files." +msgstr "" + #: ../blockstorage_backup_disks.rst:207 msgid "Repeat these steps for all your volumes." msgstr "" @@ -12743,6 +12887,10 @@ msgstr "" msgid "Serial console" msgstr "" +#: ../objectstorage-troubleshoot.rst:29 +msgid "Server failure" +msgstr "" + #: ../identity_concepts.rst:240 msgid "Service management" msgstr "" @@ -13233,6 +13381,10 @@ msgstr "" msgid "Start DHCP agent on HostB. The VM gets the wanted IP again." msgstr "" +#: ../objectstorage-troubleshoot.rst:120 +msgid "Start copying the data we have in the ring into the builder:" +msgstr "" + #: ../identity_start.rst:2 msgid "Start the Identity services" msgstr "" @@ -13410,6 +13562,10 @@ msgstr "" msgid "Syslog" msgstr "" +#: ../objectstorage-troubleshoot.rst:70 +msgid "Syslog log facility" +msgstr "" + #: ../compute-system-admin.rst:5 msgid "System administration" msgstr "" @@ -17621,6 +17777,12 @@ msgid "" "cinder.conf` to connect to the EQL array." msgstr "" +#: ../objectstorage-troubleshoot.rst:109 +msgid "" +"This procedure is a last-resort for emergency circumstances. It requires " +"knowledge of the swift python code and may not succeed." +msgstr "" + #: ../compute-default-ports.rst:11 msgid "" "This procedure modifies the iptables firewall to allow incoming connections " @@ -17647,6 +17809,12 @@ msgid "" "code:`admin_password` options:" msgstr "" +#: ../objectstorage-troubleshoot.rst:92 +msgid "" +"This script has only been tested on Ubuntu 10.04; use with caution on other " +"operating systems in production." +msgstr "" + #: ../telemetry-data-collection.rst:817 msgid "" "This script outputs what volumes or snapshots were created, deleted, or " @@ -18712,6 +18880,10 @@ msgid "" "uniform client experience." msgstr "" +#: ../objectstorage-troubleshoot.rst:3 +msgid "Troubleshoot Object Storage" +msgstr "" + #: ../telemetry-troubleshooting-guide.rst:2 msgid "Troubleshoot Telemetry" msgstr "" @@ -19420,6 +19592,14 @@ msgid "" "for a VM user. For example:" msgstr "" +#: ../objectstorage-troubleshoot.rst:102 +msgid "" +"Using existing swift tools, there is no way to recover a builder file from " +"a :file:`ring.gz` file. However, if you have a knowledge of Python, it is " +"possible to construct a builder file that is pretty close to the one you " +"have lost." +msgstr "" + #: ../compute-networking-nova.rst:786 msgid "Using multinic" msgstr "" @@ -19537,6 +19717,11 @@ msgstr "" msgid "Valid values are:" msgstr "" +#: ../objectstorage-troubleshoot.rst:151 +msgid "" +"Validate the builder. If this raises an exception, check your previous code:" +msgstr "" + # #-#-#-#-# compute-live-migration-usage.pot (Cloud Administrator Guide 0.9) #-#-#-#-# # #-#-#-#-# networking_adv-config.pot (Cloud Administrator Guide 0.9) #-#-#-#-# #: ../compute-live-migration-usage.rst:59 ../networking_adv-config.rst:26 @@ -20411,6 +20596,12 @@ msgid "" "tweak, like ``threads`` and ``processes`` in case of ``WSGIDaemon``." msgstr "" +#: ../objectstorage-troubleshoot.rst:25 +msgid "" +"You can look at error messages in :file:`/var/log/kern.log` for hints of " +"drive failure." +msgstr "" + #: ../networking_use.rst:5 msgid "" "You can manage OpenStack Networking services by using the service command. " @@ -20728,6 +20919,13 @@ msgid "" "unique ID for a file. If the checksums are different, the file is corrupted." msgstr "" +#: ../objectstorage-troubleshoot.rst:98 +msgid "" +"You should always keep a backup of swift ring builder files. However, if an " +"emergency occurs, this procedure may assist in returning your cluster to an " +"operational state." +msgstr "" + #: ../objectstorage_arch.rst:73 msgid "" "You should keep in mind the desired I/O performance for single-threaded " @@ -20736,6 +20934,17 @@ msgid "" "rates." msgstr "" +#: ../objectstorage-troubleshoot.rst:167 +msgid "" +"You should now have a file called :file:`account.builder` in the current " +"working directory. Run :command:`swift-ring-builder account.builder " +"write_ring` and compare the new :file:`account.ring.gz` to the :file:" +"`account.ring.gz` that you started from. They probably are not byte-for-byte " +"identical, but if you load them in a REPL and their ``_replica2part2dev_id`` " +"and ``devs`` attributes are the same (or nearly so), then you are in good " +"shape." +msgstr "" + #: ../compute-remote-console-access.rst:289 msgid "" "Your :file:`nova-compute` configuration file must set the following values:" @@ -21349,6 +21558,10 @@ msgstr "" msgid "``demand``" msgstr "" +#: ../objectstorage-troubleshoot.rst:63 +msgid "``device_dir = /srv/node``" +msgstr "" + #: ../keystone_token-binding.rst:35 msgid "``disabled``" msgstr "" @@ -21373,6 +21586,10 @@ msgstr "" msgid "``enabled = False``" msgstr "" +#: ../objectstorage-troubleshoot.rst:65 +msgid "``error_limit = 1``" +msgstr "" + #: ../telemetry-data-retrieval.rst:48 msgid "``field``" msgstr "" @@ -21430,6 +21647,30 @@ msgstr "" msgid "``keystone.common.cache.backends.mongo``" msgstr "" +#: ../objectstorage-troubleshoot.rst:67 +msgid "``log_address = /dev/log``" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:69 +msgid "``log_facility = LOG_LOCAL0``" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:71 +msgid "``log_file_pattern = /var/log/kern.*[!.][!g][!z]``" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:74 +msgid "``log_level = INFO``" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:76 +msgid "``log_max_line_length = 0``" +msgstr "" + +#: ../objectstorage-troubleshoot.rst:79 +msgid "``log_to_console = False``" +msgstr "" + #: ../telemetry-data-retrieval.rst:481 msgid "``max_bytes``" msgstr "" @@ -21477,6 +21718,10 @@ msgstr "" msgid "``min``" msgstr "" +#: ../objectstorage-troubleshoot.rst:81 +msgid "``minutes = 60``" +msgstr "" + #: ../database.rst:159 msgid "``mysql-5.5``" msgstr "" @@ -21631,10 +21876,18 @@ msgstr "" msgid "``project_id``: project" msgstr "" +#: ../objectstorage-troubleshoot.rst:83 +msgid "``recon_cache_path = /var/cache/swift``" +msgstr "" + #: ../compute-remote-console-access.rst:164 msgid "``record = False``" msgstr "" +#: ../objectstorage-troubleshoot.rst:85 +msgid "``regex_pattern_1 = \\berror\\b.*\\b(dm-[0-9]{1,2}\\d?)\\b``" +msgstr "" + #: ../keystone_token-binding.rst:48 msgid "``required``" msgstr "" @@ -21737,6 +21990,10 @@ msgstr "" msgid "``type``" msgstr "" +#: ../objectstorage-troubleshoot.rst:87 +msgid "``unmount_failed_device = True``" +msgstr "" + #: ../objectstorage-monitoring.rst:168 msgid "" "``update_stats(self, metric, amount, sample_rate=1)`` Increments the " diff --git a/doc/arch-design/locale/arch-design.pot b/doc/arch-design/locale/arch-design.pot index ec6388aba4..314ec81099 100644 --- a/doc/arch-design/locale/arch-design.pot +++ b/doc/arch-design/locale/arch-design.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2015-08-17 06:35+0000\n" +"POT-Creation-Date: 2015-08-19 06:15+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -97,23 +97,23 @@ msgstr "" msgid "This chapter discusses the legal and security requirements you need to consider for the different OpenStack scenarios." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:12(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:73(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title) +#: ./doc/arch-design/ch_legal-security-requirements.xml:12(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:77(title) msgid "Legal requirements" msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:13(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:13(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:74(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:13(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:78(para) msgid "Many jurisdictions have legislative and regulatory requirements governing the storage and management of data in cloud environments. Common areas of regulation include:" msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:18(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:18(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:79(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:18(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:83(para) msgid "Data retention policies ensuring storage of persistent data and records management to meet data archival requirements." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:23(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:23(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:84(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:23(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:88(para) msgid "Data ownership policies governing the possession and responsibility for data." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:27(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:27(para) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:88(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:92(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:27(para) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:92(para) msgid "Data sovereignty policies governing the storage of data in foreign countries or otherwise separate jurisdictions." msgstr "" @@ -125,7 +125,7 @@ msgstr "" msgid "Examples of such legal frameworks include the data protection framework of the European Union and the requirements of the Financial Industry Regulatory Authority in the United States. Consult a local regulatory body for more information." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:48(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:47(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:432(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:267(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:154(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:90(title) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:112(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:760(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term) +#: ./doc/arch-design/ch_legal-security-requirements.xml:48(title) ./doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml:47(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:432(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:154(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:112(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:630(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:760(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:191(term) msgid "Security" msgstr "" @@ -141,7 +141,7 @@ msgstr "" msgid "It's important to understand that user authentication requests encase sensitive information such as user names, passwords, and authentication tokens. For this reason, place the API services behind hardware that performs SSL termination." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:69(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:152(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:69(para) msgid "Be mindful of consistency when utilizing third party clouds to explore authentication options." msgstr "" @@ -177,7 +177,7 @@ msgstr "" msgid "Management security domains" msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:113(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:135(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:113(para) msgid "The management security domain is where services interact. The networks in this domain transport confidential data such as configuration parameters, user names, and passwords. Trust this domain when it is behind an organization's firewall in deployments." msgstr "" @@ -185,7 +185,7 @@ msgstr "" msgid "Data security domains" msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:120(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:139(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:120(para) msgid "The data security domain is concerned primarily with information pertaining to the storage services within OpenStack. The data that crosses this network has integrity and confidentiality requirements. Depending on the type of deployment there may also be availability requirements. The trust level of this network is heavily dependent on deployment decisions and does not have a default level of trust." msgstr "" @@ -197,7 +197,7 @@ msgstr "" msgid "The hypervisor also requires a security assessment. In a public cloud, organizations typically do not have control over the choice of hypervisor. For example, Amazon uses its own particular version of Xen. Properly securing your hypervisor is important. Attacks made upon the unsecured hypervisor are called a hypervisor breakout. Hypervisor breakout describes the event of a compromised or malicious instance breaking out of the resource controls of the hypervisor and gaining access to the bare metal operating system and hardware resources." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:142(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:167(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:142(para) msgid "There is not an issue if the security of instances is not important. However, enterprises need to avoid vulnerability. The only way to do this is to avoid the situation where the instances are running on a public cloud. That does not mean that there is a need to own all of the infrastructure on which an OpenStack installation operates; it suggests avoiding situations in which sharing hardware with others occurs." msgstr "" @@ -205,15 +205,15 @@ msgstr "" msgid "Baremetal security" msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:152(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:174(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:152(para) msgid "There are other services worth considering that provide a bare metal instance instead of a cloud. In other cases, it is possible to replicate a second private cloud by integrating with a private Cloud-as-a-Service deployment. The organization does not buy the hardware, but also does not share with other tenants. It is also possible to use a provider that hosts a bare-metal \"public\" cloud instance for which the hardware is dedicated only to one customer, or a provider that offers private Cloud-as-a-Service." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:161(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:183(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:161(para) msgid "It is important to realize that each cloud implements services differently. What keeps data secure in one cloud may not do the same in another. Be sure to know the security requirements of every cloud that handles the organization's data or workloads." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:166(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:188(para) +#: ./doc/arch-design/ch_legal-security-requirements.xml:166(para) msgid "More information on OpenStack Security can be found in the OpenStack Security Guide." msgstr "" @@ -257,7 +257,7 @@ msgstr "" msgid "Just as tenants in a single-site deployment need isolation from each other, so do tenants in multi-site installations. The extra challenges in multi-site designs revolve around ensuring that tenant networks function across regions. Unfortunately, OpenStack Networking does not presently support a mechanism to provide this functionality, therefore an external system may be necessary to manage these mappings. Tenant networks may contain sensitive information requiring that this mapping be accurate and consistent to ensure that a tenant in one site does not connect to a different tenant in another site." msgstr "" -#: ./doc/arch-design/ch_legal-security-requirements.xml:226(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:361(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:470(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:358(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:166(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:487(title) +#: ./doc/arch-design/ch_legal-security-requirements.xml:226(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:361(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:470(title) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:219(title) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:166(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:144(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:560(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:667(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:487(title) msgid "OpenStack components" msgstr "" @@ -325,7 +325,7 @@ msgstr "" msgid "These types of applications are sensitive to network configurations. Examples include financial systems, credit card transaction applications, and trading and other extremely high volume systems. These systems are sensitive to network jitter and latency. They must balance a high volume of East-West and North-South network traffic to maximize efficiency of the data delivery. Many of these systems must access large, high performance database back ends." msgstr "" -#: ./doc/arch-design/ch_network_focus.xml:78(term) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:86(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:178(term) +#: ./doc/arch-design/ch_network_focus.xml:78(term) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:48(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:132(term) msgid "High availability" msgstr "" @@ -566,22 +566,22 @@ msgid "Multi-site" msgstr "" #: ./doc/arch-design/ch_multi_site.xml:9(para) -msgid "A multi-site OpenStack environment is one in which services, located in more than one data center, are used to provide the overall solution. Usage requirements of different multi-site clouds may vary widely, but they share some common needs. OpenStack is capable of running in a multi-region configuration. This enables some parts of OpenStack to effectively manage a group of sites as a single cloud. With careful planning in the design phase, OpenStack can act as an excellent multi-site cloud solution for a multitude of needs." +msgid "OpenStack is capable of running in a multi-region configuration. This enables some parts of OpenStack to effectively manage a group of sites as a single cloud." msgstr "" -#: ./doc/arch-design/ch_multi_site.xml:19(para) +#: ./doc/arch-design/ch_multi_site.xml:12(para) msgid "Some use cases that might indicate a need for a multi-site deployment of OpenStack include:" msgstr "" -#: ./doc/arch-design/ch_multi_site.xml:23(para) +#: ./doc/arch-design/ch_multi_site.xml:16(para) msgid "An organization with a diverse geographic footprint." msgstr "" -#: ./doc/arch-design/ch_multi_site.xml:27(para) +#: ./doc/arch-design/ch_multi_site.xml:20(para) msgid "Geo-location sensitive data." msgstr "" -#: ./doc/arch-design/ch_multi_site.xml:30(para) +#: ./doc/arch-design/ch_multi_site.xml:23(para) msgid "Data locality, in which specific data or functionality should be close to users." msgstr "" @@ -589,44 +589,48 @@ msgstr "" msgid "Hybrid" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:9(para) -msgid "Hybrid cloud, by definition, means that the design spans more than one cloud. An example of this kind of architecture may include a situation in which the design involves more than one OpenStack cloud (for example, an OpenStack-based private cloud and an OpenStack-based public cloud), or it may be a situation incorporating an OpenStack cloud and a non-OpenStack cloud (for example, an OpenStack-based private cloud that interacts with Amazon Web Services). Bursting into an external cloud is the practice of creating new instances to alleviate extra load where there is no available capacity in the private cloud." +#: ./doc/arch-design/ch_hybrid.xml:8(para) +msgid "A hybrid cloud design is one that uses more than one cloud. For example, designs that use both an OpenStack-based private cloud and an OpenStack-based public cloud, or that use an OpenStack cloud and a non-OpenStack cloud, are hybrid clouds." msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:22(para) -msgid "Some situations that could involve hybrid cloud architecture include:" +#: ./doc/arch-design/ch_hybrid.xml:13(para) +msgid "Bursting describes the practice of creating new instances in an external cloud to alleviate capacity issues in a private cloud." msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:26(para) +#: ./doc/arch-design/ch_hybrid.xml:17(title) +msgid "Example scenarios suited to hybrid clouds" +msgstr "" + +#: ./doc/arch-design/ch_hybrid.xml:19(para) msgid "Bursting from a private cloud to a public cloud" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:30(para) +#: ./doc/arch-design/ch_hybrid.xml:23(para) msgid "Disaster recovery" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:33(para) +#: ./doc/arch-design/ch_hybrid.xml:26(para) msgid "Development and testing" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:36(para) +#: ./doc/arch-design/ch_hybrid.xml:29(para) msgid "Federated cloud, enabling users to choose resources from multiple providers" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:40(para) -msgid "Hybrid clouds built to support legacy systems as they transition to cloud" +#: ./doc/arch-design/ch_hybrid.xml:33(para) +msgid "Supporting legacy systems as they transition to the cloud" msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:44(para) -msgid "As a hybrid cloud design deals with systems that are outside of the control of the cloud architect or organization, a hybrid cloud architecture requires considering aspects of the architecture that might not have otherwise been necessary. For example, the design may need to deal with hardware, software, and APIs under the control of a separate organization." +#: ./doc/arch-design/ch_hybrid.xml:37(para) +msgid "Hybrid clouds interact with systems that are outside the control of the private cloud administrator, and require careful architecture to prevent conflicts with hardware, software, and APIs under external control." msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:50(para) -msgid "Similarly, the degree to which the architecture is OpenStack-based will have an effect on the cloud operator or cloud consumer's ability to accomplish tasks with native OpenStack tools. By definition, this is a situation in which no single cloud can provide all of the necessary functionality. In order to manage the entire system, users, operators and consumers will need an overarching tool known as a cloud management platform (CMP). Any organization that is working with multiple clouds already has a CMP, even if that CMP is the operator who logs into an external web portal and launches a public cloud instance." +#: ./doc/arch-design/ch_hybrid.xml:41(para) +msgid "The degree to which the architecture is OpenStack-based affects your ability to accomplish tasks with native OpenStack tools. By definition, this is a situation in which no single cloud can provide all of the necessary functionality. In order to manage the entire system, we recommend using a cloud management platform (CMP)." msgstr "" -#: ./doc/arch-design/ch_hybrid.xml:61(para) -msgid "There are commercially available options, such as Rightscale, and open source options, such as ManageIQ (http://manageiq.org), but there is no single CMP that can address all needs in all scenarios. Whereas most of the sections of this book talk about the aspects of OpenStack, an architect needs to consider when designing an OpenStack architecture. This section will also discuss the things the architect must address when choosing or building a CMP to run a hybrid cloud design, even if the CMP will be a manually built solution." +#: ./doc/arch-design/ch_hybrid.xml:47(para) +msgid "There are several commercial and open source CMPs available, but there is no single CMP that can address all needs in all scenarios, and sometimes a manually-built solution is the best option. This chapter includes discussion of using CMPs for managing a hybrid cloud." msgstr "" #: ./doc/arch-design/ch_massively_scalable.xml:7(title) @@ -673,7 +677,7 @@ msgstr "" msgid "Like a general purpose cloud, the instances deployed in a massively scalable OpenStack cloud do not necessarily use any specific aspect of the cloud offering (compute, network, or storage). As the cloud grows in scale, the number of workloads can cause stress on all the cloud components. This adds further stresses to supporting infrastructure such as databases and message brokers. The architecture design for such a cloud must account for these performance pressures without negatively impacting user experience." msgstr "" -#: ./doc/arch-design/ch_references.xml:8(title) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:150(title) +#: ./doc/arch-design/ch_references.xml:8(title) msgid "References" msgstr "" @@ -1373,7 +1377,7 @@ msgstr "" msgid "When designing a network architecture, the traffic patterns of an application heavily influence the allocation of total bandwidth and the number of links that you use to send and receive traffic. Applications that provide file storage for customers allocate bandwidth and links to favor incoming traffic, whereas video streaming applications allocate bandwidth and links to favor outgoing traffic." msgstr "" -#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:415(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(term) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:258(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:114(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:228(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:572(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term) +#: ./doc/arch-design/network_focus/section_tech_considerations_network_focus.xml:415(title) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:18(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:42(term) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:118(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:108(title) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:387(term) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:572(title) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:120(term) msgid "Performance" msgstr "" @@ -1433,7 +1437,7 @@ msgstr "" msgid "Configuring incorrect IP addresses, VLANs, and routers can cause outages to areas of the network or, in the worst-case scenario, the entire cloud infrastructure. Automate network configurations to minimize the opportunity for operator error as it can cause disruptive problems." msgstr "" -#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:53(term) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:55(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:58(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:107(title) +#: ./doc/arch-design/network_focus/section_user_requirements_network_focus.xml:53(term) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:55(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:51(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:107(title) msgid "Capacity planning" msgstr "" @@ -1907,7 +1911,7 @@ msgstr "" msgid "Consider the following factors when selecting storage hardware:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:15(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:35(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:147(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:384(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:35(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:142(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:139(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:17(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:99(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:259(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:583(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:24(term) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:15(para) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:35(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:147(term) ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:384(term) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:35(para) ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:142(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:99(title) ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:17(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:99(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:259(term) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:583(term) ./doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml:24(term) msgid "Cost" msgstr "" @@ -2259,7 +2263,7 @@ msgstr "" msgid "A storage-focused OpenStack design architecture typically uses the following components:" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:488(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:371(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:488(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:232(para) msgid "OpenStack Identity (keystone)" msgstr "" @@ -2275,11 +2279,11 @@ msgstr "" msgid "OpenStack Object Storage (swift) (or another object storage solution)" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:502(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:402(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:502(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:257(para) msgid "OpenStack Block Storage (cinder)" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:505(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:368(para) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:505(para) ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:229(para) msgid "OpenStack Image service (glance)" msgstr "" @@ -2319,7 +2323,7 @@ msgstr "" msgid "Logging" msgstr "" -#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:559(para) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:124(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:34(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:56(title) +#: ./doc/arch-design/storage_focus/section_architecture_storage_focus.xml:559(para) ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:136(title) ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:34(title) ./doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml:56(title) msgid "Monitoring" msgstr "" @@ -2385,313 +2389,217 @@ msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:235(None) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:194(None) msgid "@@image: '../figures/Compute_Tech_Bin_Packing_General1.png'; md5=34f2f0b656a66124016d2484fb96068b" msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:243(None) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:202(None) msgid "@@image: '../figures/Compute_Tech_Bin_Packing_CPU_optimized1.png'; md5=45084140c29e59a459d6b0af9b47642a" msgstr "" #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:13(para) -msgid "In a compute-focused OpenStack cloud, the type of instance workloads you provision heavily influences technical decision making. For example, specific use cases that demand multiple, short-running jobs present different requirements than those that specify long-running jobs, even though both situations are compute focused." +msgid "In a compute-focused OpenStack cloud, the type of instance workloads you provision heavily influences technical decision making." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:19(para) -msgid "Public and private clouds require deterministic capacity planning to support elastic growth in order to meet user SLA expectations. Deterministic capacity planning is the path to predicting the effort and expense of making a given process perform consistently. This process is important because, when a service becomes a critical part of a user's infrastructure, the user's experience links directly to the SLAs of the cloud itself. In cloud computing, it is not average speed but speed consistency that determines a service's performance. There are two aspects of capacity planning to consider:" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:16(para) +msgid "Public and private clouds require deterministic capacity planning to support elastic growth in order to meet user SLA expectations. Deterministic capacity planning is the path to predicting the effort and expense of making a given process perform consistently. This process is important because, when a service becomes a critical part of a user's infrastructure, the user's experience links directly to the SLAs of the cloud itself." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:31(para) -msgid "planning the initial deployment footprint" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:24(para) +msgid "There are two aspects of capacity planning to consider:" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:27(para) +msgid "Planning the initial deployment footprint" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:30(para) +msgid "Planning expansion of the environment to stay ahead of the demands of cloud users" msgstr "" #: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:34(para) -msgid "planning expansion of it to stay ahead of the demands of cloud users" +msgid "Begin planning an initial OpenStack deployment footprint with estimations of expected uptake, and existing infrastructure workloads." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:38(para) -msgid "Plan the initial footprint for an OpenStack deployment based on existing infrastructure workloads and estimates based on expected uptake." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:41(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:36(para) msgid "The starting point is the core count of the cloud. By applying relevant ratios, the user can gather information about:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:46(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:41(para) msgid "The number of expected concurrent instances: (overcommit fraction × cores) / virtual cores per instance" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:50(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:45(para) msgid "Required storage: flavor disk size × number of instances" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:53(para) -msgid "Use these ratios to determine the amount of additional infrastructure needed to support the cloud. For example, consider a situation in which you require 1600 instances, each with 2 vCPU and 50 GB of storage. Assuming the default overcommit rate of 16:1, working out the math provides an equation of:" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:48(para) +msgid "These ratios determine the amount of additional infrastructure needed to support the cloud. For example, consider a situation in which you require 1600 instances, each with 2 vCPU and 50 GB of storage. Assuming the default overcommit rate of 16:1, working out the math provides an equation of:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:61(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:56(para) msgid "1600 = (16 (number of physical cores)) / 2" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:64(para) -msgid "storage required = 50GB 1600" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:59(para) +msgid "Storage required = 50GB 1600" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:67(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:62(para) msgid "On the surface, the equations reveal the need for 200 physical cores and 80TB of storage for /var/lib/nova/instances/. However, it is also important to look at patterns of usage to estimate the load that the API services, database servers, and queue servers are likely to encounter." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:74(para) -msgid "Consider, for example, the differences between a cloud that supports a managed web-hosting platform and one running integration tests for a development project that creates one instance per code commit. In the former, the heavy work of creating an instance happens only every few months, whereas the latter puts constant heavy load on the cloud controller. The average instance lifetime is significant, as a larger number generally means less load on the cloud controller." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:69(para) +msgid "Aside from the creation and termination of instances, consider the impact of users accessing the service, particularly on nova-api and its associated database. Listing instances gathers a great deal of information and given the frequency with which users run this operation, a cloud with a large number of users can increase the load significantly. This can even occur unintentionally. For example, the OpenStack Dashboard instances tab refreshes the list of instances every 30 seconds, so leaving it open in a browser window can cause unexpected load." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:83(para) -msgid "Aside from the creation and termination of instances, consider the impact of users accessing the service, particularly on nova-api and its associated database. Listing instances gathers a great deal of information and, given the frequency with which users run this operation, a cloud with a large number of users can increase the load significantly. This can even occur unintentionally. For example, the OpenStack Dashboard instances tab refreshes the list of instances every 30 seconds, so leaving it open in a browser window can cause unexpected load." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:93(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:79(para) msgid "Consideration of these factors can help determine how many cloud controller cores you require. A server with 8 CPU cores and 8 GB of RAM server would be sufficient for a rack of compute nodes, given the above caveats." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:97(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:83(para) msgid "Key hardware specifications are also crucial to the performance of user instances. Be sure to consider budget and performance needs, including storage performance (spindles/core), memory availability (RAM/core), network bandwidth (Gbps/core), and overall CPU performance (CPU/core)." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:103(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:89(para) msgid "The cloud resource calculator is a useful tool in examining the impacts of different hardware and instance load outs. See: https://github.com/noslzzp/cloud-resource-calculator/blob/master/cloud-resource-calculator.ods" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:108(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:95(title) msgid "Expansion planning" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:109(para) -msgid "A key challenge for planning the expansion of cloud compute services is the elastic nature of cloud infrastructure demands. Previously, new users or customers had to plan for and request the infrastructure they required ahead of time, allowing time for reactive procurement processes. Cloud computing users have come to expect the agility of having instant access to new resources as required. Consequently, plan for typical usage and for sudden bursts in usage." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:96(para) +msgid "A key challenge for planning the expansion of cloud compute services is the elastic nature of cloud infrastructure demands." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:118(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:99(para) msgid "Planning for expansion is a balancing act. Planning too conservatively can lead to unexpected oversubscription of the cloud and dissatisfied users. Planning for cloud expansion too aggressively can lead to unexpected underutilization of the cloud and funds spent unnecessarily on operating infrastructure." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:124(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:105(para) msgid "The key is to carefully monitor the trends in cloud usage over time. The intent is to measure the consistency with which you deliver services, not the average speed or capacity of the cloud. Using this information to model capacity performance enables users to more accurately determine the current and future capacity of the cloud." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:131(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:115(title) msgid "CPU and RAM" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:132(para) -msgid "Adapted from: http://docs.openstack.org/openstack-ops/content/compute_nodes.html#cpu_choice" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:134(para) -msgid "In current generations, CPUs have up to 12 cores. If an Intel CPU supports Hyper-Threading, those 12 cores double to 24 cores. A server that supports multiple CPUs multiplies the number of available cores. Hyper-Threading is Intel's proprietary simultaneous multi-threading implementation, used to improve parallelization on their CPUs. Consider enabling Hyper-Threading to improve the performance of multithreaded applications." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:143(para) -msgid "Whether the user should enable Hyper-Threading on a CPU depends on the use case. For example, disabling Hyper-Threading can be beneficial in intense computing environments. Running performance tests using local workloads with and without Hyper-Threading can help determine which option is more appropriate in any particular case." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:150(para) -msgid "If they must run the Libvirt or KVM hypervisor drivers, then the compute node CPUs must support virtualization by way of the VT-x extensions for Intel chips and AMD-v extensions for AMD chips to provide full performance." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:155(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:116(para) msgid "OpenStack enables users to overcommit CPU and RAM on compute nodes. This allows an increase in the number of instances running on the cloud at the cost of reducing the performance of the instances. OpenStack Compute uses the following ratios by default:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:162(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:123(para) msgid "CPU allocation ratio: 16:1" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:165(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:126(para) msgid "RAM allocation ratio: 1.5:1" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:168(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:129(para) msgid "The default CPU allocation ratio of 16:1 means that the scheduler allocates up to 16 virtual cores per physical core. For example, if a physical node has 12 cores, the scheduler sees 192 available virtual cores. With typical flavor definitions of 4 virtual cores per instance, this ratio would provide 48 instances on a physical node." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:174(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:135(para) msgid "Similarly, the default RAM allocation ratio of 1.5:1 means that the scheduler allocates instances to a physical node as long as the total amount of RAM associated with the instances is less than 1.5 times the amount of RAM available on the physical node." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:179(para) -msgid "For example, if a physical node has 48 GB of RAM, the scheduler allocates instances to that node until the sum of the RAM associated with the instances reaches 72 GB (such as nine instances, in the case where each instance has 8 GB of RAM)." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:184(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:140(para) msgid "You must select the appropriate CPU and RAM allocation ratio based on particular use cases." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:187(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:145(title) msgid "Additional hardware" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:188(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:146(para) msgid "Certain use cases may benefit from exposure to additional devices on the compute node. Examples might include:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:192(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:150(para) msgid "High performance computing jobs that benefit from the availability of graphics processing units (GPUs) for general-purpose computing." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:199(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:155(para) msgid "Cryptographic routines that benefit from the availability of hardware random number generators to avoid entropy starvation." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:204(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:160(para) msgid "Database management systems that benefit from the availability of SSDs for ephemeral storage to maximize read/write time." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:209(para) -msgid "Host aggregates group hosts that share similar characteristics, which can include hardware similarities. The addition of specialized hardware to a cloud deployment is likely to add to the cost of each node, so consider carefully consideration whether all compute nodes, or just a subset targeted by flavors, need the additional customization to support the desired workloads." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:165(para) +msgid "Host aggregates group hosts that share similar characteristics, which can include hardware similarities. The addition of specialized hardware to a cloud deployment is likely to add to the cost of each node, so consider carefully whether all compute nodes, or just a subset targeted by flavors, need the additional customization to support the desired workloads." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:217(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:79(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:196(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:176(title) ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:86(title) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:80(title) msgid "Utilization" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:218(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:177(para) msgid "Infrastructure-as-a-Service offerings, including OpenStack, use flavors to provide standardized views of virtual machine resource requirements that simplify the problem of scheduling instances while making the best use of the available physical resources." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:223(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:182(para) msgid "In order to facilitate packing of virtual machines onto physical hosts, the default selection of flavors provides a second largest flavor that is half the size of the largest flavor in every dimension. It has half the vCPUs, half the vRAM, and half the ephemeral disk space. The next largest flavor is half that size again. The following figure provides a visual representation of this concept for a general purpose computing design: " msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:238(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:197(para) msgid "The following figure displays a CPU-optimized, packed server: " msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:246(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:205(para) msgid "These default flavors are well suited to typical configurations of commodity server hardware. To maximize utilization, however, it may be necessary to customize the flavors or create new ones in order to better align instance sizes to the available hardware." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:251(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:210(para) msgid "Workload characteristics may also influence hardware choices and flavor configuration, particularly where they present different ratios of CPU versus RAM versus HDD requirements." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:255(para) -msgid "For more information on Flavors see: http://docs.openstack.org/openstack-ops/content/flavors.html" +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:214(para) +msgid "For more information on Flavors see: OpenStack Operations Guide: Flavors" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:259(para) -msgid "So that workloads can consume as many resources as are available, do not share cloud infrastructure. Ensure you accommodate large scale workloads." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:262(para) -msgid "The duration of batch processing differs depending on individual workloads. Time limits range from seconds to hours, and as a result it is difficult to predict resource use." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(para) -msgid "The security considerations for this scenario are similar to those of the other scenarios in this guide." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:270(para) -msgid "A security domain comprises users, applications, servers, and networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization requirements and users." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:275(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:765(para) -msgid "These security domains are:" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:278(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:99(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:768(para) -msgid "Public" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:281(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:102(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:771(para) -msgid "Guest" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:284(para) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:158(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:105(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:774(para) -msgid "Management" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:287(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:108(para) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:168(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:777(para) -msgid "Data" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:290(para) -msgid "You can map these security domains individually to the installation, or combine them. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separate. In each case, the cloud operator should be aware of the appropriate security concerns. Map out security domains against specific OpenStack deployment topology. The domains and their trust requirements depend on whether the cloud instance is public, private, or hybrid." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:300(para) -msgid "The public security domain is an untrusted area of the cloud infrastructure. It can refer to the Internet as a whole or simply to networks over which the user has no authority. Always consider this domain untrusted." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:304(para) -msgid "Typically used for compute instance-to-instance traffic, the guest security domain handles compute data generated by instances on the cloud. It does not handle services that support the operation of the cloud, for example API calls. Public cloud providers and private cloud providers who do not have stringent controls on instance use or who allow unrestricted Internet access to instances should consider this an untrusted domain. Private cloud providers may want to consider this an internal network and therefore trusted only if they have controls in place to assert that they trust instances and all their tenants." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:315(para) -msgid "The management security domain is where services interact. Sometimes referred to as the \"control plane\", the networks in this domain transport confidential data such as configuration parameters, user names, and passwords. In most deployments this is a trusted domain." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:320(para) -msgid "The data security domain deals with information pertaining to the storage services within OpenStack. Much of the data that crosses this network has high integrity and confidentiality requirements and depending on the type of deployment there may also be strong availability requirements. The trust level of this network is heavily dependent on deployment decisions and as such we do not assign this a default level of trust." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:328(para) -msgid "When deploying OpenStack in an enterprise as a private cloud, you can generally assume it is behind a firewall and within the trusted network alongside existing systems. Users of the cloud are typically employees or trusted individuals that are bound by the security requirements set forth by the company. This tends to push most of the security domains towards a more trusted model. However, when deploying OpenStack in a public-facing role, you cannot make these assumptions and the number of attack vectors significantly increases. For example, the API endpoints and the software behind it become vulnerable to hostile entities attempting to gain unauthorized access or prevent access to services. This can result in loss of reputation and you must protect against it through auditing and appropriate filtering." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:342(para) -msgid "Take care when managing the users of the system, whether in public or private clouds. The identity service enables LDAP to be part of the authentication process, and includes such systems as an OpenStack deployment that may ease user management if integrated into existing systems." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:348(para) -msgid "We recommend placing API services behind hardware that performs SSL termination. API services transmit user names, passwords, and generated tokens between client machines and API endpoints and therefore must be secure." -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:353(para) -msgid "For more information on OpenStack Security, see http://docs.openstack.org/security-guide/" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:359(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:220(para) msgid "Due to the nature of the workloads in this scenario, a number of components are highly beneficial for a Compute-focused cloud. This includes the typical OpenStack components:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:365(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:226(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:136(term) msgid "OpenStack Compute (nova)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:374(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:235(para) msgid "Also consider several specialized components:" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:377(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:238(para) msgid "Orchestration module (heat)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:381(para) -msgid "It is safe to assume that, given the nature of the applications involved in this scenario, these are heavily automated deployments. Making use of Orchestration is highly beneficial in this case. You can script the deployment of a batch of instances and the running of tests, but it makes sense to use the Orchestration module to handle all these actions." +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:240(para) +msgid "Given the nature of the applications involved in this scenario, these are heavily automated deployments. Making use of Orchestration is highly beneficial in this case. You can script the deployment of a batch of instances and the running of tests, but it makes sense to use the Orchestration module to handle all these actions." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:390(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:249(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:153(term) msgid "Telemetry module (ceilometer)" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:393(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:250(para) msgid "Telemetry and the alarms it generates support autoscaling of instances using Orchestration. Users that are not using the Orchestration module do not need to deploy the Telemetry module and may choose to use external solutions to fulfill their metering and monitoring requirements." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:398(para) -msgid "See also: http://docs.openstack.org/openstack-ops/content/logging_monitoring.html" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:405(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:258(para) msgid "Due to the burst-able nature of the workloads and the applications and instances that perform batch processing, this cloud mainly uses memory or CPU, so the need for add-on storage to each instance is not a likely requirement. This does not mean that you do not use OpenStack Block Storage (cinder) in the infrastructure, but typically it is not a central component." msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:414(para) ./doc/arch-design/multi_site/section_architecture_multi_site.xml:86(title) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:267(para) ./doc/arch-design/multi_site/section_architecture_multi_site.xml:89(title) msgid "Networking" msgstr "" -#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:417(para) +#: ./doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml:268(para) msgid "When choosing a networking platform, ensure that it either works with all desired hypervisor and container technologies and their OpenStack drivers, or that it includes an implementation of an ML2 mechanism driver. You can mix networking platforms that provide ML2 mechanisms drivers." msgstr "" @@ -2707,7 +2615,7 @@ msgstr "" msgid "Network" msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para) ./doc/arch-design/multi_site/section_architecture_multi_site.xml:53(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:155(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:27(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:18(para) ./doc/arch-design/multi_site/section_architecture_multi_site.xml:57(title) ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:114(para) ./doc/arch-design/generalpurpose/section_architecture_general_purpose.xml:22(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:27(para) msgid "Storage" msgstr "" @@ -2803,7 +2711,7 @@ msgstr "" msgid "Image (glance)" msgstr "" -#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:190(para) +#: ./doc/arch-design/compute_focus/section_architecture_compute_focus.xml:190(para) ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:144(term) msgid "Networking (neutron)" msgstr "" @@ -2871,7 +2779,7 @@ msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:136(None) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:148(None) msgid "@@image: '../figures/Generic_CERN_Architecture.png'; md5=f5ec57432a0b3bd35efeaa25e84d9947" msgstr "" @@ -2951,68 +2859,68 @@ msgstr "" msgid "There is also some customization of the filter scheduler that handles placement within the cells:" msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:84(para) -msgid "ImagePropertiesFilter - To provide special handling depending on the guest operating system in use (Linux-based or Windows-based)." +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:84(term) +msgid "ImagePropertiesFilter" msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:88(para) -msgid "ProjectsToAggregateFilter - To provide special handling depending on the project the instance is associated with." +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:86(para) +msgid "Provides special handling depending on the guest operating system in use (Linux-based or Windows-based)." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:91(term) +msgid "ProjectsToAggregateFilter" msgstr "" #: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:92(para) -msgid "default_schedule_zones - Allows the selection of multiple default availability zones, rather than a single default." +msgid "Provides special handling depending on which project the instance is associated with." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:97(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:97(term) +msgid "default_schedule_zones" +msgstr "" + +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:98(para) +msgid "Allows the selection of multiple default availability zones, rather than a single default." +msgstr "" + +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:104(para) msgid "A central database team manages the MySQL database server in each cell in an active/passive configuration with a NetApp storage back end. Backups run every 6 hours." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:101(title) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:109(title) msgid "Network architecture" msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:102(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:110(para) msgid "To integrate with existing networking infrastructure, CERN made customizations to legacy networking (nova-network). This was in the form of a driver to integrate with CERN's existing database for tracking MAC and IP address assignments." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:106(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:114(para) msgid "The driver facilitates selection of a MAC address and IP for new instances based on the compute node where the scheduler places the instance." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:109(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:117(para) msgid "The driver considers the compute node where the scheduler placed an instance and selects a MAC address and IP from the pre-registered list associated with that node in the database. The database updates to reflect the address assignment to that instance." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:115(title) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:125(title) msgid "Storage architecture" msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:116(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:126(para) msgid "CERN deploys the OpenStack Image service in the API cell and configures it to expose version 1 (V1) of the API. This also requires the image registry. The storage back end in use is a 3 PB Ceph cluster." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:120(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:130(para) msgid "CERN maintains a small set of Scientific Linux 5 and 6 images onto which orchestration tools can place applications. Puppet manages instance configuration and customization." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:125(para) +#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:137(para) msgid "CERN does not require direct billing, but uses the Telemetry module to perform metering for the purposes of adjusting project quotas. CERN uses a sharded, replicated, MongoDB back-end. To spread API load, CERN deploys instances of the nova-api service within the child cells for Telemetry to query against. This also requires the configuration of supporting services such as keystone, glance-api, and glance-registry in the child cells." msgstr "" -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:139(para) -msgid "Additional monitoring tools in use include Flume, Elastic Search, Kibana, and the CERN developed Lemon project." -msgstr "" - #: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:151(para) -msgid "The authors of the Architecture Design Guide would like to thank CERN for publicly documenting their OpenStack deployment in these resources, which formed the basis for this chapter:" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:156(link) -msgid "http://openstack-in-production.blogspot.fr" -msgstr "" - -#: ./doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml:160(link) -msgid "Deep dive into the CERN Cloud Infrastructure" +msgid "Additional monitoring tools in use include Flume, Elastic Search, Kibana, and the CERN developed Lemon project." msgstr "" #: ./doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml:9(para) @@ -3080,204 +2988,208 @@ msgid "The added risk of increasing the overcommit ratio is that more instances msgstr "" #: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:9(para) -msgid "Deployment of a multi-site OpenStack cloud using regions requires that the service catalog contains per-region entries for each service deployed other than the Identity service itself. There is limited support amongst currently available off-the-shelf OpenStack deployment tools for defining multiple regions in this fashion." +msgid "Multi-site OpenStack cloud deployment using regions requires that the service catalog contains per-region entries for each service deployed other than the Identity service. Most off-the-shelf OpenStack deployment tools have limited support for defining multiple regions in this fashion." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:15(para) -msgid "Deployers must be aware of this and provide the appropriate customization of the service catalog for their site either manually or via customization of the deployment tools in use." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:14(para) +msgid "Deployers should be aware of this and provide the appropriate customization of the service catalog for their site either manually, or by customizing deployment tools in use." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:19(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:17(para) msgid "As of the Kilo release, documentation for implementing this feature is in progress. See this bug for more information: https://bugs.launchpad.net/openstack-manuals/+bug/1340509." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:26(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:24(title) msgid "Licensing" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:27(para) -msgid "Multi-site OpenStack deployments present additional licensing considerations over and above regular OpenStack clouds, particularly where site licenses are in use to provide cost efficient access to software licenses. The licensing for host operating systems, guest operating systems, OpenStack distributions (if applicable), software-defined infrastructure including network controllers and storage systems, and even individual applications need to be evaluated in light of the multi-site nature of the cloud." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:25(para) +msgid "Multi-site OpenStack deployments present additional licensing considerations over and above regular OpenStack clouds, particularly where site licenses are in use to provide cost efficient access to software licenses. The licensing for host operating systems, guest operating systems, OpenStack distributions (if applicable), software-defined infrastructure including network controllers and storage systems, and even individual applications need to be evaluated." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:36(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:33(para) msgid "Topics to consider include:" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:39(para) -msgid "The specific definition of what constitutes a site in the relevant licenses, as the term does not necessarily denote a geographic or otherwise physically isolated location in the traditional sense." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:36(para) +msgid "The definition of what constitutes a site in the relevant licenses, as the term does not necessarily denote a geographic or otherwise physically isolated location." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:46(para) -msgid "Differentiations between \"hot\" (active) and \"cold\" (inactive) sites where significant savings may be made in situations where one site is a cold standby for disaster recovery purposes only." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:42(para) +msgid "Differentiations between \"hot\" (active) and \"cold\" (inactive) sites, where significant savings may be made in situations where one site is a cold standby for disaster recovery purposes only." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:52(para) -msgid "Certain locations might require local vendors to provide support and services for each site provides challenges, but will vary on the licensing agreement in place." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:48(para) +msgid "Certain locations might require local vendors to provide support and services for each site which may vary with the licensing agreement in place." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:59(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:54(title) msgid "Logging and monitoring" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:60(para) -msgid "Logging and monitoring does not significantly differ for a multi-site OpenStack cloud. The same well known tools described in the Logging and monitoring chapter of the Operations Guide remain applicable. Logging and monitoring can be provided both on a per-site basis and in a common centralized location." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:55(para) +msgid "Logging and monitoring does not significantly differ for a multi-site OpenStack cloud. The tools described in the Logging and monitoring chapter of the Operations Guide remain applicable. Logging and monitoring can be provided on a per-site basis, and in a common centralized location." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:68(para) -msgid "When attempting to deploy logging and monitoring facilities to a centralized location, care must be taken with regards to the load placed on the inter-site networking links." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:62(para) +msgid "When attempting to deploy logging and monitoring facilities to a centralized location, care must be taken with the load placed on the inter-site networking links." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:72(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:44(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:66(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:44(title) msgid "Upgrades" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:73(para) -msgid "In multi-site OpenStack clouds deployed using regions each site is, effectively, an independent OpenStack installation which is linked to the others by using centralized services such as Identity which are shared between sites. At a high level the recommended order of operations to upgrade an individual OpenStack environment is (see the Upgrades chapter of the Operations Guide for details):" +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:67(para) +msgid "In multi-site OpenStack clouds deployed using regions, sites are independent OpenStack installations which are linked together using shared centralized services such as OpenStack Identity. At a high level the recommended order of operations to upgrade an individual OpenStack environment is (see the Upgrades chapter of the Operations Guide for details):" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:84(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:77(para) msgid "Upgrade the OpenStack Identity service (keystone)." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:88(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:81(para) msgid "Upgrade the OpenStack Image service (glance)." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:91(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:84(para) msgid "Upgrade OpenStack Compute (nova), including networking components." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:95(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:88(para) msgid "Upgrade OpenStack Block Storage (cinder)." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:98(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:91(para) msgid "Upgrade the OpenStack dashboard (horizon)." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:101(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:94(para) msgid "The process for upgrading a multi-site environment is not significantly different:" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:105(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:98(para) msgid "Upgrade the shared OpenStack Identity service (keystone) deployment." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:109(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:102(para) msgid "Upgrade the OpenStack Image service (glance) at each site." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:113(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:106(para) msgid "Upgrade OpenStack Compute (nova), including networking components, at each site." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:117(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:110(para) msgid "Upgrade OpenStack Block Storage (cinder) at each site." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:121(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:114(para) msgid "Upgrade the OpenStack dashboard (horizon), at each site or in the single central location if it is shared." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:126(para) -msgid "Note that Compute upgrades within each site can also be performed in a rolling fashion. Compute controller services (API, Scheduler, and Conductor) can be upgraded prior to upgrading of individual compute nodes. This maximizes the ability of operations staff to keep a site operational for users of compute services while performing an upgrade." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:119(para) +msgid "Compute upgrades within each site can also be performed in a rolling fashion. Compute controller services (API, Scheduler, and Conductor) can be upgraded prior to upgrading of individual compute nodes. This allows operations staff to keep a site operational for users of Compute services while performing an upgrade." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:134(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:126(title) msgid "Quota management" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:135(para) -msgid "To prevent system capacities from being exhausted without notification, OpenStack provides operators with the ability to define quotas. Quotas are used to set operational limits and are currently enforced at the tenant (or project) level rather than at the user level." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:127(para) +msgid "Quotas are used to set operational limits to prevent system capacities from being exhausted without notification. They are currently enforced at the tenant (or project) level rather than at the user level." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:140(para) -msgid "Quotas are defined on a per-region basis. Operators may wish to define identical quotas for tenants in each region of the cloud to provide a consistent experience, or even create a process for synchronizing allocated quotas across regions. It is important to note that only the operational limits imposed by the quotas will be aligned consumption of quotas by users will not be reflected between regions." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:131(para) +msgid "Quotas are defined on a per-region basis. Operators can define identical quotas for tenants in each region of the cloud to provide a consistent experience, or even create a process for synchronizing allocated quotas across regions. It is important to note that only the operational limits imposed by the quotas will be aligned consumption of quotas by users will not be reflected between regions." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:147(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:138(para) msgid "For example, given a cloud with two regions, if the operator grants a user a quota of 25 instances in each region then that user may launch a total of 50 instances spread across both regions. They may not, however, launch more than 25 instances in any single region." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:152(para) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:143(para) msgid "For more information on managing quotas refer to the Managing projects and users chapter of the OpenStack Operators Guide." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:159(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:150(title) msgid "Policy management" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:160(para) -msgid "OpenStack provides a default set of Role Based Access Control (RBAC) policies, defined in a policy.json file, for each service. Operators edit these files to customize the policies for their OpenStack installation. If the application of consistent RBAC policies across sites is considered a requirement, then it is necessary to ensure proper synchronization of the policy.json files to all installations." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:151(para) +msgid "OpenStack provides a default set of Role Based Access Control (RBAC) policies, defined in a policy.json file, for each service. Operators edit these files to customize the policies for their OpenStack installation. If the application of consistent RBAC policies across sites is a requirement, then it is necessary to ensure proper synchronization of the policy.json files to all installations." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:168(para) -msgid "This must be done using normal system administration tools such as rsync as no functionality for synchronizing policies across regions is currently provided within OpenStack." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:158(para) +msgid "This must be done using system administration tools such as rsync as functionality for synchronizing policies across regions is not currently provided within OpenStack." msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:172(title) +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:162(title) msgid "Documentation" msgstr "" -#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:173(para) -msgid "Users must be able to leverage cloud infrastructure and provision new resources in the environment. It is important that user documentation is accessible by users of the cloud infrastructure to ensure they are given sufficient information to help them leverage the cloud. As an example, by default OpenStack schedules instances on a compute node automatically. However, when multiple regions are available, it is left to the end user to decide in which region to schedule the new instance. The dashboard presents the user with the first region in your configuration. The API and CLI tools do not execute commands unless a valid region is specified. It is therefore important to provide documentation to your users describing the region layout as well as calling out that quotas are region-specific. If a user reaches his or her quota in one region, OpenStack does not automatically build new instances in another. Documenting specific examples helps users understand how to operate the cloud, thereby reducing calls and tickets filed with the help desk." +#: ./doc/arch-design/multi_site/section_operational_considerations_multi_site.xml:163(para) +msgid "Users must be able to leverage cloud infrastructure and provision new resources in the environment. It is important that user documentation is accessible by users to ensure they are given sufficient information to help them leverage the cloud. As an example, by default OpenStack schedules instances on a compute node automatically. However, when multiple regions are available, the end user needs to decide in which region to schedule the new instance. The dashboard presents the user with the first region in your configuration. The API and CLI tools do not execute commands unless a valid region is specified. It is therefore important to provide documentation to your users describing the region layout as well as calling out that quotas are region-specific. If a user reaches his or her quota in one region, OpenStack does not automatically build new instances in another. Documenting specific examples helps users understand how to operate the cloud, thereby reducing calls and tickets filed with the help desk." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:21(None) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:24(None) msgid "@@image: '../figures/Multi-Site_shared_keystone_horizon_swift1.png'; md5=fb80511b491731906fb54d5a1f029f91" msgstr "" #: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:9(para) -msgid "This graphic is a high level diagram of a multi-site OpenStack architecture. Each site is an OpenStack cloud but it may be necessary to architect the sites on different versions. For example, if the second site is intended to be a replacement for the first site, they would be different. Another common design would be a private OpenStack cloud with replicated site that would be used for high availability or disaster recovery. The most important design decision is how to configure the storage. It can be configured as a single shared pool or separate pools, depending on the user and technical requirements." +msgid " illustrates a high level multi-site OpenStack architecture. Each site is an OpenStack cloud but it may be necessary to architect the sites on different versions. For example, if the second site is intended to be a replacement for the first site, they would be different. Another common design would be a private OpenStack cloud with a replicated site that would be used for high availability or disaster recovery. The most important design decision is configuring storage as a single shared pool or separate pools, depending on user and technical requirements." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:25(title) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:20(title) +msgid "Multi-site OpenStack architecture" +msgstr "" + +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:29(title) msgid "OpenStack services architecture" msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:26(para) -msgid "The OpenStack Identity service, which is used by all other OpenStack components for authorization and the catalog of service endpoints, supports the concept of regions. A region is a logical construct that can be used to group OpenStack services that are in close proximity to one another. The concept of regions is flexible; it may can contain OpenStack service endpoints located within a distinct geographic region, or regions. It may be smaller in scope, where a region is a single rack within a data center or even a single blade chassis, with multiple regions existing in adjacent racks in the same data center." +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:30(para) +msgid "The OpenStack Identity service, which is used by all other OpenStack components for authorization and the catalog of service endpoints, supports the concept of regions. A region is a logical construct used to group OpenStack services in close proximity to one another. The concept of regions is flexible; it may can contain OpenStack service endpoints located within a distinct geographic region or regions. It may be smaller in scope, where a region is a single rack within a data center, with multiple regions existing in adjacent racks in the same data center." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:36(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:40(para) msgid "The majority of OpenStack components are designed to run within the context of a single region. The OpenStack Compute service is designed to manage compute resources within a region, with support for subdivisions of compute resources by using availability zones and cells. The OpenStack Networking service can be used to manage network resources in the same broadcast domain or collection of switches that are linked. The OpenStack Block Storage service controls storage resources within a region with all storage resources residing on the same storage network. Like the OpenStack Compute service, the OpenStack Block Storage service also supports the availability zone construct which can be used to subdivide storage resources." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:48(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:52(para) msgid "The OpenStack dashboard, OpenStack Identity, and OpenStack Object Storage services are components that can each be deployed centrally in order to serve multiple regions." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:54(para) -msgid "With multiple OpenStack regions, having a single OpenStack Object Storage service endpoint that delivers shared file storage for all regions is desirable. The Object Storage service internally replicates files to multiple nodes. The advantages of this are that, if a file placed into the Object Storage service is visible to all regions, it can be used by applications or workloads in any or all of the regions. This simplifies high availability failover and disaster recovery rollback." +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:58(para) +msgid "With multiple OpenStack regions, it is recommended to configure a single OpenStack Object Storage service endpoint to deliver shared file storage for all regions. The Object Storage service internally replicates files to multiple nodes which can be used by applications or workloads in multiple regions. This simplifies high availability failover and disaster recovery rollback." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:62(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:64(para) msgid "In order to scale the Object Storage service to meet the workload of multiple regions, multiple proxy workers are run and load-balanced, storage nodes are installed in each region, and the entire Object Storage Service can be fronted by an HTTP caching layer. This is done so client requests for objects can be served out of caches rather than directly from the storage modules themselves, reducing the actual load on the storage network. In addition to an HTTP caching layer, use a caching layer like Memcache to cache objects between the proxy and storage nodes." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:71(para) -msgid "If the cloud is designed without a single Object Storage Service endpoint for multiple regions, and instead a separate Object Storage Service endpoint is made available in each region, applications are required to handle synchronization (if desired) and other management operations to ensure consistency across the nodes. For some applications, having multiple Object Storage Service endpoints located in the same region as the application may be desirable due to reduced latency, cross region bandwidth, and ease of deployment." +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:73(para) +msgid "If the cloud is designed with a separate Object Storage Service endpoint made available in each region, applications are required to handle synchronization (if desired) and other management operations to ensure consistency across the nodes. For some applications, having multiple Object Storage Service endpoints located in the same region as the application may be desirable due to reduced latency, cross region bandwidth, and ease of deployment." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:80(para) -msgid "For the Block Storage service, the most important decisions are the selection of the storage technology and whether or not a dedicated network is used to carry storage traffic from the storage service to the compute nodes." +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:82(para) +msgid "For the Block Storage service, the most important decisions are the selection of the storage technology, and whether a dedicated network is used to carry storage traffic from the storage service to the compute nodes." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:87(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:90(para) msgid "When connecting multiple regions together there are several design considerations. The overlay network technology choice determines how packets are transmitted between regions and how the logical network and addresses present to the application. If there are security or regulatory requirements, encryption should be implemented to secure the traffic between regions. For networking inside a region, the overlay network technology for tenant networks is equally important. The overlay technology and the network traffic of an application generates or receives can be either complementary or be at cross purpose. For example, using an overlay technology for an application that transmits a large amount of small packets could add excessive latency or overhead to each packet if not configured properly." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:102(title) ./doc/arch-design/introduction/section_methodology.xml:84(term) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:105(title) ./doc/arch-design/introduction/section_methodology.xml:84(term) msgid "Dependencies" msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:103(para) -msgid "The architecture for a multi-site installation of OpenStack is dependent on a number of factors. One major dependency to consider is storage. When designing the storage system, the storage mechanism needs to be determined. Once the storage type is determined, how it is accessed is critical. For example, we recommend that storage should use a dedicated network. Another concern is how the storage is configured to protect the data. For example, the recovery point objective (RPO) and the recovery time objective (RTO). How quickly can the recovery from a fault be completed, determines how often the replication of data is required. Ensure that enough storage is allocated to support the data protection strategy." +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:106(para) +msgid "The architecture for a multi-site OpenStack installation is dependent on a number of factors. One major dependency to consider is storage. When designing the storage system, the storage mechanism needs to be determined. Once the storage type is determined, how it is accessed is critical. For example, we recommend that storage should use a dedicated network. Another concern is how the storage is configured to protect the data. For example, the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). How quickly recovery from a fault can be completed, determines how often the replication of data is required. Ensure that enough storage is allocated to support the data protection strategy." msgstr "" -#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:115(para) +#: ./doc/arch-design/multi_site/section_architecture_multi_site.xml:119(para) msgid "Networking decisions include the encapsulation mechanism that can be used for the tenant networks, how large the broadcast domains should be, and the contracted SLAs for the interconnects." msgstr "" @@ -3290,216 +3202,232 @@ msgid "When determining capacity options be sure to take into account not just t msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:20(para) -msgid "Inter-site link capacity describes the capabilities of the connectivity between the different OpenStack sites. This includes parameters such as bandwidth, latency, whether or not a link is dedicated, and any business policies applied to the connection. The capability and number of the links between sites determine what kind of options are available for deployment. For example, if two sites have a pair of high-bandwidth links available between them, it may be wise to configure a separate storage replication network between the two sites to support a single Swift endpoint and a shared object storage capability between them. (An example of this technique, as well as a configuration walk-through, is available at http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network). Another option in this scenario is to build a dedicated set of tenant private networks across the secondary link using overlay networks with a third party mapping the site overlays to each other." +msgid "Inter-site link capacity describes the capabilities of the connectivity between the different OpenStack sites. This includes parameters such as bandwidth, latency, whether or not a link is dedicated, and any business policies applied to the connection. The capability and number of the links between sites determine what kind of options are available for deployment. For example, if two sites have a pair of high-bandwidth links available between them, it may be wise to configure a separate storage replication network between the two sites to support a single Swift endpoint and a shared Object Storage capability between them. An example of this technique, as well as a configuration walk-through, is available at http://docs.openstack.org/developer/swift/replication_network.html#dedicated-replication-network. Another option in this scenario is to build a dedicated set of tenant private networks across the secondary link, using overlay networks with a third party mapping the site overlays to each other." msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:38(para) -msgid "The capacity requirements of the links between sites is driven by application behavior. If the latency of the links is too high, certain applications that use a large number of small packets, for example RPC calls, may encounter issues communicating with each other or operating properly. Additionally, OpenStack may encounter similar types of issues. To mitigate this, tuning of the Identity service call timeouts may be necessary to prevent issues authenticating against a central Identity service." +msgid "The capacity requirements of the links between sites is driven by application behavior. If the link latency is too high, certain applications that use a large number of small packets, for example RPC calls, may encounter issues communicating with each other or operating properly. Additionally, OpenStack may encounter similar types of issues. To mitigate this, Identity service call timeouts can be tuned to prevent issues authenticating against a central Identity service." msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:47(para) -msgid "Another capacity consideration when it comes to networking for a multi-site deployment is the available amount and performance of overlay networks for tenant networks. If using shared tenant networks across zones, it is imperative that an external overlay manager or controller be used to map these overlays together. It is necessary to ensure the amount of possible IDs between the zones are identical. Note that, as of the Kilo release, OpenStack Networking was not capable of managing tunnel IDs across installations. This means that if one site runs out of IDs, but other does not, that tenant's network is unable to reach the other site." +msgid "Another network capacity consideration for a multi-site deployment is the amount and performance of overlay networks available for tenant networks. If using shared tenant networks across zones, it is imperative that an external overlay manager or controller be used to map these overlays together. It is necessary to ensure the amount of possible IDs between the zones are identical." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:58(para) -msgid "Capacity can take other forms as well. The ability for a region to grow depends on scaling out the number of available compute nodes. This topic is covered in greater detail in the section for compute-focused deployments. However, it should be noted that cells may be necessary to grow an individual region beyond a certain point. This point depends on the size of your cluster and the ratio of virtual machines per hypervisor." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:55(para) +msgid "As of the Kilo release, OpenStack Networking was not capable of managing tunnel IDs across installations. So if one site runs out of IDs, but another does not, that tenant's network is unable to reach the other site." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:66(para) -msgid "A third form of capacity comes in the multi-region-capable components of OpenStack. Centralized Object Storage is capable of serving objects through a single namespace across multiple regions. Since this works by accessing the object store via swift proxy, it is possible to overload the proxies. There are two options available to mitigate this issue. The first is to deploy a large number of swift proxies. The drawback to this is that the proxies are not load-balanced and a large file request could continually hit the same proxy. The other way to mitigate this is to front-end the proxies with a caching HTTP proxy and load balancer. Since swift objects are returned to the requester via HTTP, this load balancer would alleviate the load required on the swift proxies." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:60(para) +msgid "Capacity can take other forms as well. The ability for a region to grow depends on scaling out the number of available compute nodes. This topic is covered in greater detail in the section for compute-focused deployments. However, it may be necessary to grow cells in an individual region, depending on the size of your cluster and the ratio of virtual machines per hypervisor." +msgstr "" + +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:67(para) +msgid "A third form of capacity comes in the multi-region-capable components of OpenStack. Centralized Object Storage is capable of serving objects through a single namespace across multiple regions. Since this works by accessing the object store through swift proxy, it is possible to overload the proxies. There are two options available to mitigate this issue:" +msgstr "" + +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:75(para) +msgid "Deploy a large number of swift proxies. The drawback is that the proxies are not load-balanced and a large file request could continually hit the same proxy." msgstr "" #: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:80(para) +msgid "Add a caching HTTP proxy and load balancer in front of the swift proxies. Since swift objects are returned to the requester via HTTP, this load balancer would alleviate the load required on the swift proxies." +msgstr "" + +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:87(para) msgid "While constructing a multi-site OpenStack environment is the goal of this guide, the real test is whether an application can utilize it." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:83(para) -msgid "Identity is normally the first interface for the majority of OpenStack users. Interacting with the Identity service is required for almost all major operations within OpenStack. Therefore, it is important to ensure that you provide users with a single URL for Identity service authentication. Equally important is proper documentation and configuration of regions within the Identity service. Each of the sites defined in your installation is considered to be a region in Identity nomenclature. This is important for the users of the system, when reading Identity documentation, as it is required to define the region name when providing actions to an API endpoint or in the dashboard." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:90(para) +msgid "The Identity service is normally the first interface for OpenStack users and is required for almost all major operations within OpenStack. Therefore, it is important that you provide users with a single URL for Identity service authentication, and document the configuration of regions within the Identity service. Each of the sites defined in your installation is considered to be a region in Identity nomenclature. This is important for the users, as it is required to define the region name when providing actions to an API endpoint or in the dashboard." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:94(para) -msgid "Load balancing is another common issue with multi-site installations. While it is still possible to run HAproxy instances with Load-Balancer-as-a-Service, these are local to a specific region. Some applications may be able to cope with this via internal mechanisms. Others, however, may require the implementation of an external system including global services load balancers or anycast-advertised DNS." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:99(para) +msgid "Load balancing is another common issue with multi-site installations. While it is still possible to run HAproxy instances with Load-Balancer-as-a-Service, these are defined to a specific region. Some applications can manage this using internal mechanisms. Other applications may require the implementation of an external system, including global services load balancers or anycast-advertised DNS." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:102(para) -msgid "Depending on the storage model chosen during site design, storage replication and availability are also a concern for end-users. If an application is capable of understanding regions, then it is possible to keep the object storage system separated by region. In this case, users who want to have an object available to more than one region need to do the cross-site replication themselves. With a centralized swift proxy, however, the user may need to benchmark the replication timing of the Object Storage back end. Benchmarking allows the operational staff to provide users with an understanding of the amount of time required for a stored or modified object to become available to the entire environment." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:106(para) +msgid "Depending on the storage model chosen during site design, storage replication and availability are also a concern for end-users. If an application can support regions, then it is possible to keep the object storage system separated by region. In this case, users who want to have an object available to more than one region need to perform cross-site replication. However, with a centralized swift proxy, the user may need to benchmark the replication timing of the Object Storage back end. Benchmarking allows the operational staff to provide users with an understanding of the amount of time required for a stored or modified object to become available to the entire environment." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:115(para) -msgid "Determining the performance of a multi-site installation involves considerations that do not come into play in a single-site deployment. Being a distributed deployment, multi-site deployments incur a few extra penalties to performance in certain situations." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:119(para) +msgid "Determining the performance of a multi-site installation involves considerations that do not come into play in a single-site deployment. Being a distributed deployment, performance in multi-site deployments may be affected in certain situations." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:120(para) -msgid "Since multi-site systems can be geographically separated, they may have worse than normal latency or jitter when communicating across regions. This can especially impact systems like the OpenStack Identity service when making authentication attempts from regions that do not contain the centralized Identity implementation. It can also affect certain applications which rely on remote procedure call (RPC) for normal operation. An example of this can be seen in High Performance Computing workloads." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:124(para) +msgid "Since multi-site systems can be geographically separated, there may be greater latency or jitter when communicating across regions. This can especially impact systems like the OpenStack Identity service when making authentication attempts from regions that do not contain the centralized Identity implementation. It can also affect applications which rely on Remote Procedure Call (RPC) for normal operation. An example of this can be seen in high performance computing workloads." msgstr "" -#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:129(para) +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:132(para) msgid "Storage availability can also be impacted by the architecture of a multi-site deployment. A centralized Object Storage service requires more time for an object to be available to instances locally in regions where the object was not created. Some applications may need to be tuned to account for this effect. Block Storage does not currently have a method for replicating data across multiple regions, so applications that depend on available block storage need to manually cope with this limitation by creating duplicate block storage entries in each region." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:9(para) -msgid "A multi-site architecture is complex and has its own risks and considerations, therefore it is important to make sure when contemplating the design such an architecture that it meets the user and business requirements." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:145(para) +msgid "Most OpenStack installations require a bare minimum set of pieces to function. These include the OpenStack Identity (keystone) for authentication, OpenStack Compute (nova) for compute, OpenStack Image service (glance) for image storage, OpenStack Networking (neutron) for networking, and potentially an object store in the form of OpenStack Object Storage (swift). Deploying a multi-site installation also demands extra components in order to coordinate between regions. A centralized Identity service is necessary to provide the single authentication point. A centralized dashboard is also recommended to provide a single login point and a mapping to the API and CLI options available. A centralized Object Storage service may also be used, but will require the installation of the swift proxy service." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:32(para) -msgid "Data compliance policies governing types of information that needs to reside in certain locations due to regular issues and, more importantly, cannot reside in other locations for the same reason." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:159(para) +msgid "It may also be helpful to install a few extra options in order to facilitate certain use cases. For example, installing Designate may assist in automatically generating DNS domains for each region with an automatically-populated zone full of resource records for each instance. This facilitates using DNS as a mechanism for determining which region will be selected for certain applications." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:38(para) -msgid "Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules) in the United States. Consult a local regulatory body for more information." +#: ./doc/arch-design/multi_site/section_tech_considerations_multi_site.xml:166(para) +msgid "Another useful tool for managing a multi-site installation is Orchestration (heat). The Orchestration module allows the use of templates to define a set of instances to be launched together or for scaling existing sets. It can also be used to set up matching or differentiated groupings based on regions. For instance, if an application requires an equally balanced number of nodes across sites, the same heat template can be used to cover each site with small alterations to only the region name." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:47(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:10(title) msgid "Workload characteristics" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:48(para) -msgid "The expected workload is a critical requirement that needs to be captured to guide decision-making. An understanding of the workloads in the context of the desired multi-site environment and use case is important. Another way of thinking about a workload is to think of it as the way the systems are used. A workload could be a single application or a suite of applications that work together. It could also be a duplicate set of applications that need to run in multiple cloud environments. Often in a multi-site deployment the same workload will need to work identically in more than one physical location." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:11(para) +msgid "An understanding of the expected workloads for a desired multi-site environment and use case is an important factor in the decision-making process. In this context, workload refers to the way the systems are used. A workload could be a single application or a suite of applications that work together. It could also be a duplicate set of applications that need to run in multiple cloud environments. Often in a multi-site deployment, the same workload will need to work identically in more than one physical location." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:59(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:20(para) msgid "This multi-site scenario likely includes one or more of the other scenarios in this book with the additional requirement of having the workloads in two or more locations. The following are some possible scenarios:" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:63(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:24(para) msgid "For many use cases the proximity of the user to their workloads has a direct influence on the performance of the application and therefore should be taken into consideration in the design. Certain applications require zero to minimal latency that can only be achieved by deploying the cloud in multiple locations. These locations could be in different data centers, cities, countries or geographical regions, depending on the user requirement and location of the users." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:72(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:33(title) msgid "Consistency of images and templates across different sites" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:74(para) -msgid "It is essential that the deployment of instances is consistent across the different sites. This needs to be built into the infrastructure. If the OpenStack Object Storage is used as a back end for the Image service, it is possible to create repositories of consistent images across multiple sites. Having central endpoints with multiple storage nodes allows consistent centralized storage for each and every site." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:35(para) +msgid "It is essential that the deployment of instances is consistent across the different sites and built into the infrastructure. If the OpenStack Object Storage is used as a back end for the Image service, it is possible to create repositories of consistent images across multiple sites. Having central endpoints with multiple storage nodes allows consistent centralized storage for every site." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:81(para) -msgid "Not using a centralized object store increases operational overhead so that a consistent image library can be maintained. This could include development of a replication mechanism to handle the transport of images and the changes to the images across multiple sites." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:42(para) +msgid "Not using a centralized object store increases the operational overhead of maintaining a consistent image library. This could include development of a replication mechanism to handle the transport of images and the changes to the images across multiple sites." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:87(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:49(para) msgid "If high availability is a requirement to provide continuous infrastructure operations, a basic requirement of high availability should be defined." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:90(para) -msgid "The OpenStack management components need to have a basic and minimal level of redundancy. The simplest example is the loss of any single site has no significant impact on the availability of the OpenStack services of the entire infrastructure." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:52(para) +msgid "The OpenStack management components need to have a basic and minimal level of redundancy. The simplest example is the loss of any single site should have minimal impact on the availability of the OpenStack services." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:95(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:56(para) msgid "The OpenStack High Availability Guide contains more information on how to provide redundancy for the OpenStack components." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:100(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:61(para) msgid "Multiple network links should be deployed between sites to provide redundancy for all components. This includes storage replication, which should be isolated to a dedicated network or VLAN with the ability to assign QoS to control the replication traffic or provide priority for this traffic. Note that if the data store is highly changeable, the network requirements could have a significant effect on the operational cost of maintaining the sites." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:108(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:69(para) msgid "The ability to maintain object availability in both sites has significant implications on the object storage design and implementation. It also has a significant impact on the WAN network design between the sites." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:112(para) -msgid "Connecting more than two sites increases the challenges and adds more complexity to the design considerations. Multi-site implementations require extra planning to address the additional topology complexity used for internal and external connectivity. Some options include full mesh topology, hub spoke, spine leaf, or 3d Torus." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:73(para) +msgid "Connecting more than two sites increases the challenges and adds more complexity to the design considerations. Multi-site implementations require planning to address the additional topology used for internal and external connectivity. Some options include full mesh topology, hub spoke, spine leaf, and 3D Torus." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:118(para) -msgid "Not all the applications running in a cloud are cloud-aware. If that is the case, there should be clear measures and expectations to define what the infrastructure can support and, more importantly, what it cannot. An example would be shared storage between sites. It is possible, however such a solution is not native to OpenStack and requires a third-party hardware vendor to fulfill such a requirement. Another example can be seen in applications that are able to consume resources in object storage directly. These applications need to be cloud aware to make good use of an OpenStack Object Store." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:78(para) +msgid "If applications running in a cloud are not cloud-aware, there should be clear measures and expectations to define what the infrastructure can and cannot support. An example would be shared storage between sites. It is possible, however such a solution is not native to OpenStack and requires a third-party hardware vendor to fulfill such a requirement. Another example can be seen in applications that are able to consume resources in object storage directly. These applications need to be cloud aware to make good use of an OpenStack Object Store." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:129(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:31(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:89(title) ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:31(title) msgid "Application readiness" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:130(para) -msgid "Some applications are tolerant of the lack of synchronized object storage, while others may need those objects to be replicated and available across regions. Understanding of how the cloud implementation impacts new and existing applications is important for risk mitigation and the overall success of a cloud project. Applications may have to be written to expect an infrastructure with little to no redundancy. Existing applications not developed with the cloud in mind may need to be rewritten." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:90(para) +msgid "Some applications are tolerant of the lack of synchronized object storage, while others may need those objects to be replicated and available across regions. Understanding how the cloud implementation impacts new and existing applications is important for risk mitigation, and the overall success of a cloud project. Applications may have to be written or rewritten for an infrastructure with little to no redundancy, or with the cloud in mind." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:140(para) -msgid "The requirement of having more than one site has a cost attached to it. The greater the number of sites, the greater the cost and complexity. Costs can be broken down into the following categories:" +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:100(para) +msgid "A greater number of sites increase cost and complexity for a multi-site deployment. Costs can be broken down into the following categories:" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:146(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:105(para) msgid "Compute resources" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:149(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:108(para) msgid "Networking resources" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:152(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:111(para) msgid "Replication" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:161(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:117(para) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:774(para) +msgid "Management" +msgstr "" + +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:120(para) msgid "Operational costs" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:165(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:124(title) msgid "Site loss and recovery" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:166(para) -msgid "Outages can cause loss of partial or full functionality of a site. Strategies should be implemented to understand and plan for recovery scenarios." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:125(para) +msgid "Outages can cause partial or full loss of site functionality. Strategies should be implemented to understand and plan for recovery scenarios." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:171(para) -msgid "The deployed applications need to continue to function and, more importantly, consideration should be taken of the impact on the performance and reliability of the application when a site is unavailable." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:130(para) +msgid "The deployed applications need to continue to function and, more importantly, you must consider the impact on the performance and reliability of the application when a site is unavailable." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:178(para) -msgid "It is important to understand what happens to the replication of objects and data between the sites when a site goes down. If this causes queues to start building up, consider how long these queues can safely exist until something explodes." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:136(para) +msgid "It is important to understand what happens to the replication of objects and data between the sites when a site goes down. If this causes queues to start building up, consider how long these queues can safely exist until an error occurs." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:185(para) -msgid "Ensure determination of the method for resuming proper operations of a site when it comes back online after a disaster. We recommend you architect the recovery to avoid race conditions." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:143(para) +msgid "After an outage, ensure the method for resuming proper operations of a site is implemented when it comes back online. We recommend you architect the recovery to avoid race conditions." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:192(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:149(title) msgid "Compliance and geo-location" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:193(para) -msgid "An organization could have certain legal obligations and regulatory compliance measures which could require certain workloads or data to not be located in certain regions." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:150(para) +msgid "An organization may have certain legal obligations and regulatory compliance measures which could require certain workloads or data to not be located in certain regions." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:197(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:154(title) msgid "Auditing" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:198(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:155(para) msgid "A well thought-out auditing strategy is important in order to be able to quickly track down issues. Keeping track of changes made to security groups and tenant changes can be useful in rolling back the changes if they affect production. For example, if all security group rules for a tenant disappeared, the ability to quickly track down the issue would be important for operational and legal reasons." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:206(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:163(title) msgid "Separation of duties" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:207(para) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:164(para) msgid "A common requirement is to define different roles for the different cloud administration functions. An example would be a requirement to segregate the duties and permissions by site." msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:212(title) +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:169(title) msgid "Authentication between sites" msgstr "" -#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:213(para) -msgid "Ideally it is best to have a single authentication domain and not need a separate implementation for each and every site. This, of course, requires an authentication mechanism that is highly available and distributed to ensure continuous operation. Authentication server locality is also something that might be needed as well and should be planned for." +#: ./doc/arch-design/multi_site/section_user_requirements_multi_site.xml:170(para) +msgid "It is recommended to have a single authentication domain rather than a separate implementation for each and every site. This requires an authentication mechanism that is highly available and distributed to ensure continuous operation. Authentication server locality might be required and should be planned for." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:85(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:87(None) msgid "@@image: '../figures/Multi-Site_Customer_Edge.png'; md5=01850cf774e7075bd7202c6e7f087f36" msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:191(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:194(None) msgid "@@image: '../figures/Multi-site_Geo_Redundant_LB.png'; md5=c94a96f6084c2e50a0eb6846f6fde479" msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:222(None) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:231(None) msgid "@@image: '../figures/Multi-Site_shared_keystone1.png'; md5=eaef18e7f04eec7e3f8968ad69aed7d3" msgstr "" @@ -3508,7 +3436,7 @@ msgid "There are multiple ways to build a multi-site OpenStack installation, bas msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:20(para) -msgid "A large content provider needs to deliver content to customers that are geographically dispersed. The workload is very sensitive to latency and needs a rapid response to end-users. After reviewing the user, technical and operational considerations, it is determined beneficial to build a number of regions local to the customer's edge. In this case rather than build a few large, centralized data centers, the intent of the architecture is to provide a pair of small data centers in locations that are closer to the customer. In this use case, spreading applications out allows for different horizontal scaling than a traditional compute workload scale. The intent is to scale by creating more copies of the application in closer proximity to the users that need it most, in order to ensure faster response time to user requests. This provider deploys two datacenters at each of the four chosen regions. The implications of this design are based around the method of placing copies of resources in each of the remote regions. Swift objects, Glance images, and block storage need to be manually replicated into each region. This may be beneficial for some systems, such as the case of content service, where only some of the content needs to exist in some but not all regions. A centralized Keystone is recommended to ensure authentication and that access to the API endpoints is easily manageable." +msgid "A large content provider needs to deliver content to customers that are geographically dispersed. The workload is very sensitive to latency and needs a rapid response to end-users. After reviewing the user, technical and operational considerations, it is determined beneficial to build a number of regions local to the customer's edge. Rather than build a few large, centralized data centers, the intent of the architecture is to provide a pair of small data centers in locations that are closer to the customer. In this use case, spreading applications out allows for different horizontal scaling than a traditional compute workload scale. The intent is to scale by creating more copies of the application in closer proximity to the users that need it most, in order to ensure faster response time to user requests. This provider deploys two datacenters at each of the four chosen regions. The implications of this design are based around the method of placing copies of resources in each of the remote regions. Swift objects, Glance images, and block storage need to be manually replicated into each region. This may be beneficial for some systems, such as the case of content service, where only some of the content needs to exist in some but not all regions. A centralized Keystone is recommended to ensure authentication and that access to the API endpoints is easily manageable." msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:44(para) @@ -3520,111 +3448,123 @@ msgid "Telemetry for each region is also deployed, as each region may grow diffe msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:63(para) -msgid "One of the key decisions of running this sort of infrastructure is whether or not to provide a redundancy model. Two types of redundancy and high availability models in this configuration can be implemented. The first type revolves around the availability of the central OpenStack components. Keystone can be made highly available in three central data centers that host the centralized OpenStack components. This prevents a loss of any one of the regions causing an outage in service. It also has the added benefit of being able to run a central storage repository as a primary cache for distributing content to each of the regions." +msgid "One of the key decisions of running this infrastructure is whether or not to provide a redundancy model. Two types of redundancy and high availability models in this configuration can be implemented. The first type is the availability of central OpenStack components. Keystone can be made highly available in three central data centers that host the centralized OpenStack components. This prevents a loss of any one of the regions causing an outage in service. It also has the added benefit of being able to run a central storage repository as a primary cache for distributing content to each of the regions." msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:74(para) -msgid "The second redundancy topic is that of the edge data center itself. A second data center in each of the edge regional locations house a second region near the first. This ensures that the application does not suffer degraded performance in terms of latency and availability." +msgid "The second redundancy type is the edge data center itself. A second data center in each of the edge regional locations house a second region near the first region. This ensures that the application does not suffer degraded performance in terms of latency and availability." msgstr "" #: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:79(para) -msgid "This figure depicts the solution designed to have both a centralized set of core data centers for OpenStack services and paired edge data centers:" +msgid " depicts the solution designed to have both a centralized set of core data centers for OpenStack services and paired edge data centers:" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:89(title) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:83(title) +msgid "Multi-site architecture example" +msgstr "" + +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:92(title) msgid "Geo-redundant load balancing" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:90(para) -msgid "A large-scale web application has been designed with cloud principles in mind. The application is designed provide service to application store, on a 24/7 basis. The company has typical 2-tier architecture with a web front-end servicing the customer requests and a NoSQL database back end storing the information." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:93(para) +msgid "A large-scale web application has been designed with cloud principles in mind. The application is designed provide service to application store, on a 24/7 basis. The company has typical two tier architecture with a web front-end servicing the customer requests, and a NoSQL database back end storing the information." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:96(para) -msgid "As of late there has been several outages in number of major public cloud providersusually due to the fact these applications were running out of a single geographical location. The design therefore should mitigate the chance of a single site causing an outage for their business." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:99(para) +msgid "As of late there has been several outages in number of major public cloud providers due to applications running out of a single geographical location. The design therefore should mitigate the chance of a single site causing an outage for their business." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:101(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:30(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:104(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:30(para) msgid "The solution would consist of the following OpenStack components:" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:105(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:34(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:108(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:34(para) msgid "A firewall, switches and load balancers on the public facing network connections." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:109(para) -msgid "OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. The other services, Identity, Orchestration, Telemetry, Image service and Object Storage can be installed centrallywith nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:112(para) +msgid "OpenStack Controller services running, Networking, dashboard, Block Storage and Compute running locally in each of the three regions. Identity service, Orchestration service, Telemetry service, Image service and Object Storage can be installed centrally, with nodes in each of the region providing a redundant OpenStack Controller plane throughout the globe." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:119(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:44(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:121(para) ./doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml:44(para) msgid "OpenStack Compute nodes running the KVM hypervisor." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:123(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:125(para) msgid "OpenStack Object Storage for serving static objects such as images can be used to ensure that all images are standardized across all the regions, and replicated on a regular basis." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:129(para) -msgid "A Distributed DNS service available to all regionsthat allows for dynamic update of DNS records of deployed instances." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:131(para) +msgid "A distributed DNS service available to all regions that allows for dynamic update of DNS records of deployed instances." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:134(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:136(para) msgid "A geo-redundant load balancing service can be used to service the requests from the customers based on their origin." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:139(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:141(para) msgid "An autoscaling heat template can be used to deploy the application in the three regions. This template includes:" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:143(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:145(para) msgid "Web Servers, running Apache." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:146(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:148(para) msgid "Appropriate user_data to populate the central DNS servers upon instance launch." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:150(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:152(para) msgid "Appropriate Telemetry alarms that maintain state of the application and allow for handling of region or instance failure." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:155(para) -msgid "Another autoscaling Heat template can be used to deploy a distributed MongoDB shard over the three locationswith the option of storing required data on a globally available swift container. According to the usage and load on the database serveradditional shards can be provisioned according to the thresholds defined in Telemetry." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:157(para) +msgid "Another autoscaling Heat template can be used to deploy a distributed MongoDB shard over the three locations, with the option of storing required data on a globally available swift container. According to the usage and load on the database server, additional shards can be provisioned according to the thresholds defined in Telemetry." msgstr "" #. The reason that three regions were selected here was because of #. the fear of having abnormal load on a single region in the #. event of a failure. Two data center would have been sufficient #. had the requirements been met. -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:165(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:167(para) msgid "Two data centers would have been sufficient had the requirements been met. But three regions are selected here to avoid abnormal load on a single region in the event of a failure." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:168(para) -msgid "Orchestration is used because of the built-in functionality of autoscaling and auto healing in the event of increased load. Additional configuration management tools, such as Puppet or Chef could also have been used in this scenario, but were not chosen due to the fact that Orchestration had the appropriate built-in hooks into the OpenStack cloudwhereas the other tools were external and not native to OpenStack. In additionsince this deployment scenario was relatively straight forwardthe external tools were not needed." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:170(para) +msgid "Orchestration is used because of the built-in functionality of autoscaling and auto healing in the event of increased load. Additional configuration management tools, such as Puppet or Chef could also have been used in this scenario, but were not chosen since Orchestration had the appropriate built-in hooks into the OpenStack cloud, whereas the other tools were external and not native to OpenStack. In addition, external tools were not needed since this deployment scenario was straight forward." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:177(para) -msgid "OpenStack Object Storage is used here to serve as a back end for the Image service since it is the most suitable solution for a globally distributed storage solutionwith its own replication mechanism. Home grown solutions could also have been used including the handling of replicationbut were not chosen, because Object Storage is already an intricate part of the infrastructureand proven solution." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:179(para) +msgid "OpenStack Object Storage is used here to serve as a back end for the Image service since it is the most suitable solution for a globally distributed storage solution with its own replication mechanism. Home grown solutions could also have been used including the handling of replication, but were not chosen, because Object Storage is already an intricate part of the infrastructure and a proven solution." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:185(para) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:186(para) msgid "An external load balancing service was used and not the LBaaS in OpenStack because the solution in OpenStack is not redundant and does not have any awareness of geo location." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:194(title) +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:190(title) +msgid "Multi-site geo-redundant architecture" +msgstr "" + +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:200(title) msgid "Location-local service" msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:195(para) -msgid "A common use for a multi-site deployment of OpenStack, is for creating a Content Delivery Network. An application that uses a location-local architecture requires low network latency and proximity to the user, in order to provide an optimal user experience, in addition to reducing the cost of bandwidth and transit, since the content resides on sites closer to the customer, instead of a centralized content store that requires utilizing higher cost cross-country links." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:201(para) +msgid "A common use for multi-site OpenStack deployment is creating a Content Delivery Network. An application that uses a location-local architecture requires low network latency and proximity to the user to provide an optimal user experience and reduce the cost of bandwidth and transit. The content resides on sites closer to the customer, instead of a centralized content store that requires utilizing higher cost cross-country links." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:203(para) -msgid "This architecture usually includes a geo-location component that places user requests at the closest possible node. In this scenario, 100% redundancy of content across every site is a goal rather than a requirement, with the intent being to maximize the amount of content available that is within a minimum number of network hops for any given end user. Despite these differences, the storage replication configuration has significant overlap with that of a geo-redundant load balancing use case." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:209(para) +msgid "This architecture includes a geo-location component that places user requests to the closest possible node. In this scenario, 100% redundancy of content across every site is a goal rather than a requirement, with the intent to maximize the amount of content available within a minimum number of network hops for end users. Despite these differences, the storage replication configuration has significant overlap with that of a geo-redundant load balancing use case." msgstr "" -#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:212(para) -msgid "In this example, the application utilizing this multi-site OpenStack install that is location aware would launch web server or content serving instances on the compute cluster in each site. Requests from clients are first sent to a global services load balancer that determines the location of the client, then routes the request to the closest OpenStack site where the application completes the request." +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:218(para) +msgid "In , the application utilizing this multi-site OpenStack install that is location-aware would launch web server or content serving instances on the compute cluster in each site. Requests from clients are first sent to a global services load balancer that determines the location of the client, then routes the request to the closest OpenStack site where the application completes the request." +msgstr "" + +#: ./doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml:227(title) +msgid "Multi-site shared keystone architecture" msgstr "" #: ./doc/arch-design/hybrid/section_operational_considerations_hybrid.xml:9(para) @@ -3684,171 +3624,147 @@ msgid "Hybrid clouds rely on third party systems and processes. As a result, it msgstr "" #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:13(para) -msgid "A hybrid cloud environment requires inspection and understanding of technical issues that are not only outside of an organization's data center, but potentially outside of an organization's control. In many cases, it is necessary to ensure that the architecture and CMP chosen are adaptable. All of these factors influence and add complexity to the design of the hybrid cloud architecture." +msgid "A hybrid cloud environment requires inspection and understanding of technical issues in external data centers that may not be in your control. Ideally, select an architecture and CMP that are adaptable to changing environments." +msgstr "" + +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:17(para) +msgid "Using diverse cloud platforms increases the risk of compatibility issues, but clouds using the same version and distribution of OpenStack are less likely to experience problems." msgstr "" #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:20(para) -msgid "Incompatibilities with other cloud platforms are inevitable, however, clouds using the same version and distribution of OpenStack are unlikely to experience any issues." +msgid "Clouds that exclusively use the same versions of OpenStack should have no issues, regardless of distribution. More recent distributions are less likely to encounter incompatibility between versions. An OpenStack community initiative defines core functions that need to remain backward compatible between supported versions. For example, the DefCore initiative defines basic functions that every distribution must support in order to use the name OpenStack." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:23(para) -msgid "Clouds that exclusively use the same versions of OpenStack should have no issues, regardless of distribution. The newer the distribution in question, the less likely it is that there will be incompatibilities between versions. An OpenStack community initiative defines core functions that need to remain backward compatible between supported versions." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:28(para) +msgid "Vendors can add proprietary customization to their distributions. If an application or architecture makes use of these features, it can be difficult to migrate to or use other types of environments." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:30(para) -msgid "For example, the DefCore initiative defines basic functions that every distribution must support in order to bear the name OpenStack." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:31(para) +msgid "If an environment includes non-OpenStack clouds, it may experience compatibility problems. CMP tools must account for the differences in the handling of operations and the implementation of services." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:34(para) -msgid "Vendors can add proprietary customization to their distributions. If an application or architecture makes use of these features, it will be difficult to migrate to or use other types of environments." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:35(title) +msgid "Possible cloud incompatibilities" msgstr "" #: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:37(para) -msgid "If an environment includes non-OpenStack clouds, it may experience compatibility problems. CMP tools must account for the differences in the handling of operations and implementation of services. Some situations in which these incompatibilities can arise include differences between the way in which a cloud:" +msgid "Instance deployment" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:44(para) -msgid "Deploys instances" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:40(para) +msgid "Network management" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:47(para) -msgid "Manages networks" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:43(para) +msgid "Application management" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:50(para) -msgid "Treats applications" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:46(para) +msgid "Services implementation" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:53(para) -msgid "Implements services" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:52(para) +msgid "One of the primary reasons many organizations use a hybrid cloud is to increase capacity without making large capital investments." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:59(para) -msgid "One of the primary reasons many organizations turn to a hybrid cloud system is to increase capacity without having to make large capital investments." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:55(para) +msgid "Capacity and the placement of workloads are key design considerations for hybrid clouds. The long-term capacity plan for these designs must incorporate growth over time to prevent permanent consumption of more expensive external clouds. To avoid this scenario, account for future applications' capacity requirements and plan growth appropriately." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:62(para) -msgid "Capacity, and the placement of workloads, accounts for the design of a mostly internally-operated cloud. The long-term capacity plan for this design must incorporate growth over time to prevent permanent consumption of a more expensive external cloud. In order to avoid this scenario, we recommend accounting for the future applications' capacity requirements and plan growth appropriately." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:61(para) +msgid "It is difficult to predict the amount of load a particular application might incur if the number of users fluctuates, or the application experiences an unexpected increase in use. It is possible to define application requirements in terms of vCPU, RAM, bandwidth, or other resources and plan appropriately. However, other clouds might not use the same meter or even the same oversubscription rates." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:70(para) -msgid "Unpredictability is a consideration for capacity planning. It is difficult to predict the amount of load a particular application might incur if the number of users fluctuate, or the application experiences an unexpected increase in popularity. It is possible to define application requirements in terms of vCPU, RAM, bandwidth or other resources and plan appropriately. However, other clouds might not use the same meter or even the same oversubscription rates." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:68(para) +msgid "Oversubscription is a method to emulate more capacity than may physically be present. For example, a physical hypervisor node with 32GB RAM may host 24 instances, each provisioned with 2GB RAM. As long as all 24 instances do not concurrently use 2 full gigabytes, this arrangement works well. However, some hosts take oversubscription to extremes and, as a result, performance can be inconsistent. If at all possible, determine what the oversubscription rates of each host are and plan capacity accordingly." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:77(para) -msgid "Oversubscription is a method to emulate more capacity than may physically be present. For example, a physical hypervisor node with 32GB RAM may host 24 instances, each provisioned with 2GB RAM. As long as all 24 instances are not concurrently utilizing 2 full gigabytes, this arrangement is a non-issue. However, some hosts take oversubscription to extremes and, as a result, performance can frequently be inconsistent. If at all possible, determine what the oversubscription rates of each host are and plan capacity accordingly." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:81(para) +msgid "A CMP must be aware of what workloads are running, where they are running, and their preferred utilizations. For example, in most cases it is desirable to run as many workloads internally as possible, utilizing other resources only when necessary. On the other hand, situations exist in which the opposite is true, such as when an internal cloud is only for development and stressing it is undesirable. A cost model of various scenarios and consideration of internal priorities helps with this decision. To improve efficiency, automate these decisions when possible." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:91(para) -msgid "Security domains are an important distinction when planning for a hybrid cloud environment and its capabilities. A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:90(para) +msgid "The Telemetry module (ceilometer) provides information on the usage of various OpenStack components. Note the following:" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:96(para) -msgid "The security domains are:" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:94(para) +msgid "If Telemetry must retain a large amount of data, for example when monitoring a large or active cloud, we recommend using a NoSQL back end such as MongoDB." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:111(para) -msgid "You can map the security domains individually to the organization's installation or combine them. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas other topologies physically separate the networks. In each case, the cloud operator should be aware of the appropriate security concerns. We recommend mapping security domains against the specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:121(para) -msgid "The public security domain is an entirely untrusted area of the cloud infrastructure. It can refer to the internet as a whole, or simply to networks over which an organization has no authority. Do not trust this domain. For example, in a hybrid cloud deployment, any information traversing between and beyond the clouds is of the public domain and untrustworthy." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:127(para) -msgid "The guest security domain handles compute data. Instances on the cloud generate the data, but not services that support the operation of the cloud, such as API calls. We recommend not to trust this domain if you are a public cloud provider that uses hybrid cloud configurations, or a private cloud provider who does not have controls on instance use and allows unrestricted internet access to instances. Private cloud providers, however, can use this network as an internally trusted network if controls are in place." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:146(para) -msgid "When operating or utilizing public or private clouds, consider the management of the users. The identity service allows for LDAP to be part of the authentication process. Including these systems in your OpenStack deployments may ease user management if integrating into existing systems." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:155(para) -msgid "Due to the passing of user names, passwords, and tokens between client machines and API endpoints, we recommend the placement of API services behind hardware to perform SSL termination." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:158(para) -msgid "The hypervisor also requires a security assessment. In a public cloud, organizations typically do not have control over the choice of hypervisor. For example, Amazon uses its own particular version of Xen. Properly securing your hypervisor is important. Attacks made upon the unsecured hypervisor are called a \"hypervisor breakout\". Hypervisor breakout describes the event of a compromised or malicious instance breaking out of the resource controls of the hypervisor and gaining access to the bare metal operating system and hardware resources." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:197(para) -msgid "When it comes to utilization, it is important that the CMP understands what workloads are running, where they are running, and their preferred utilizations. For example, in most cases it is desirable to run as many workloads internally as possible, utilizing other resources only when necessary. On the other hand, situations exist in which the opposite is true. The internal cloud may only be for development and stressing it is undesirable. In most cases, a cost model of various scenarios helps with this decision. However, internal priorities influence this analysis. To improve efficiency, make these decisions programmatically." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:208(para) -msgid "The Telemetry module (ceilometer) provides information on the usage of various OpenStack components. There are two limitations to consider:" -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:213(para) -msgid "If there is to be a large amount of data (for example, if monitoring a large cloud, or a very active one) it is desirable to use a NoSQL back end for Ceilometer, such as MongoDB." -msgstr "" - -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:220(para) +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:100(para) msgid "You must monitor connections to non-OpenStack clouds and report this information to the CMP." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:229(para) -msgid "Performance is of the upmost importance in the design of a cloud. When it comes to a hybrid cloud deployment, many of the same issues for multi-site deployments apply, such as network latency between sites. It is also important to think about the speed at which a workload can be spun up in another cloud, and how to reduce the time necessary to accomplish the task. This may mean moving data closer to applications or applications closer to the data they process, including a grouping functionality so that connections that require low latency take place over a single cloud rather than spanning clouds. This may also mean ensuring that the CMP has the intelligence to know which cloud can most efficiently run which types of workloads." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:109(para) +msgid "Performance is critical to hybrid cloud deployments, and they are affected by many of the same issues as multi-site deployments, such as network latency between sites. Also consider the time required to run a workload in different clouds and methods for reducing this time. This may require moving data closer to applications or applications closer to the data they process, and grouping functionality so that connections that require low latency take place over a single cloud rather than spanning clouds. This may also require a CMP that can determine which cloud can most efficiently run which types of workloads." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:242(para) -msgid "As with utilization, native OpenStack tools are available to assist. Ceilometer can measure performance and, if necessary, the Orchestration (heat) module can react to changes in demand by spinning up more resources." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:119(para) +msgid "As with utilization, native OpenStack tools help improve performance. For example, you can use Telemetry to measure performance and the Orchestration module (heat) to react to changes in demand." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:247(para) -msgid "It is important to note, however, that Orchestration requires special configurations in the client to enable functioning with solution offerings from Amazon Web Services. When dealing with other types of clouds, it is necessary to rely on the features of the CMP." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:123(para) +msgid "Orchestration requires special client configurations to integrate with Amazon Web Services. For other types of clouds, use CMP features." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:257(title) +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:131(title) msgid "Components" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:258(para) -msgid "The number and types of native OpenStack components that are available for use is dependent on whether the deployment is exclusively an OpenStack cloud or not." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:132(para) +msgid "Using more than one cloud in any design requires consideration of four OpenStack tools:" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:261(para) -msgid "Using more than one cloud in any situation requires consideration of four OpenStack tools:" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:138(para) +msgid "Regardless of deployment location, hypervisor choice has a direct effect on how difficult it is to integrate with additional clouds." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:265(para) -msgid "OpenStack Compute (nova): Regardless of deployment location, hypervisor choice has a direct effect on how difficult it is to integrate with one or more additional clouds. For example, integrating a Hyper-V based OpenStack cloud with Azure has less compatibility issues than if KVM is used." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:146(para) +msgid "Whether using OpenStack Networking (neutron) or legacy networking (nova-network), it is necessary to understand network integration capabilities in order to connect between clouds." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:273(para) -msgid "Networking (neutron): Whether OpenStack Networking or legacy networking (nova-network) is used, the network is one place where understanding integration capabilities is necessary in order to connect between clouds." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:155(para) +msgid "Use of Telemetry depends, in large part, on what the other parts of the cloud you are using." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:279(para) -msgid "Telemetry module (ceilometer): Use of Telemetry depends, in large part, on what the other parts of the cloud are using." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:160(term) +msgid "Orchestration module (heat)" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:284(para) -msgid "Orchestration module (heat): Similarly, Orchestration can be a valuable tool in orchestrating tasks a CMP decides are necessary in an OpenStack-based cloud." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:162(para) +msgid "Orchestration can be a valuable tool in orchestrating tasks a CMP decides are necessary in an OpenStack-based cloud." msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:293(title) +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:170(title) msgid "Special considerations" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:294(para) -msgid "Hybrid cloud deployments also involve two more issues that are not common in other situations:" +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:171(para) +msgid "Hybrid cloud deployments require consideration of two issues that are not common in other situations:" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:298(para) -msgid "Image portability: Note that, as of the Kilo release, there is no single common image format that is usable by all clouds. Conversion or the recreation of images is necessary if porting between clouds. To make things simpler, launch the smallest and simplest images feasible, installing only what is necessary preferably using a deployment manager such as Chef or Puppet. Do not use golden images for speeding up the process. However, if you repeat the deployment of the same images, we recommend utilizing this technique instead of provisioning applications on lighter images each time." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:175(term) ./doc/arch-design/hybrid/section_architecture_hybrid.xml:24(title) +msgid "Image portability" msgstr "" -#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:310(para) -msgid "API differences: Avoid using a hybrid cloud deployment with more than just OpenStack (or with different versions of OpenStack). The APIs need to perform certain functions that are different. The CMP needs to know how to handle all necessary versions. To get around this issue, some implementers build portals to achieve a hybrid cloud environment, but a heavily developer-focused organization may benefit more from a hybrid cloud broker SDK such as jClouds." +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:177(para) +msgid "As of the Kilo release, there is no common image format that is usable by all clouds. Conversion or recreation of images is necessary if migrating between clouds. To simplify deployment, use the smallest and simplest images feasible, install only what is necessary, and use a deployment manager such as Chef or Puppet. Do not use golden images to speed up the process unless you repeatedly deploy the same images on the same cloud." +msgstr "" + +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:187(term) +msgid "API differences" +msgstr "" + +#: ./doc/arch-design/hybrid/section_tech_considerations_hybrid.xml:189(para) +msgid "Avoid using a hybrid cloud deployment with more than just OpenStack (or with different versions of OpenStack) as API changes can cause compatibility issues." msgstr "" #: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:9(para) -msgid "Hybrid cloud architectures are complex, especially those that use heterogeneous cloud platforms. It is important to make sure that design choices match requirements in such a way that the benefits outweigh the inherent additional complexity and risks." +msgid "Hybrid cloud architectures are complex, especially those that use heterogeneous cloud platforms. Ensure that design choices match requirements so that the benefits outweigh the inherent additional complexity and risks." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:13(para) -msgid "Business considerations when designing a hybrid cloud deployment include:" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:14(title) +msgid "Business considerations when designing a hybrid cloud deployment" msgstr "" #: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:19(para) @@ -3860,183 +3776,187 @@ msgid "Revenue opportunity" msgstr "" #: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:33(para) -msgid "Revenue opportunities vary greatly based on the intent and use case of the cloud. As a commercial, customer-facing product, you must consider whether building over multiple platforms makes the design more attractive to customers." +msgid "Revenue opportunities vary based on the intent and use case of the cloud. As a commercial, customer-facing product, you must consider whether building over multiple platforms makes the design more attractive to customers." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:41(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:40(term) msgid "Time-to-market" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:43(para) -msgid "One of the most common reasons to use cloud platforms is to improve the time-to-market of a new product or application. For example, using multiple cloud platforms is viable because there is an existing investment in several applications. It is faster to tie the investments together rather than migrate the components and refactoring them to a single platform." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:42(para) +msgid "One common reason to use cloud platforms is to improve the time-to-market of a new product or application. For example, using multiple cloud platforms is viable because there is an existing investment in several applications. It is faster to tie the investments together rather than migrate the components and refactoring them to a single platform." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:53(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:51(term) msgid "Business or technical diversity" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:55(para) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:53(para) msgid "Organizations leveraging cloud-based services can embrace business diversity and utilize a hybrid cloud design to spread their workloads across multiple cloud providers. This ensures that no single cloud provider is the sole host for an application." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:63(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:61(term) msgid "Application momentum" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:65(para) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:63(para) msgid "Businesses with existing applications may find that it is more cost effective to integrate applications on multiple cloud platforms than migrating them to a single platform." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:93(para) -msgid "Data compliance policies governing certain types of information needs to reside in certain locations due to regular issues and, more importantly, cannot reside in other locations for the same reason." -msgstr "" - -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:99(para) -msgid "Examples of such legal frameworks include the data protection framework of the European Union (Reform of data protection legislation) and the requirements of the Financial Industry Regulatory Authority (FINRA Rules) in the United States. Consult a local regulatory body for more information." -msgstr "" - -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:110(title) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:71(title) msgid "Workload considerations" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:111(para) -msgid "A workload can be a single application or a suite of applications that work together. It can also be a duplicate set of applications that need to run on multiple cloud environments. In a hybrid cloud deployment, the same workload often needs to function equally well on radically different public and private cloud environments. The architecture needs to address these potential conflicts, complexity, and platform incompatibilities. Some possible use cases for a hybrid cloud architecture include:" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:72(para) +msgid "A workload can be a single application or a suite of applications that work together. It can also be a duplicate set of applications that need to run on multiple cloud environments. In a hybrid cloud deployment, the same workload often needs to function equally well on radically different public and private cloud environments. The architecture needs to address these potential conflicts, complexity, and platform incompatibilities." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:122(term) -msgid "Dynamic resource expansion or \"bursting\"" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:81(title) +msgid "Use cases for a hybrid cloud architecture" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:124(para) -msgid "An application that requires additional resources is another common reason you might use a multiple cloud architecture. For example, a retailer needs additional resources during the holiday retail season, but does not want to build expensive cloud resources to meet the peak demand. The user might have an OpenStack private cloud but want to burst to AWS or some other public cloud for these peak load periods. These bursts could be for long or short cycles ranging from hourly to yearly." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:83(term) +msgid "Dynamic resource expansion or bursting" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:136(term) -msgid "Disaster recovery-business continuity" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:85(para) +msgid "An application that requires additional resources may suit a multiple cloud architecture. For example, a retailer needs additional resources during the holiday season, but does not want to add private cloud resources to meet the peak demand. The user can accommodate the increased load by bursting to a public cloud for these peak load periods. These bursts could be for long or short cycles ranging from hourly to yearly." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:138(para) -msgid "The cheaper storage and instance management makes a good case for using the cloud as a secondary site. Using OpenStack public or private cloud in combination with the public cloud for these purposes is popular." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:97(term) +msgid "Disaster recovery and business continuity" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:145(term) -msgid "Federated hypervisor-instance management" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:99(para) +msgid "Cheaper storage makes the public cloud suitable for maintaining backup applications." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:147(para) -msgid "Adding self-service, charge back and transparent delivery of the right resources from a federated pool can be cost effective. In a hybrid cloud environment, this is a particularly important consideration. Look for a cloud that provides cross-platform hypervisor support and robust instance management tools." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:104(term) +msgid "Federated hypervisor and instance management" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:156(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:106(para) +msgid "Adding self-service, charge back, and transparent delivery of the resources from a federated pool can be cost effective. In a hybrid cloud environment, this is a particularly important consideration. Look for a cloud that provides cross-platform hypervisor support and robust instance management tools." +msgstr "" + +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:115(term) msgid "Application portfolio integration" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:158(para) -msgid "An enterprise cloud delivers efficient application portfolio management and deployments by leveraging self-service features and rules for deployments based on types of use. Stitching together multiple existing cloud environments that are already in production or development is a common driver when building hybrid cloud architectures." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:117(para) +msgid "An enterprise cloud delivers efficient application portfolio management and deployments by leveraging self-service features and rules according to use. Integrating existing cloud environments is a common driver when building hybrid cloud architectures." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:167(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:125(term) msgid "Migration scenarios" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:169(para) -msgid "A common reason to create a hybrid cloud architecture is to allow the migration of applications between different clouds. Permanent migration of the application to a new platform is one reason, or another might be because the application requires support on multiple platforms." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:127(para) +msgid "Hybrid cloud architecture enables the migration of applications between different clouds." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:180(para) -msgid "Another important reason for wanting a multiple cloud architecture is to address the needs for high availability. Using a combination of multiple locations and platforms, a design can achieve a level of availability that is not possible with a single platform. This approach does add a significant amount of complexity." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:134(para) +msgid "A combination of locations and platforms enables a level of availability that is not possible with a single platform. This approach increases design complexity." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:190(para) -msgid "In addition to thinking about how the workload works on a single cloud, the design must accommodate the added complexity of needing the workload to run on multiple cloud platforms. We recommend exploring the complexity of transferring workloads across clouds at the application, instance, cloud platform, hypervisor, and network levels." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:141(para) +msgid "As running a workload on multiple cloud platforms increases design complexity, we recommend first exploring options such as transferring workloads across clouds at the application, instance, cloud platform, hypervisor, and network levels." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:199(title) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:148(title) msgid "Tools considerations" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:200(para) -msgid "When working with designs spanning multiple clouds, the design must incorporate tools to facilitate working across those multiple clouds. Some of the user requirements drive the need for tools that perform the following functions:" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:149(para) +msgid "Hybrid cloud designs must incorporate tools to facilitate working across multiple clouds." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:206(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:152(title) +msgid "Tool functions" +msgstr "" + +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:154(term) msgid "Broker between clouds" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:208(para) -msgid "Since the multiple cloud architecture assumes that there are at least two different and possibly incompatible platforms that are likely to have different costs, brokering software evaluates relative costs between different cloud platforms. The name for these solutions is Cloud Management Platforms (CMPs). Examples include Rightscale, Gravitent, Scalr, CloudForms, and ManageIQ. These tools allow the designer to determine the right location for the workload based on predetermined criteria." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:156(para) +msgid "Brokering software evaluates relative costs between different cloud platforms. Cloud Management Platforms (CMP) allow the designer to determine the right location for the workload based on predetermined criteria." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:222(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:163(term) msgid "Facilitate orchestration across the clouds" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:224(para) -msgid "CMPs are tools are used to tie everything together. Using cloud orchestration tools improves the management of IT application portfolios as they migrate onto public, private, and hybrid cloud platforms. We recommend using cloud orchestration tools for managing a diverse portfolio of installed systems across multiple cloud platforms. The typical enterprise IT application portfolio is still comprised of a few thousand applications scattered over legacy hardware, virtualized infrastructure, and now dozens of disjointed shadow public Infrastructure-as-a-Service (IaaS) and Software-as-a-Service (SaaS) providers and offerings." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:165(para) +msgid "CMPs simplify the migration of application workloads between public, private, and hybrid cloud platforms. We recommend using cloud orchestration tools for managing a diverse portfolio of systems and applications across multiple cloud platforms." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:243(title) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:176(title) msgid "Network considerations" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:244(para) -msgid "The network services functionality is an important factor to assess when choosing a CMP and cloud provider. Considerations are functionality, security, scalability and HA. Important tasks for the architecture include the verification and ongoing testing of critical features for the cloud endpoint." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:177(para) +msgid "It is important to consider the functionality, security, scalability, availability, and testability of network when choosing a CMP and cloud provider." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:251(para) -msgid "Decide on a network functionality framework and design a minimum functionality test. This ensures testing and functionality persists during and after upgrades." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:182(para) +msgid "Decide on a network framework and design minimum functionality tests. This ensures testing and functionality persists during and after upgrades." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:256(para) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:188(para) msgid "Scalability across multiple cloud providers may dictate which underlying network framework you choose in different cloud providers. It is important to present the network API functions and to verify that functionality persists across all cloud endpoints chosen." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:264(para) -msgid "High availability implementations vary in functionality and design. Examples of some common methods are active-hot-standby, active-passive and active-active. Development of high availability and test frameworks is necessary to insure understanding of functionality and limitations." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:196(para) +msgid "High availability implementations vary in functionality and design. Examples of some common methods are active-hot-standby, active-passive, and active-active. Development of high availability and test frameworks is necessary to insure understanding of functionality and limitations." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:272(para) -msgid "Consider the security of data between the client, the endpoint, and any traffic that traverses the multiple clouds." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:204(para) +msgid "Consider the security of data between the client and the endpoint, and of traffic that traverses the multiple clouds." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:280(title) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:212(title) msgid "Risk mitigation and management considerations" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:281(para) -msgid "Hybrid cloud architectures introduce additional risk because they add additional complexity and potentially conflicting or incompatible components or tools. However, they also reduce risk by spreading workloads over multiple providers. This means, if one was to go out of business, the organization could remain operational. Heightened risks when using a hybrid cloud architecture include:" +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:213(para) +msgid "Hybrid cloud architectures introduce additional risk because they are more complex than a single cloud design and may involve incompatible components or tools. However, they also reduce risk by spreading workloads over multiple providers." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:290(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:218(title) +msgid "Hybrid cloud risks" +msgstr "" + +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:220(term) msgid "Provider availability or implementation details" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:292(para) -msgid "This can range from the company going out of business to the company changing how it delivers its services. The design of a cloud architecture is meant to be flexible and changeable; however, the cloud is perceived to be both rock solid and ever flexible at the same time." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:222(para) +msgid "Business changes can affect provider availability. Likewise, changes in a provider's service can disrupt a hybrid cloud environment or increase costs." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:302(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:229(term) msgid "Differing SLAs" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:304(para) -msgid "Users of hybrid cloud environments potentially encounter some losses through differences in service level agreements. A hybrid cloud design needs to accommodate the different SLAs the various clouds involved in the design offer, and must address the actual enforceability of the providers' SLAs." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:231(para) +msgid "Hybrid cloud designs must accommodate differences in SLAs between providers, and consider their enforceability." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:314(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:236(term) msgid "Security levels" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:316(para) -msgid "Securing multiple cloud environments is more complex than securing a single cloud environment. We recommend addressing concerns at the application, network, and cloud platform levels. One issue is that different cloud platforms approach security differently, and a hybrid cloud design must address and compensate for differences in security approaches. For example, AWS uses a relatively simple model that relies on user privilege combined with firewalls." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:238(para) +msgid "Securing multiple cloud environments is more complex than securing single cloud environments. We recommend addressing concerns at the application, network, and cloud platform levels. Be aware that each cloud platform approaches security differently, and a hybrid cloud design must address and compensate for these differences." msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:329(term) +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:248(term) msgid "Provider API changes" msgstr "" -#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:331(para) -msgid "APIs are crucial in a hybrid cloud environment. As a consumer of a provider's cloud services, an organization rarely has control over provider changes to APIs. Cloud services that might have previously had compatible APIs may no longer work. This is particularly a problem with AWS and OpenStack AWS-compatible APIs. The planning of OpenStack included the maintenance of compatibility with changes in AWS APIs. However, over time, the APIs have become more divergent in functionality. One way to address this issue is to focus on using only the most common and basic APIs to minimize potential conflicts." +#: ./doc/arch-design/hybrid/section_user_requirements_hybrid.xml:250(para) +msgid "Consumers of external clouds rarely have control over provider changes to APIs, and changes can break compatibility. Using only the most common and basic APIs can minimize potential conflicts." msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. @@ -4173,10 +4093,6 @@ msgstr "" msgid "For your chosen cloud management platform, note the relative levels of support for both monitoring and orchestration." msgstr "" -#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:24(title) -msgid "Image portability" -msgstr "" - #: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:25(para) msgid "The majority of cloud workloads currently run on instances using hypervisor technologies. The challenge is that each of these hypervisors uses an image format that may not be compatible with the others. When possible, standardize on a single hypervisor and instance image format. This may not be possible when using externally-managed public clouds." msgstr "" @@ -4269,6 +4185,10 @@ msgstr "" msgid "It is imperative to address security considerations. For example, addressing how data is secured between client and endpoint and any traffic that traverses the multiple clouds. Business and regulatory requirements dictate what security approach to take. For more information, see the Security Requirements Chapter" msgstr "" +#: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:168(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:777(para) +msgid "Data" +msgstr "" + #: ./doc/arch-design/hybrid/section_architecture_hybrid.xml:169(para) msgid "Traditionally, replication has been the best method of protecting object store implementations. A variety of replication methods exist in storage architectures, for example synchronous and asynchronous mirroring. Most object stores and back-end storage systems implement methods for replication at the storage subsystem layer. Object stores also tailor replication techniques to fit a cloud's requirements." msgstr "" @@ -4584,7 +4504,7 @@ msgid "Broker" msgstr "" #: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:42(para) -msgid "The connection broker is a central component of the architecture that determines which remote desktop host the user connects to. The broker is often a full-blown management product enabling the automated deployment and provisioning of remote desktop hosts." +msgid "The connection broker determines which remote desktop host users can access. Medium and large scale environments require a broker since its service represents a central component of the architecture. The broker is a complete management product, and enables automated deployment and provisioning of remote desktop hosts." msgstr "" #: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:49(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:28(title) ./doc/arch-design/specialized/section_networking_specialized.xml:23(title) @@ -4592,10 +4512,10 @@ msgid "Possible solutions" msgstr "" #: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:50(para) -msgid "There are a number of commercial products currently available that provide such a broker solution but nothing that is native to the OpenStack project. Not providing a broker is also an option, but managing this manually would not suffice for a large scale, enterprise solution." +msgid "There are a number of commercial products currently available that provide a broker solution. However, no native OpenStack projects provide broker services. Not providing a broker is also an option, but managing this manually would not suffice for a large scale, enterprise solution." msgstr "" -#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:59(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:40(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:70(title) +#: ./doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml:59(title) ./doc/arch-design/specialized/section_software_defined_networking_specialized.xml:40(title) ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:71(title) msgid "Diagram" msgstr "" @@ -4637,7 +4557,7 @@ msgstr "" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:74(None) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:75(None) msgid "@@image: '../figures/Specialized_OOO.png'; md5=65a8e3666ebf09a0145c61bc1d472144" msgstr "" @@ -4646,42 +4566,46 @@ msgid "OpenStack on OpenStack" msgstr "" #: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:13(para) -msgid "In some cases it is necessary to run OpenStack nested on top of another OpenStack cloud. This scenario enables you to manage and provision complete OpenStack cloud environments on instances running on hypervisors and servers that the underlying OpenStack cloud controls. Public cloud providers can use this technique to manage the upgrade and maintenance process on complete OpenStack-based clouds. Developers and those testing OpenStack can also use this guidance to provision their own OpenStack environments on available OpenStack Compute resources, whether public or private." +msgid "In some cases, users may run OpenStack nested on top of another OpenStack cloud. This scenario describes how to manage and provision complete OpenStack environments on instances supported by hypervisors and servers, which an underlying OpenStack environment controls." +msgstr "" + +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:18(para) +msgid "Public cloud providers can use this technique to manage the upgrade and maintenance process on complete OpenStack environments. Developers and those testing OpenStack can also use this technique to provision their own OpenStack environments on available OpenStack Compute resources, whether public or private." msgstr "" #: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:26(para) -msgid "The network aspect of deploying a nested cloud is the most complicated aspect of this architecture. You must expose VLANs to the physical ports on which the underlying cloud runs, as the bare metal cloud owns all the hardware, but you must also expose them to the nested levels as well. Alternatively, you can use the network overlay technologies on the OpenStack cloud running on OpenStack to provide the required software defined networking for the deployment." +msgid "The network aspect of deploying a nested cloud is the most complicated aspect of this architecture. You must expose VLANs to the physical ports on which the underlying cloud runs because the bare metal cloud owns all the hardware. You must also expose them to the nested levels as well. Alternatively, you can use the network overlay technologies on the OpenStack environment running on the host OpenStack environment to provide the required software defined networking for the deployment." msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:36(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:425(title) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(title) ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:425(title) msgid "Hypervisor" msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:37(para) -msgid "A key question to address in this scenario is which approach you should take to provide a nested hypervisor in OpenStack. This decision influences which operating systems you use for the deployment of the nested OpenStack deployments." +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:38(para) +msgid "In this example architecture, consider which approach you should take to provide a nested hypervisor in OpenStack. This decision influences which operating systems you use for the deployment of the nested OpenStack deployments." msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:44(title) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:45(title) msgid "Possible solutions: deployment" msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:45(para) -msgid "Deployment of a full stack can be challenging but you can mitigate this difficulty by creating a Heat template to deploy the entire stack or a configuration management system. After creating the Heat template, you can automate the deployment of additional stacks." +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:46(para) +msgid "Deployment of a full stack can be challenging but you can mitigate this difficulty by creating a Heat template to deploy the entire stack, or a configuration management system. After creating the Heat template, you can automate the deployment of additional stacks." msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:49(para) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:50(para) msgid "The OpenStack-on-OpenStack project (TripleO) addresses this issue. Currently, however, the project does not completely cover nested stacks. For more information, see https://wiki.openstack.org/wiki/TripleO." msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:56(title) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:57(title) msgid "Possible solutions: hypervisor" msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:57(para) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:58(para) msgid "In the case of running TripleO, the underlying OpenStack cloud deploys the Compute nodes as bare-metal. You then deploy OpenStack on these Compute bare-metal servers with the appropriate hypervisor, such as KVM." msgstr "" -#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:61(para) +#: ./doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml:62(para) msgid "In the case of running smaller OpenStack clouds for testing purposes, where performance is not a critical factor, you can use QEMU instead. It is also possible to run a KVM hypervisor in an instance (see http://davejingtian.org/2014/03/30/nested-kvm-just-for-fun/), though this is not a supported configuration, and could be a complex solution for such a use case." msgstr "" @@ -4712,11 +4636,11 @@ msgid "Specialized hardware" msgstr "" #: ./doc/arch-design/specialized/section_hardware_specialized.xml:9(para) -msgid "Certain workloads require specialized hardware devices that are either difficult to virtualize or impossible to share. Applications such as load balancers, highly parallel brute force computing, and direct to wire networking may need capabilities that basic OpenStack components do not provide." +msgid "Certain workloads require specialized hardware devices that have significant virtualization or sharing challenges. Applications such as load balancers, highly parallel brute force computing, and direct to wire networking may need capabilities that basic OpenStack components do not provide." msgstr "" #: ./doc/arch-design/specialized/section_hardware_specialized.xml:17(para) -msgid "Some applications need access to hardware devices to either improve performance or provide capabilities that are not virtual CPU, RAM, network, or storage. These can be a shared resource, such as a cryptography processor, or a dedicated resource, such as a Graphics Processing Unit. OpenStack can provide some of these, while others may need extra work." +msgid "Some applications need access to hardware devices to either improve performance or provide capabilities that are not virtual CPU, RAM, network, or storage. These can be a shared resource, such as a cryptography processor, or a dedicated resource, such as a Graphics Processing Unit (GPU). OpenStack can provide some of these, while others may need extra work." msgstr "" #: ./doc/arch-design/specialized/section_hardware_specialized.xml:26(title) @@ -4724,7 +4648,7 @@ msgid "Solutions" msgstr "" #: ./doc/arch-design/specialized/section_hardware_specialized.xml:27(para) -msgid "To provide cryptography offloading to a set of instances, you can use Image service configuration options to assign the cryptography chip to a device node in the guest. The OpenStack Command Line Reference contains further information on configuring this solution in the chapter Image service property keys, but it allows all guests using the configured images to access the hypervisor cryptography device." +msgid "To provide cryptography offloading to a set of instances, you can use Image service configuration options. For example, assign the cryptography chip to a device node in the guest. The OpenStack Command Line Reference contains further information on configuring this solution in the chapter Image service property keys. A challenge, however, is this option allows all guests using the configured images to access the hypervisor cryptography device." msgstr "" #: ./doc/arch-design/specialized/section_hardware_specialized.xml:37(para) @@ -5879,6 +5803,18 @@ msgstr "" msgid "A security domain comprises users, applications, servers or networks that share common trust requirements and expectations within a system. Typically they have the same authentication and authorization requirements and users." msgstr "" +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:765(para) +msgid "These security domains are:" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:768(para) +msgid "Public" +msgstr "" + +#: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:771(para) +msgid "Guest" +msgstr "" + #: ./doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml:780(para) msgid "These security domains can be mapped to an OpenStack deployment individually, or combined. For example, some deployment topologies combine both guest and data domains onto one physical network, whereas in other cases these networks are physically separated. In each case, the cloud operator should be aware of the appropriate security concerns. Security domains should be mapped out against your specific OpenStack deployment topology. The domains and their trust requirements depend upon whether the cloud instance is public, private, or hybrid." msgstr "" diff --git a/doc/arch-design/locale/zh_CN.po b/doc/arch-design/locale/zh_CN.po index c97713e1cc..8ac86f9aa3 100644 --- a/doc/arch-design/locale/zh_CN.po +++ b/doc/arch-design/locale/zh_CN.po @@ -9,8 +9,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2015-08-14 19:12+0000\n" -"PO-Revision-Date: 2015-08-14 19:14+0000\n" +"POT-Creation-Date: 2015-08-19 01:35+0000\n" +"PO-Revision-Date: 2015-08-19 01:37+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Chinese (China) (http://www.transifex.com/openstack/openstack-" "manuals-i18n/language/zh_CN/)\n" @@ -141,26 +141,6 @@ msgstr "" "己的数据库和消息队列(理想情况下是集群化的)，并提供将负载细分到这些子系统中的" "功能，以提高整体性能。" -msgid "" -"Hybrid cloud, by " -"definition, means that the design spans more than one cloud. An example of " -"this kind of architecture may include a situation in which the design " -"involves more than one OpenStack cloud (for example, an OpenStack-based " -"private cloud and an OpenStack-based public cloud), or it may be a situation " -"incorporating an OpenStack cloud and a non-OpenStack cloud (for example, an " -"OpenStack-based private cloud that interacts with Amazon Web Services). " -"Bursting into an external cloud " -"is the practice of creating new instances to alleviate extra load where " -"there is no available capacity in the private cloud." -msgstr "" -"混合云,依据定义，意思就是跨" -"多个云的设计。举个这种类型架构的例子，设计包含多个OpenStack云的情景(例如，一" -"个是基于OpenStack的私有云，另外一个是基于OpenStack的公有云)，又或许是一个" -"OpenStack云和一个非OpenStack云的互操作的情况(例如，一个基于OpenStack的私有云" -"和Amazon Web Services互相操作).突破 到外部的云，当私有云没有可用的资源时，系统可以自动到外部的云去建立" -"新的实例。" - msgid "" "Orchestration module (heat)" msgstr "" @@ -453,13 +433,6 @@ msgstr "" "@@image: '../figures/Storage_Object.png'; " "md5=ad0b4ee39c96ab081a368ef7857479a5" -msgid "" -"A Distributed DNS service available to all regionsthat allows for dynamic " -"update of DNS records of deployed instances." -msgstr "" -"在所有的region中都有一个分布式DNS服务可用，允许动态的为已经部署的实例更新DNS" -"记录。" - msgid "" "A common requirement is to define different roles for the different cloud " "administration functions. An example would be a requirement to segregate the " @@ -564,15 +537,6 @@ msgstr "" "用。运维花费更高的原因在于相比与其它架构需要更多复杂的编排以及额外的工具。相" "比之下，整体运营成本可能在最具成本效益的平台中使用云运营工具部署负载会降低。" -msgid "" -"A key question to address in this scenario is which approach you should take " -"to provide a nested hypervisor in OpenStack. This decision influences which " -"operating systems you use for the deployment of the nested OpenStack " -"deployments." -msgstr "" -"这种场景中需要解决的一个关键问题是决定采用何种方式为嵌套的 OpenStack 环境提供" -"宿主机。这个决定将会影响在嵌套 OpenStack 部署中哪些操作系统可以被使用。" - msgid "" "A large, monolithic, single-tiered legacy application typically isn't a good " "fit for the cloud. Efficiencies are gained when load can be spread over " @@ -584,48 +548,12 @@ msgstr "" "割为多个实例会获得高效，所以部分系统失效不会特别影响其他部分的系统，或者说随" "应用的需要而横向扩展。" -msgid "" -"A large-scale web application has been designed with cloud principles in " -"mind. The application is designed provide service to application store, on a " -"24/7 basis. The company has typical 2-tier architecture with a web front-end " -"servicing the customer requests and a NoSQL database back end storing the " -"information." -msgstr "" -"在脑子里想着一个大型扩展的web应用被设计为遵循云的原则。应用被设计为在应用商店" -"中7*24的提供服务，公司拥有典型的2层架构，前端是用户需求的web服务，后端是用" -"NoSQL数据库存放信息。" - msgid "" "A measure of how many servers can fit into a given measure of physical " "space, such as a rack unit [U]." msgstr "" "关于多少台服务器能够放下到一个给定尺寸的物理空间的量度，比如一个机柜单位[U]。" -msgid "" -"A multi-site OpenStack environment is one in which services, located in more " -"than one data center, are used to provide the overall solution. Usage " -"requirements of different multi-site clouds may vary widely, but they share " -"some common needs. OpenStack is capable of running in a multi-region " -"configuration. This enables some parts of OpenStack to effectively manage a " -"group of sites as a single cloud. With careful planning in the design phase, " -"OpenStack can act as an excellent multi-site cloud solution for a multitude " -"of needs." -msgstr "" -"一个多区域openstack环境是指它的服务分布在多个数据中心来提供整体的服务.不同的" -"多区域云可能在使用要求上区别会很大,然而它们还是有一些共同点的.openstack可以运" -"行在多区域环境下,允许某部分服务有效地像管理一个单区域的云一样来管理着由多个区" -"域组成的群组.通过在设计阶段仔细计划,面对不同的需求,openstack可以是一个多区域" -"云的完美解决方案" - -msgid "" -"A multi-site architecture is complex and has its own risks and " -"considerations, therefore it is important to make sure when contemplating " -"the design such an architecture that it meets the user and business " -"requirements." -msgstr "" -"一个多区域架构是复杂的而且尤其自身的风险和考虑，因此确保考虑此架构的设计应满" -"足用户和业务的需求显得异常重要。" - msgid "" "A network designed on layer-2 protocols has advantages over one designed on " "layer-3 protocols. In spite of the difficulties of using a bridge to perform " @@ -718,26 +646,6 @@ msgstr "" "一个存储型设计也许需要使用Orchestration，能够启动带块设备卷的实例，以满足存储" "密集型任务处理。" -msgid "" -"A third form of capacity comes in the multi-region-capable components of " -"OpenStack. Centralized Object Storage is capable of serving objects through " -"a single namespace across multiple regions. Since this works by accessing " -"the object store via swift proxy, it is possible to overload the proxies. " -"There are two options available to mitigate this issue. The first is to " -"deploy a large number of swift proxies. The drawback to this is that the " -"proxies are not load-balanced and a large file request could continually hit " -"the same proxy. The other way to mitigate this is to front-end the proxies " -"with a caching HTTP proxy and load balancer. Since swift objects are " -"returned to the requester via HTTP, this load balancer would alleviate the " -"load required on the swift proxies." -msgstr "" -"第三种形式的容量表现在multi-region-capable 的OpenStack组件，中心化的对象存储" -"在跨多region通过单一的命名空间能够服务对象。此工作方式由swift代理来访问对象信" -"息，因此是有可能代理过度负载。有两种方法可减低此问题，第一，部署大量的swift代" -"理，此方法的缺陷在于代理没有负载均衡，大量的文件请求会访问同一个proxy。第二种" -"降低负载的办法是在代理的前端使用HTTP代理缓存和负载均衡器。因此swift对象会通过" -"HTTP来响应请求，此负载均衡器能缓和swift代理的负载请求。" - msgid "A three-node MariaDB and Galera cluster, each with 4 vCPUs and 8 GB RAM" msgstr "MariaDB安装在3个节点并组成Galera集群，每节点拥有4 vCPU和8GB内存" @@ -939,14 +847,6 @@ msgstr "" "需求而能够灵活扩展。他们目前的环境不具有灵活的调整目标到运行开源的应用程序接" "口环境。目前的环境是如下面这样：" -msgid "" -"An organization could have certain legal obligations and regulatory " -"compliance measures which could require certain workloads or data to not be " -"located in certain regions." -msgstr "" -"一个组织须有一定的法律义务和法规遵从来衡量什么是需要的负载或数据能否存放在指" -"定的地区。" - msgid "An organization with a diverse geographic footprint." msgstr "一个有不同地域认证的组织" @@ -975,15 +875,6 @@ msgstr "" "DNS64。这使得实例都有全局可达的 IPv6 地址，同时只在必要的情况下，或者以共享的" "方式使用 IPv4 地址。" -msgid "" -"Another option to address the higher host count is to use a quad socket " -"platform. Taking this approach decreases host density which also increases " -"rack count. This configuration affects the number of power connections and " -"also impacts network and cooling requirements." -msgstr "" -"解决高主机计数的另外的办法是使用四路平台。这样的话降低了主机密度，也增加了机" -"架数，这样的配置会影响到网络需求，电源连接数量，还有可能影响的制冷需求。" - msgid "" "Anthony Veiga (Comcast) @daaelar" @@ -991,19 +882,6 @@ msgstr "" "Anthony Veiga (Comcast) @daaelar" -msgid "" -"Any chosen OS/hypervisor combination should be chosen based on the " -"interoperability with one another, and other OS-hyervisor combinations. " -"Operational and troubleshooting tools for one OS-hypervisor combination may " -"differ from the tools used for another OS-hypervisor combination. As a " -"result, the design must address if the two sets of tools need to " -"interoperate." -msgstr "" -"用户需要考虑此操作系统和Hypervisor组合和另外的操作系统和hypervisor怎么互动，" -"甚至包括和其它的软件。操作某一操作系统-hypervisor组合的故障排除工具，和操作其" -"他的操作系统-hypervisor组合也许根本就不一样，那结果就是，设计时就需要交付此两" -"种工具集的互操作性。" - msgid "Application awareness" msgstr "应用的可知性" @@ -1078,31 +956,11 @@ msgstr "" "作为基础产品，通用型云并不对任何特定的功能提供优化性能。虽然通用型云希望能够" "提供足够的性能以满足所以用户的考虑，但是性能本身并不是通用型云所关注的。" -msgid "" -"As a hybrid cloud design deals with systems that are outside of the control " -"of the cloud architect or organization, a hybrid cloud architecture requires " -"considering aspects of the architecture that might not have otherwise been " -"necessary. For example, the design may need to deal with hardware, software, " -"and APIs under the control of a separate organization." -msgstr "" -"作为混合云设计所处理的系统，其实已经不是云架构或组织所能控制的，一个混合云架" -"构需要考虑架构的方面可能没有其他云所必须的。举例，设计也许需要处理硬件、软" -"件、以及其他组织控制下的应用程序接口。" - msgid "" "As of 2011 CERN operated these two compute centers in Europe with plans to " "add a third." msgstr "CERN在2011年准备在欧洲建立第三个数据中心。" -msgid "" -"As of late there has been several outages in number of major public cloud " -"providersusually due to the fact these applications were running out of a " -"single geographical location. The design therefore should mitigate the " -"chance of a single site causing an outage for their business." -msgstr "" -"最后，经常由于一些因素他们的应用运行在单个地理位置,主要的公有云提供者因此会停" -"止一些服务。因此设计中要考虑如何降低由于单个站点引起的中断业务的几率。" - msgid "" "As you add back-end storage capacity to the system, the partition maps " "redistribute data amongst the storage nodes. In some cases, this replication " @@ -1174,19 +1032,6 @@ msgstr "" "基于云中实例提供的服务的需求，网络服务的选择将会是影响用户设计架构的下一个决" "定。" -msgid "" -"Based on the selected storage solution, ensure the connectivity matches the " -"storage solution requirements. If selecting centralized storage array, " -"determine how the hypervisors connect to the storage array. Connectivity can " -"affect latency and thus performance. We recommended confirming that the " -"network characteristics minimize latency to boost the overall performance of " -"the design." -msgstr "" -"根据所选择的存储解决方案，要确保它的连接和存储解决方案的需求是匹配的。如果是" -"选择了中心化的存储阵列，决定有多少台hypervisor会连接到此阵列中是很重要的。连" -"接会影响到延迟以及它们的性能，所以监测网络因素以达到最小延迟，提升整体的性" -"能。" - msgid "" "Be a pessimist: Assume everything fails and design backwards. Love your " "chaos monkey." @@ -1335,18 +1180,6 @@ msgstr "CPU密集型" msgid "Capacity" msgstr "容量" -msgid "" -"Capacity can take other forms as well. The ability for a region to grow " -"depends on scaling out the number of available compute nodes. This topic is " -"covered in greater detail in the section for compute-focused deployments. " -"However, it should be noted that cells may be necessary to grow an " -"individual region beyond a certain point. This point depends on the size of " -"your cluster and the ratio of virtual machines per hypervisor." -msgstr "" -"容量还有其它形式的表现，region增长的能力依赖于横向扩展更多可用的计算节点。此" -"话题在章节计算型中会谈到更多的细节。总之，务必记得也许需要为各个region增加" -"cell以超过一定的点，此点又依赖于集群的大小和每hypervisor对虚拟机的比例。" - msgid "Capacity constraints for a general purpose cloud environment include:" msgstr "在通用型云环境中的容量限制包括：" @@ -1384,31 +1217,12 @@ msgstr "" "确定硬件的形式，也许更适合通用型OpenStack云，因为通用型有对资源的对等(接近对" "等)平衡的需求。服务器硬件须提供如下资源平衡细节描述：" -msgid "" -"Certain locations might require local vendors to provide support and " -"services for each site provides challenges, but will vary on the licensing " -"agreement in place." -msgstr "" -"为应对不同站点的挑战，某些地点也许需要当地供应商的支持和服务，但是都得遵循当" -"地的许可协议。" - msgid "" "Certain use cases may benefit from exposure to additional devices on the " "compute node. Examples might include:" msgstr "" "在计算节点中使用一些额外的设备对于某些用例有着显著的益处。举几个常见的例子：" -msgid "" -"Certain workloads require specialized hardware devices that are either " -"difficult to virtualize or impossible to share. Applications such as load " -"balancers, highly parallel brute force computing, and direct to wire " -"networking may need capabilities that basic OpenStack components do not " -"provide." -msgstr "" -"有些特定的负载需要难以虚拟化或者无法共享的特殊的硬件设备。例如负载均衡器、高" -"并行暴力运算以及与网线直接相连的联网等应用，都可能需要基本 OpenStack 组件不提" -"供的功能。" - msgid "Challenges" msgstr "挑战" @@ -1591,17 +1405,6 @@ msgstr "" "然后通过配置准备系统，对它们分别创建配置文件以及保证系统的状态。由于错误或者" "故障而离开预定义的状态的系统很快就会被从活动节点池中移除，并被替换。" -msgid "" -"Connecting more than two sites increases the challenges and adds more " -"complexity to the design considerations. Multi-site implementations require " -"extra planning to address the additional topology complexity used for " -"internal and external connectivity. Some options include full mesh topology, " -"hub spoke, spine leaf, or 3d Torus." -msgstr "" -"连接多于两个站点会增加挑战，会给设计考虑增加更多的复杂性。多站点实现需要额外" -"的规划，增加交付内外部连通性的复杂拓扑，一些选项包括完全mesh拓扑，hub spoke," -"spine leaf,或3d Torus。" - msgid "" "Connecting specialized network applications to their required resources " "alters the design of an OpenStack installation. Installations that rely on " @@ -1624,12 +1427,6 @@ msgstr "" "为认证流程的一部分。Including such systems in an OpenStack deployment may " "ease user management if integrating into existing systems." -msgid "" -"Considerations affecting storage architecture (and corresponding storage " -"hardware) of a Storage-focused OpenStack cloud:" -msgstr "" -"一些潜在的可能影响到存储型OpenStack云的特定的存储架构(及其相应的存储硬件):" - msgid "Consistency of images and templates across different sites" msgstr "镜像和模板在跨不同站点时要保持一致性。" @@ -1694,22 +1491,6 @@ msgstr "" "数据合规性-基于常规某些类型的数据需要放在某些位置，同样的原因，不能放在其他位" "置更加的重要。" -msgid "" -"Data compliance policies governing certain types of information needs to " -"reside in certain locations due to regular issues and, more importantly, " -"cannot reside in other locations for the same reason." -msgstr "" -"管理由于监管上的问题因而特定类型的数据必须存放在特定的地点或者更重要的，由于" -"相同的原因，不能够存放在其它地点的数据管理政策。" - -msgid "" -"Data compliance policies governing types of information that needs to reside " -"in certain locations due to regular issues and, more importantly, cannot " -"reside in other locations for the same reason." -msgstr "" -"数据合规性,管理由于监管上的问题因而特定类型的数据必须存放在特定的地点或者更重" -"要的，由于相同的原因，不能够存放在其它地点的数据管理政策。" - msgid "Data grids" msgstr "数据网格" @@ -1767,9 +1548,6 @@ msgstr "" msgid "Databases." msgstr "数据库。" -msgid "Deep dive into the CERN Cloud Infrastructure" -msgstr "深入学习CERN云基础设施" - msgid "Dependencies" msgstr "依赖" @@ -1783,14 +1561,6 @@ msgstr "" "才可支持所选定的操作系统和hpervisor组合。如果没有的话，那么在设计中就得考虑培" "训的提供是需要另外的开销的。" -msgid "" -"Deployers must be aware of this and provide the appropriate customization of " -"the service catalog for their site either manually or via customization of " -"the deployment tools in use." -msgstr "" -"部署者务必意识到这点，为他们的站点提供合适的定制服务目录，无论是手动还是定" -"制，都的使用这些部署工具。" - msgid "" "Deploying an OpenStack installation using OpenStack Networking with a " "provider network allows direct layer-2 connectivity to an upstream " @@ -1811,30 +1581,6 @@ msgstr "" "治系统的 BGP 点对点连接能够存在。应该尽量避免使用三层网络的插件，因为它们会分" "隔广播域并且阻止邻接路由器的形成。" -msgid "" -"Deployment of a full stack can be challenging but you can mitigate this " -"difficulty by creating a Heat template to deploy the entire stack or a " -"configuration management system. After creating the Heat template, you can " -"automate the deployment of additional stacks." -msgstr "" -"部署整个 OpenStack 环境是比较麻烦的，不过这个困难可以被轻松化解，通过创建一" -"个 Heat 模板来部署整个环境或者使用一个配置管理系统。一旦 Heat 模板创建完成，" -"部署新的 OpenStack 环境就变得非常简单并且可以使用自动化方式完成。" - -msgid "" -"Deployment of a multi-site OpenStack cloud using regions requires that the " -"service catalog contains per-region entries for each service deployed other " -"than the Identity service itself. There is limited support amongst currently " -"available off-the-shelf OpenStack deployment tools for defining multiple " -"regions in this fashion." -msgstr "" -"使用region来部署一个多区域OpenStack云，要求每个部署的服务的服务目录包含per-" -"region元素，不仅仅是认证服务本身。当前现成的OpenStack部署工具中，对于定义多" -"region的支持还很有限。" - -msgid "Deploys instances" -msgstr "部署实例" - msgid "" "Design a dense multi-path network core to support multi-directional scaling " "and flexibility." @@ -1915,17 +1661,6 @@ msgstr "决定的是如果用例中拥有并行或高度变化的延迟。" msgid "Determine the most effective configuration for block storage network." msgstr "确定块存储网络的最高效配置。" -msgid "" -"Determine the required features of OpenStack. This often determines the " -"selection of the OS-hypervisor combination. Certain features are only " -"available with specific OSes or hypervisors. For example, if certain " -"features are not available, you might need to modify the design to meet user " -"requirements." -msgstr "" -"决定那些特性是需要OpenStack提供的。这通常也决定了操作系统-hypervisor组合的选" -"择。一些特性仅在特定的操作系统和hypervisor中是可用的。举例，如果确认某些特性" -"无法实现，设计也许需要修改代码去满足用户的需求。" - msgid "" "Determine which features of OpenStack are required. This will often " "determine the selection of the OS-hypervisor combination. Some features are " @@ -1937,15 +1672,6 @@ msgstr "" "择。一些特性仅在特定的操作系统和hypervisor中是可用的。举例，如果确认某些特性" "无法实现，设计也许需要修改代码去满足用户的需求。" -msgid "" -"Determining the performance of a multi-site installation involves " -"considerations that do not come into play in a single-site deployment. Being " -"a distributed deployment, multi-site deployments incur a few extra penalties " -"to performance in certain situations." -msgstr "" -"决定多区域安装的性能所包含的考虑因素和在单站点部署是不一样的，作为分布式部" -"署，多区域部署在一些场景中会遭遇一些额外的性能瓶颈。" - msgid "Determining whether an application is cloud-ready" msgstr "决定那些应用程序是可在云中运行" @@ -1955,14 +1681,6 @@ msgstr "开发和测试" msgid "Diagram" msgstr "图示" -msgid "" -"Differentiations between \"hot\" (active) and \"cold\" (inactive) sites " -"where significant savings may be made in situations where one site is a cold " -"standby for disaster recovery purposes only." -msgstr "" -"“热”(活动)和\"冷\"(非活动)站点之间的区别在于，冷的预备站点只是用于灾难恢复的" -"情况发生。" - msgid "Differing SLAs" msgstr "服务水平协议比较" @@ -2019,14 +1737,6 @@ msgstr "" "求，安排到从可用的单元中选出的一个特定单元上。单元内部常规的过滤调度器将负责" "其内部的这种安排。" -msgid "" -"Ensure determination of the method for resuming proper operations of a site " -"when it comes back online after a disaster. We recommend you architect the " -"recovery to avoid race conditions." -msgstr "" -"确保在灾难发生之后，当业务恢复正常之前的这段时间内，恢复站点的正确操作的几种" -"办法要决定下来。我们建议用户恢复的架构要避免竞争状态。" - msgid "" "Ensure that selected OS and hypervisor combinations meet the appropriate " "scale and performance requirements. The chosen architecture will need to " @@ -2047,17 +1757,6 @@ msgstr "" "hypervisor组合打安全补丁的频率会影响到性能，而且补丁的安装流程也会影响到维护" "工作。" -msgid "" -"Ensure that the design can accommodate the regular periodic installation of " -"application security patches while maintaining the required workloads. The " -"frequency of security patches for the proposed OS-hypervisor combination " -"impacts performance and the patch installation process could affect " -"maintenance windows." -msgstr "" -"确保设计能够在维护负载需求时能够容纳正常的所安装的应用的安全补丁。为操作系统-" -"hypervisor组合打安全补丁的频率会影响>到性能，而且补丁的安装流程也会影响到维护" -"工作。" - msgid "" "Ensure that the physical data center provides the necessary power for the " "selected network hardware." @@ -2073,15 +1772,6 @@ msgstr "" "没有什么影响，但是spine交换机的叶和fabric以及排尾交换机(EoR)就可能发生问题，" "假如电力不足的话。" -msgid "" -"Ensure that the selected OS and hypervisor combination meet the appropriate " -"scale and performance requirements needed for this storage focused OpenStack " -"cloud. The chosen architecture must meet the targeted instance-host ratios " -"with the selected OS-hypervisor combination." -msgstr "" -"确保所选择的操作系统和hypervisor组合能够满足扩展和性能的需求。所选择的架构需" -"要满足目标实例-主机的比例。" - msgid "" "Ensure that the selected server hardware is configured to support enough " "storage capacity (or storage expandability) to match the requirements of " @@ -2096,11 +1786,6 @@ msgstr "" "的集中存储阵列需要InfiniBand或FDDI连接，那么服务器硬件就需要安装对应的网卡来" "兼容此特定厂商的存储阵列。" -msgid "" -"Ensure that the storage solution throughput is optimized based on " -"application requirements." -msgstr "要确保存储解决方案是基于应用的需求整个被优化。" - msgid "" "Ensure that, if storage protocols other than Ethernet are part of the " "storage solution, the appropriate hardware has been selected. If a " @@ -2157,9 +1842,6 @@ msgstr "" "以太网帧包含了所有联网所需的要素。这些要素包括但不限于，全局唯一的源地址，全" "局唯一的目标地址，以及错误控制。" -msgid "Evaluate Compute (server) hardware four opposing dimensions:" -msgstr "模拟计算(服务器)硬件需要从以下四个不同的方面进行评估：" - msgid "Example applications deployed with cloud storage characteristics:" msgstr "以下是云存储类型的应用部署的例子：" @@ -2210,14 +1892,6 @@ msgstr "" "量。举例，一个存储架构为专注于开发者平台的云和商业产品云在expandability和" "scalability上就不可能一样。" -msgid "" -"Expandability is the overall ability of the solution to grow. A storage " -"solution that expands to 50 PB is more expandable than a solution that only " -"scales to 10 PB." -msgstr "" -"规模扩展性是指在整个解决方案的扩张的整体能力。一个存储解决方案可以扩展到" -"50PB，一定比仅能扩展到10PB的规模扩展性强，也会更加倾向于前者。" - msgid "Expansion planning" msgstr "扩展计划" @@ -2289,14 +1963,6 @@ msgstr "" "对于通用型OpenStack云来说，基础设施组件需要高可用。如果设计时没有包括硬件的负" "载均衡器，那么就得包含网络软件包如HAProxy。" -msgid "" -"For a storage-focused OpenStack design architecture, the selection of " -"storage hardware determines the overall performance and scalability of the " -"design architecture. Several factors impact the design process:" -msgstr "" -"对于存储型OpenStack架构设计来说，存储硬件的选择将决定整个架构的性能和可扩展" -"性。在设计过程中，一些需要考虑的不同因素：" - msgid "" "For a user of a massively scalable OpenStack public cloud, there are no " "expectations for control over security, performance, or availability. Users " @@ -2373,15 +2039,6 @@ msgstr "" "用是被设计为容错的，那么就要额外考虑支持实例的迁移，也需要额外的支持服务，包" "括共享存储挂载到计算主机，就需要被部署。" -msgid "" -"For example, if a physical node has 48 GB of RAM, the scheduler allocates " -"instances to that node until the sum of the RAM associated with the " -"instances reaches 72 GB (such as nine instances, in the case where each " -"instance has 8 GB of RAM)." -msgstr "" -"举例来说，如果一台物理节点有48GB的内存，调度器为实例分配的内存总量要少于" -"72GB(如果每个实例分配了8GB内存的话，此节点可建立9个实例)。" - msgid "" "For example, many sled servers offer four independent dual-socket nodes in " "2U for a total of 8 CPU sockets in 2U. However, the dual-socket limitation " @@ -2426,15 +2083,6 @@ msgstr "" "更多关于OpenStack安全的信息，请访问OpenStack 安全指南。" -msgid "" -"For more information on Flavors see: http://docs.openstack.org/" -"openstack-ops/content/flavors.html" -msgstr "" -"对于Flavor的更多信息请参考： http://docs.openstack.org/openstack-ops/" -"content/flavors.html" - msgid "" "For more information on high availability in OpenStack, see the " msgstr "OpenStack 加入到 SDN 控制器所控制的网络中：" -msgid "" -"OpenStack provides a default set of Role Based Access Control (RBAC) " -"policies, defined in a policy.json file, for each " -"service. Operators edit these files to customize the policies for their " -"OpenStack installation. If the application of consistent RBAC policies " -"across sites is considered a requirement, then it is necessary to ensure " -"proper synchronization of the policy.json files to all " -"installations." -msgstr "" -"OpenStack默认提供的是基于角色访问控制(RBAC)规则，在每个服务中，在文件" -"policy.json定义。运维人员可以编辑此文件来定制规则。如果" -"跨区域被认为有需要将RBAC规则一致处理的话，那么就有必要确保在所有的安装配置中" -"将文件policy.json保持同步。" - msgid "OpenStack services architecture" msgstr "OpenStack服务架构" @@ -4303,31 +3812,9 @@ msgstr "运营者的需求" msgid "Orchestration (heat)" msgstr "编排 (heat)" -msgid "" -"Orchestration is used because of the built-in functionality of autoscaling " -"and auto healing in the event of increased load. Additional configuration " -"management tools, such as Puppet or Chef could also have been used in this " -"scenario, but were not chosen due to the fact that Orchestration had the " -"appropriate built-in hooks into the OpenStack cloudwhereas the other tools " -"were external and not native to OpenStack. In additionsince this deployment " -"scenario was relatively straight forwardthe external tools were not needed." -msgstr "" -"这里用到Orchestration是由于自动伸缩的内部功能和偶然增长的负载后的自动复原功" -"能。另外一些配置管理工具，如Puppet或Chef也会在此场景下用到，但是不会被选择用" -"于Orchestration，在OpenStack云中它们做不到内部的钩子，也不是OpenStack本身的工" -"具。此外，其实相对简单的场景根本用不到这些额外的工具。" - msgid "Orchestration module" msgstr "编排模块" -msgid "" -"Orchestration module (heat): Similarly, Orchestration can be a valuable tool " -"in orchestrating tasks a CMP decides are necessary in an OpenStack-based " -"cloud." -msgstr "" -"Orchestration 模块 (heat): 同样的，Orchestration在编排任务中是一个非常有价值" -"的工具，在基于OpenStack云的云管理平台所需要。 " - msgid "" "Organizations need to determine if it is logical to create their own clouds " "internally. Using a private cloud, organizations are able to maintain " @@ -4336,20 +3823,6 @@ msgstr "" "组织需要决定在内部建立自己的云的逻辑。私有云的使用，组织需要维护整个架构中的" "控制点以及组件。" -msgid "" -"Other factors strongly influence server hardware selection for a storage-" -"focused OpenStack design architecture. The following is a list of these " -"factors:" -msgstr "" -"一些服务器硬件的因素更加适合其他类型的，但是CPU和内存的能力拥有最高的优先级。" - -msgid "" -"Outages can cause loss of partial or full functionality of a site. " -"Strategies should be implemented to understand and plan for recovery " -"scenarios." -msgstr "" -"中断会引起站点的部分或全部功能的尚失。理解并实现恢复策略，且要规划恢复方案。" - msgid "" "Outside of the traditional data center the limitations of layer-2 network " "architectures become more obvious." @@ -4494,12 +3967,6 @@ msgstr "" "xlink:href=\"http://www.openstack.org/marketplace/training/\">http://www." "openstack.org/marketplace/training/." -msgid "" -"ProjectsToAggregateFilter - To provide special handling depending on the " -"project the instance is associated with." -msgstr "" -"ProjectsToAggregateFilter - 为了提供特殊处理，取决于该实例相关联的项目。" - msgid "Protocol support" msgstr "协议支持" @@ -4545,18 +4012,6 @@ msgstr "" msgid "Quota management" msgstr "配额管理" -msgid "" -"Quotas are defined on a per-region basis. Operators may wish to define " -"identical quotas for tenants in each region of the cloud to provide a " -"consistent experience, or even create a process for synchronizing allocated " -"quotas across regions. It is important to note that only the operational " -"limits imposed by the quotas will be aligned consumption of quotas by users " -"will not be reflected between regions." -msgstr "" -"配置被定义为每个region的基本要素之一。运维人员也许希望定义相同的配额，在每个" -"region下的租户，以提供给用户一致的体验，或者创建一个跨region同步分配配额的流" -"程。但是请记住下面一点很重要，配额不会跨region进行限制。" - msgid "RAM allocation ratio: 1.5:1" msgstr "RAM 超分配比例: 1.5:1" @@ -4920,28 +4375,9 @@ msgstr "" msgid "Selecting networking hardware" msgstr "选择网络硬件" -msgid "" -"Selecting software for a storage-focused OpenStack architecture design " -"includes three areas:" -msgstr "对于存储型OpenStack架构设计来说，选择包含的软件有以下三个方面的考虑：" - msgid "Selecting storage hardware" msgstr "选择存储硬件" -msgid "" -"Selecting the OS and hypervisor has a significant impact on the overall " -"design and also affects server hardware selection. Ensure that the selected " -"operating system and hypervisor combination support the storage hardware and " -"work with the networking hardware selection and topology. For example, Link " -"Aggregation Control Protocol (LACP) requires support from both the OS and " -"hypervisor." -msgstr "" -"操作系统和hypervisor对于整个设计有着深刻的影响。选择一个特定的操作系统和" -"hypervisor能够直接影响到服务器硬件的选择。确保存储硬件和拓扑支持选择好的操作" -"系统和Hypervisor组合。也得确保网络硬件的选择和拓扑可在选定的操作系统和" -"Hypervisor组合下正常工作。例如，如果设计中使用了链路聚合控制协议(LACP)的话，" -"操作系统和hypervisor都需要支持它才可正常工作。" - msgid "" "Selecting the proper zone design is crucial for allowing the Object Storage " "cluster to scale while providing an available and redundant storage system. " @@ -4966,19 +4402,6 @@ msgstr "" msgid "Selection of OpenStack software components" msgstr "选择OpenStack软件组件" -msgid "" -"Selection of a commercially supported hypervisor, such as Microsoft Hyper-V, " -"results in a different cost model than a community-supported open source " -"hypervisor like Kinstance or Xen. Similarly, choosing Ubuntu over Red Hat " -"(or vice versa) impacts cost due to support contracts. However, business or " -"application requirements might dictate a specific or commercially supported " -"hypervisor." -msgstr "" -"选择商业支持的hypervisor如微软的Hyper-V，和选择社区支持的开源hypervisor如" -"kinstance或Xen，在开销模式上是完全不同的。甚至在开源解决方案也表现不同，如选" -"择Ubuntu而不是RedHat(或类似)在支持上有着不同的开销。换句话说，业务和应用的需" -"求主宰着选用特殊的或商业支持的hypervisor。" - msgid "Selection of supplemental software" msgstr "选择支撑软件" @@ -5015,23 +4438,6 @@ msgstr "" "同样的，默认的内存超分配比例是1.5:1，这意味着调度器为实例分配的内存总量要少于" "物理节点内存的1.5倍。" -msgid "" -"Similarly, the degree to which the architecture is OpenStack-based will have " -"an effect on the cloud operator or cloud consumer's ability to accomplish " -"tasks with native OpenStack tools. By definition, this is a situation in " -"which no single cloud can provide all of the necessary functionality. In " -"order to manage the entire system, users, operators and consumers will need " -"an overarching tool known as a cloud management platform (CMP). Any " -"organization that is working with multiple clouds already has a CMP, even if " -"that CMP is the operator who logs into an external web portal and launches a " -"public cloud instance." -msgstr "" -"同样的，基于OpenStack的混合云架构在多大程度上影响着云的运维者和云的消费者，让" -"他们可以使用OpenStack本身的工具去完成一些任务。根据定义，此中状况没有那个单一" -"的云可以提供所有的功能。为了管理整个系统，用户、运维人员、最终用户会需要一个" -"总体工具，即众所周知的云管理平台(CMP)。任何组织只要使用了混合云，都会有一个" -"CMP，有些CMP还需要运维人员登录外部的门户以及创建一个公有云的实例。" - msgid "" "Similarly, the network architecture will have an impact on the server " "hardware selection and vice versa. For example, make sure that the server is " @@ -5047,20 +4453,6 @@ msgstr "" msgid "Simple, single agent" msgstr "简单，单独一个代理程序" -msgid "" -"Since multi-site systems can be geographically separated, they may have " -"worse than normal latency or jitter when communicating across regions. This " -"can especially impact systems like the OpenStack Identity service when " -"making authentication attempts from regions that do not contain the " -"centralized Identity implementation. It can also affect certain applications " -"which rely on remote procedure call (RPC) for normal operation. An example " -"of this can be seen in High Performance Computing workloads." -msgstr "" -"尽管多区域系统可以基于地理位置分离，它们会在跨region通信时遭遇糟糕的延迟和抖" -"动。这种情况尤其影响系统的如OpenStack身份服务从region做认证尝试时没有实现中心" -"化的身份服务。它也会影响到一些应用如远程过程调用(RPC)的正常操作，在高性能计算" -"负载型中此类问题很常见。" - msgid "Single Point Of Failure (SPOF)" msgstr "单点故障(SPOF)" @@ -5119,32 +4511,6 @@ msgid "" "Solutions that employ Galera/MariaDB require at least three MySQL nodes." msgstr "解决方案采用Galera/MariaDB，需要至少3个MySQL节点。" -msgid "" -"Some applications are tolerant of the lack of synchronized object storage, " -"while others may need those objects to be replicated and available across " -"regions. Understanding of how the cloud implementation impacts new and " -"existing applications is important for risk mitigation and the overall " -"success of a cloud project. Applications may have to be written to expect an " -"infrastructure with little to no redundancy. Existing applications not " -"developed with the cloud in mind may need to be rewritten." -msgstr "" -"一些应用可以容忍对象存储没有同步，但是也有另外的应用需要这些对象被复制且跨多" -"个region可用。理解云如何实现会影响到新的和已有的应用，对于降低风险和整个云项" -"目成功很重要。已经完成的应用期望基础设施并无冗余，已有的应用没有将运行在云中" -"考虑的话就需要重写了。" - -msgid "" -"Some applications need access to hardware devices to either improve " -"performance or provide capabilities that are not virtual CPU, RAM, network, " -"or storage. These can be a shared resource, such as a cryptography " -"processor, or a dedicated resource, such as a Graphics Processing Unit. " -"OpenStack can provide some of these, while others may need extra work." -msgstr "" -"一些应用需要使用硬件设备以提高性能或者提供非虚拟 CPU、内存、网络或者存储等的" -"功能。这些可以是共享的资源，例如加密处理器，或者专用的资源，例如图形处理器。" -"对于其中一些设备，OpenStack 有办法能够直接使用它们，而对于另外一些设备，则可" -"能需要完成额外的工作。" - msgid "" "Some applications that interact with a network require specialized " "connectivity. Applications such as a looking glass require the ability to " @@ -5189,9 +4555,6 @@ msgid "" msgstr "" "一些服务器硬件的因素更加适合其他类型的，但是CPU和内存的能力拥有最高的优先级。" -msgid "Some situations that could involve hybrid cloud architecture include:" -msgstr "一些包含混合云架构的场景如下:" - msgid "" "Some use cases that might indicate a need for a multi-site deployment of " "OpenStack include:" @@ -5297,28 +4660,6 @@ msgstr "存储管理" msgid "Storage performance" msgstr "存储性能" -msgid "" -"Storage-focused OpenStack clouds must reflect that the workloads are storage " -"intensive. These workloads are not compute intensive, nor are they " -"consistently network intensive. The network may be heavily utilized to " -"transfer storage, but they are not otherwise network intensive." -msgstr "" -"存储型OpenStack云须能反映出是针对存储密集型的负载因素。这些负载既不是计算密集" -"型也不是网络密集型，网络也许在传输数据时有很高的负载，但是这是另外一个网络密" -"集的范畴。" - -msgid "" -"Storage-focused OpenStack design architecture server hardware selection " -"should focus on a \"scale up\" versus \"scale out\" solution. The " -"determination of which is the best solution, a smaller number of larger " -"hosts or a larger number of smaller hosts, depends on a combination of " -"factors including cost, power, cooling, physical rack and floor space, " -"support-warranty, and manageability." -msgstr "" -"存储型OpenStack架构设计的服务器硬件选择只有两种结果可决定：纵向扩展抑或横向扩" -"展。在少而大的服务器主机和多而小的服务器主机选择更好的解决方案，取决于多种因" -"素：预算、电力、制冷、物理机架和地板的空间、售后服务力度、以及可管理性。" - msgid "Storage-focused workloads" msgstr "存储型负载" @@ -5370,12 +4711,6 @@ msgstr "计量模块" msgid "Telemetry module (ceilometer)" msgstr "Telemetry 模块 (ceilometer)" -msgid "" -"Telemetry module (ceilometer): Use of Telemetry depends, in large part, on " -"what the other parts of the cloud are using." -msgstr "" -"Telemetry 模块 (ceilometer):在大部分依赖使用Telemetry，可用于云的其他组件。" - msgid "Telemetry uses MongoDB." msgstr "Telemetry 使用MongoDB。" @@ -5407,23 +4742,6 @@ msgstr "" "在OpenStack的设计中，为满足用户需求，需要操作系统的hypervisor在彼此的特性和服" "务中要有互操作性。" -msgid "" -"The OpenStack Identity service, which is used by all other OpenStack " -"components for authorization and the catalog of service endpoints, supports " -"the concept of regions. A region is a logical construct that can be used to " -"group OpenStack services that are in close proximity to one another. The " -"concept of regions is flexible; it may can contain OpenStack service " -"endpoints located within a distinct geographic region, or regions. It may be " -"smaller in scope, where a region is a single rack within a data center or " -"even a single blade chassis, with multiple regions existing in adjacent " -"racks in the same data center." -msgstr "" -"OpenStack认证服务，用于所有其他OpenStack组件的验证，服务端点的目录，支持所有" -"region。一个region是用于一组OpenStack彼此接近的服务的逻辑构造。region的概念颇" -"为灵活，它可以包含地理位置很远的OpenStack服务端点，也可以是很小的范围，region" -"甚至可以是一个数据中心的机柜，或是一个刀片中心，甚至在同一个数据相邻的机柜都" -"拥有多个region。" - msgid "" "The OpenStack dashboard, OpenStack Identity, and OpenStack Object Storage " "services are components that can each be deployed centrally in order to " @@ -5432,15 +4750,6 @@ msgstr "" "OpenStack GUI，OpenStack认证，以及OpenStack对象存储等服务为了服务于多区域，这" "些组件需要部署在中心化位置。" -msgid "" -"The OpenStack management components need to have a basic and minimal level " -"of redundancy. The simplest example is the loss of any single site has no " -"significant impact on the availability of the OpenStack services of the " -"entire infrastructure." -msgstr "" -"OpenStack管理组件需要哪怕是最基本的或最小级别的冗余，举个最简单的例子，这样当" -"任何一个站点失效时而不会受到显著的影响，因为有OpenStack服务依然可用。" - msgid "" "The OpenStack services themselves should be deployed across multiple servers " "that do not represent a single point of failure. Ensuring API availability " @@ -5479,14 +4788,6 @@ msgstr "" msgid "The author team includes:" msgstr "作者团队成员有：" -msgid "" -"The authors of the Architecture Design Guide would like to thank CERN for " -"publicly documenting their OpenStack deployment in these resources, which " -"formed the basis for this chapter:" -msgstr "" -"架构设计指南的作者们非常感谢CERN,他们公开了他们在他们的环境中部署OpenStack的" -"文档，是这一节的内容的组织的基础。" - msgid "" "The availability design requirements determine the selection of Clustering " "Software, such as Corosync or Pacemaker. The availability of the cloud " @@ -5585,16 +4886,6 @@ msgstr "" "公司的网站运行着基于硬件的负载均衡服务器和多个web应用服务，且他们的编排环境是" "混合使用Puppet和脚本。网站每天都会产生大量的日志文件需要归档。" -msgid "" -"The connection broker is a central component of the architecture that " -"determines which remote desktop host the user connects to. The broker is " -"often a full-blown management product enabling the automated deployment and " -"provisioning of remote desktop hosts." -msgstr "" -"连接代理是架构中的核心组件，其决定了哪个虚拟桌面会被分配至或者连接至用户。这" -"种代理程序一般都是比较成熟全面的管理产品，能够支持远程桌面的自动部署及准备工" -"作。" - msgid "" "The cost of components affects which storage architecture and hardware you " "choose." @@ -5623,14 +4914,6 @@ msgstr "" "来说，如果物理节点有12个核，调度器就拥有192个虚拟核。在典型的flavor定义中，每" "实例4个虚拟核，那么此超分配比例可以在此物理节点上提供48个实例。" -msgid "" -"The deployed applications need to continue to function and, more " -"importantly, consideration should be taken of the impact on the performance " -"and reliability of the application when a site is unavailable." -msgstr "" -"已经部署的应用需要持续的服务，且更加重要的，需要考虑由于站点的不可用带来的性" -"能冲击和应用的可靠性。" - msgid "" "The design architecture of a massively scalable OpenStack cloud must address " "considerations around physical facilities such as space, floor weight, rack " @@ -5658,22 +4941,6 @@ msgid "" "requirement." msgstr "本例描绘了没有高性能需求的 REST 接口。" -msgid "" -"The expected workload is a critical requirement that needs to be captured to " -"guide decision-making. An understanding of the workloads in the context of " -"the desired multi-site environment and use case is important. Another way of " -"thinking about a workload is to think of it as the way the systems are used. " -"A workload could be a single application or a suite of applications that " -"work together. It could also be a duplicate set of applications that need to " -"run in multiple cloud environments. Often in a multi-site deployment the " -"same workload will need to work identically in more than one physical " -"location." -msgstr "" -"预期的工作负荷是需要被捕获到指导决策的关键要求。理解负载在预想的多区域环境和" -"用例上下文很重要。另外一个考虑负载的路径是想它怎么使用系统。一个负载可以是单" -"个的应用或一组共同工作的应用。它也可以是在多个region中运行的多份应用的复制。" -"通常在多区域部署的相同负载需要在多个不同物理地点运行相同的工作。" - msgid "" "The factors for determining which software packages in this category to " "select is outside the scope of this design guide." @@ -5813,20 +5080,6 @@ msgstr "" "OpenStack支持它们所有的操作系统和hypervisor组合。这也会对其他的设计有着非常不" "同的影响，结果就是选择了一种组合再作出选择。" -msgid "" -"The network aspect of deploying a nested cloud is the most complicated " -"aspect of this architecture. You must expose VLANs to the physical ports on " -"which the underlying cloud runs, as the bare metal cloud owns all the " -"hardware, but you must also expose them to the nested levels as well. " -"Alternatively, you can use the network overlay technologies on the OpenStack " -"cloud running on OpenStack to provide the required software defined " -"networking for the deployment." -msgstr "" -"网络方面是这个嵌套云架构的最复杂部分。由于底层裸金属架构的云拥有所有的硬件设" -"备，当使用 VLAN 的时候，VLAN 需要被暴露到底层云上的物理端口，但是它们也同样需" -"要被展现到嵌套层中。作为备选方案，网络覆盖技术能够在上层云，运行在 OpenStack " -"之上的 OpenStack， 被用以为部署提供所需要的软件定义联网。" - msgid "" "The network design should encompass a physical and logical network design " "that can be easily expanded upon. Network hardware should offer the " @@ -5986,27 +5239,11 @@ msgstr "" "读者需要有云计算架构和原理的知识背景，企业级系统设计经验，linux和虚拟化经验，" "以及可理解基本的网络原理和协议。" -msgid "" -"The relative of the hardware weighted against the level of design effort " -"needed to build the system." -msgstr "相对硬件的权重是体现构建系统的设计水准所需要的。" - msgid "" "The relative purchase price of the hardware weighted against the level of " "design effort needed to build the system." msgstr "相对硬件的购买价格，与构建系统所需要的设计功力的级别成反比。" -msgid "" -"The requirement of having more than one site has a cost attached to it. The " -"greater the number of sites, the greater the cost and complexity. Costs can " -"be broken down into the following categories:" -msgstr "" -"多个站点的需求带来更多的额外开销。更多的站点，意味着更多的开销和复杂性。开销" -"可以细分为以下几类：" - -msgid "The security domains are:" -msgstr "安全域有：" - msgid "" "The selected OS-hypervisor combination needs to be supported by OpenStack." msgstr "选择操作系统-虚拟机管理程序组合需要OpenStack支持。" @@ -6048,21 +5285,6 @@ msgstr "" "存储架构，那么服务器硬件的选择就得小心谨慎的考虑需求，以匹配商业解决方案的需" "求。" -msgid "" -"The selection of storage architecture determines if a scale-out solution " -"should be used or if a single, highly expandable and scalable centralized " -"storage array would be a better choice. If a centralized storage array is " -"the right fit for the requirements then the array vendor determines the " -"hardware selection. It is possible to build a storage array using commodity " -"hardware with Open Source software, but requires people with expertise to " -"build such a system." -msgstr "" -"存储架构的选择，以及存储硬件的选择，上面列出的几个因素是相互有冲突的，需评估" -"决定。如果是横向扩展解决方案的选择诸如Ceph，GlusterFS，或类似的,如果是单一" -"的，高扩展性的，那么选择中心化的存储阵列就没错。如果中心存储阵列能够满\n" -"足需求，那么硬件的决定就是如何选择阵列供应商的事情了。使用商业硬件和开源软件" -"来构建存储阵列也是完全可能的，只是需要构建这样的系统需要专业的人员罢了。" - msgid "" "The software selection process plays a large role in the architecture of a " "general purpose cloud. The following have a large impact on the design of " @@ -6074,14 +5296,6 @@ msgstr "" msgid "The solution would consist of the following OpenStack components:" msgstr "解决方案将由下列OpenStack组件组成：" -msgid "" -"The specific definition of what constitutes a site in the relevant licenses, " -"as the term does not necessarily denote a geographic or otherwise physically " -"isolated location in the traditional sense." -msgstr "" -"在相关的许可证下一个站点由什么构成有着特别的定义，正如该术语不一定表示在传统" -"意义上的一个地理或其他物理隔离的位置。" - msgid "" "The starting point is the core count of the cloud. By applying relevant " "ratios, the user can gather information about:" @@ -6105,16 +5319,6 @@ msgstr "" "web应用实例均运行在每个OpenStack计算节点的本地存储之上。所有的web应用实例都是" "无状态的，也就是意味着任何的实例宕掉，都不会影响到整体功能的继续服务。" -msgid "" -"There are a number of commercial products currently available that provide " -"such a broker solution but nothing that is native to the OpenStack project. " -"Not providing a broker is also an option, but managing this manually would " -"not suffice for a large scale, enterprise solution." -msgstr "" -"目前有多种商业产品能够提供这种代理的解决方案，但 OpenStack 项目中没有原生的支" -"持。不提供这样一个代理也是一个选择，但是手动管理这些功能并不能够满足作为一个" -"大规模的企业级解决方案的要求。" - msgid "" "There are a variety of well tested tools, for example ICMP, to monitor and " "manage traffic." @@ -6164,9 +5368,6 @@ msgstr "" "请注意关于 erasure coded 池的使用有特殊的考虑因素，比如说，更高的计算要求以及" "对象上所允许的操作限制。另外，部分写入在 erasure coded 的池中也不被支持。" -msgid "There are three areas to consider when selecting storage hardware:" -msgstr "当选择存储硬件时有三大块需要考虑：" - msgid "" "There is also some customization of the filter scheduler that handles " "placement within the cells:" @@ -6221,20 +5422,6 @@ msgstr "" "此应用将南北向的流量的优先级设置得比东西向的流量的优先级更高：南北向的流量与" "面向客户的数据相关。" -msgid "" -"This architecture usually includes a geo-location component that places user " -"requests at the closest possible node. In this scenario, 100% redundancy of " -"content across every site is a goal rather than a requirement, with the " -"intent being to maximize the amount of content available that is within a " -"minimum number of network hops for any given end user. Despite these " -"differences, the storage replication configuration has significant overlap " -"with that of a geo-redundant load balancing use case." -msgstr "" -"此架构通常包括一个放置在最接近节点的用户需求的地理位置组件。在此场景下，目标" -"是跨所有站点的100%冗余，已经不是一个需求，意图是为任何指定的最终用户有最大化" -"内容可用，最小的网络hop跳数。尽管他们不一样，存储冗余配置和地理位置冗余负载均" -"衡用例有明显的重叠。" - msgid "" "This book was written in a book sprint format, which is a facilitated, rapid " "development production method for books. For more information, see the Book " @@ -6265,13 +5452,6 @@ msgstr "" msgid "This example uses the following components:" msgstr "此例使用了如下组件：" -msgid "" -"This figure depicts the solution designed to have both a centralized set of " -"core data centers for OpenStack services and paired edge data centers:" -msgstr "" -"此示意图描述所设计的解决方案，同时拥有一个为OpenStack服务的中心化的核心数据中" -"心和两个边缘化的数据中心：" - msgid "" "This list expands upon the potential impacts for including a particular " "storage architecture (and corresponding storage hardware) into the design " @@ -6300,14 +5480,6 @@ msgstr "" "此多区域场景在本书中有一个或多个其他类似的场景，另外在两个或多个地点的额外负" "载需求。下面是可能一样的场景：" -msgid "" -"This must be done using normal system administration tools such as rsync as " -"no functionality for synchronizing policies across regions is currently " -"provided within OpenStack." -msgstr "" -"这个可以用普通的系统管理工具如rsync来完成，OpenStack目前没有提供跨区域的同步" -"规则。" - msgid "" "This system can provide additional performance. For example, in the database " "example below, a portion of the SSD pool can act as a block device to the " @@ -6392,32 +5564,6 @@ msgstr "" "要想使1U的服务器支持超过2个插槽，用户需要通过原始设计制造商(ODM)或二线制造商" "来购买。" -msgid "" -"To prevent system capacities from being exhausted without notification, " -"OpenStack provides operators with the ability to define quotas. Quotas are " -"used to set operational limits and are currently enforced at the tenant (or " -"project) level rather than at the user level." -msgstr "" -"为防止系统资源被耗尽而没有任何通知，OpenStack提供给运维人员定义配额的能力。配" -"额用户设置操作限制，当前可在租户(或项目)中实现了强制，而用户级别则没有实现。" - -msgid "" -"To provide cryptography offloading to a set of instances, you can use Image " -"service configuration options to assign the cryptography chip to a device " -"node in the guest. The OpenStack Command Line Reference contains further information on configuring this solution in the " -"chapter Image service property keys, but " -"it allows all guests using the configured images to access the hypervisor " -"cryptography device." -msgstr "" -"要为一组实例提供加密卸载，可以通过使用镜像服务的配置选项将加密芯片分配至客户" -"机中的一个设备节点。OpenStack 命令行参考中的镜像服务属性键一章包含了关于配置这个解决方案的" -"更多信息。但是这个方案允许所有的客户机都通过该已配置的镜像来使用宿主机的加密" -"设备。" - msgid "" "To reap the benefits of OpenStack, you should plan, design, and architect " "your cloud properly, taking user's needs into account and understanding the " @@ -6432,9 +5578,6 @@ msgstr "工具考量" msgid "Topics to consider include:" msgstr "考虑的主题有：" -msgid "Treats applications" -msgstr "Treats 应用" - msgid "Tunable networking components" msgstr "可调联网组件" @@ -6729,12 +5872,6 @@ msgstr "Web服务，运行 Apache。" msgid "Web portals or web services" msgstr "web 门户或 web 服务" -msgid "" -"When attempting to deploy logging and monitoring facilities to a centralized " -"location, care must be taken with regards to the load placed on the inter-" -"site networking links." -msgstr "当尝试将日志和监测系统部署到一个中心位置时，要小心内部网络的负载。" - msgid "" "When building a general purpose cloud, you should follow the Infrastructure-as-a-Service (IaaS) model; a " @@ -7004,21 +6141,6 @@ msgstr "" msgid "Why and how we wrote this book" msgstr "我们为什么及如何写作此书" -msgid "" -"With multiple OpenStack regions, having a single OpenStack Object Storage " -"service endpoint that delivers shared file storage for all regions is " -"desirable. The Object Storage service internally replicates files to " -"multiple nodes. The advantages of this are that, if a file placed into the " -"Object Storage service is visible to all regions, it can be used by " -"applications or workloads in any or all of the regions. This simplifies high " -"availability failover and disaster recovery rollback." -msgstr "" -"在多个OpenStack region，实现单一的OpenStack对象存储服务端点的话，就需要实现所" -"有的region共享文件存储。对象存储服务内部复制文件到多个节点。这样有一个优点，" -"那就是如果一个文件存放在对象存储服务对于所有region都可见，那么它就可以在任何" -"的或全部的region里的应用和负载所使用。这是简单的高可用失效恢复和灾难恢复回" -"滚。" - msgid "Workload characteristics" msgstr "负载特性" @@ -7083,23 +6205,12 @@ msgstr "Zone是多个节点的集合" msgid "current" msgstr "当前最新" -msgid "" -"default_schedule_zones - Allows the selection of multiple default " -"availability zones, rather than a single default." -msgstr "default_schedule_zones -允许选择多个默认可用区域，而不是单一的。" - msgid "east-west traffic" msgstr "东西向流量" -msgid "http://openstack-in-production.blogspot.fr" -msgstr "http://openstack-in-production.blogspot.fr" - msgid "north-south traffic" msgstr "南北向流量" -msgid "storage required = 50GB 1600" -msgstr "存储需要 = 50GB x 1600" - #. Put one translator per line, in the form of NAME , YEAR1, YEAR2 msgid "translator-credits" msgstr "" diff --git a/doc/common-rst/source/locale/common-rst.pot b/doc/common-rst/source/locale/common-rst.pot index f2a08a6861..d9af8a4564 100644 --- a/doc/common-rst/source/locale/common-rst.pot +++ b/doc/common-rst/source/locale/common-rst.pot @@ -5021,6 +5021,10 @@ msgstr "" msgid "Manages accounts defined with Object Storage." msgstr "" +#: ../common/get_started_object_storage.rst:25 +msgid "Manages actual objects, such as files, on the storage nodes." +msgstr "" + #: ../common/get_started_object_storage.rst:26 #: ../common/get_started_object_storage.rst:25 msgid "Manages actual objects,such as files, on the storage nodes." diff --git a/doc/common/locale/common.pot b/doc/common/locale/common.pot index 226a53419f..9c64e445af 100644 --- a/doc/common/locale/common.pot +++ b/doc/common/locale/common.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2015-08-15 06:16+0000\n" +"POT-Creation-Date: 2015-08-19 06:16+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -2932,7 +2932,7 @@ msgid "Object servers (swift-object-server\n" "Language-Team: Japanese (http://www.transifex.com/openstack/openstack-" "manuals-i18n/language/ja/)\n" @@ -917,9 +917,18 @@ msgstr "" "な手法ではありません。環境変数は通常、「システムのプロパティ」ダイアログの" "詳細設定タブで定義されます。" +msgid "Delete a group" +msgstr "グループの削除" + msgid "Description" msgstr "説明" +msgid "Description of IPv6 configuration options" +msgstr "IPv6 設定オプションの説明" + +msgid "Description of metadata configuration options" +msgstr "メタデータ設定オプションの説明" + msgid "Detect drive failures preempting data corruption" msgstr "データ破損を引き起こすドライブ故障の検知" @@ -944,6 +953,9 @@ msgstr "クライアントのバージョン番号の確認" msgid "Disk" msgstr "ディスク" +msgid "Disk tuning" +msgstr "ディスクチューニング" + msgid "Document change history" msgstr "ドキュメント変更履歴" @@ -990,11 +1002,23 @@ msgstr "容量を簡単に追加可能 (RAID リサイズとの違い)" msgid "Elastic data scaling with ease" msgstr "容易に伸縮自在なデータスケーラビリティ" +msgid "Element" +msgstr "要素" + +msgid "Emergency recovery of ring builder files" +msgstr "リングビルダーファイルの緊急復旧" + msgid "Enable direct browser access to content, such as for a control panel" msgstr "" "コントロールパネル用など、コンテンツにブラウザーから直接アクセスすることを有" "効化します。" +msgid "Enable domain-specific drivers:" +msgstr "ドメイン固有のドライバーを有効化します。" + +msgid "Enable the LDAP driver:" +msgstr "LDAP ドライバーを有効化します。" + msgid "" "Enable this hybrid setting by configuring both your database and cache, as " "discussed previously. Then, set the following value:" diff --git a/doc/common/locale/zh_CN.po b/doc/common/locale/zh_CN.po index f1649fc529..cc537b600d 100644 --- a/doc/common/locale/zh_CN.po +++ b/doc/common/locale/zh_CN.po @@ -11,8 +11,8 @@ msgid "" msgstr "" "Project-Id-Version: OpenStack Manuals\n" -"POT-Creation-Date: 2015-08-14 19:13+0000\n" -"PO-Revision-Date: 2015-08-14 13:18+0000\n" +"POT-Creation-Date: 2015-08-19 01:36+0000\n" +"PO-Revision-Date: 2015-08-18 17:33+0000\n" "Last-Translator: openstackjenkins \n" "Language-Team: Chinese (China) (http://www.transifex.com/openstack/openstack-" "manuals-i18n/language/zh_CN/)\n" @@ -1503,9 +1503,6 @@ msgstr "" msgid "Manages accounts defined with Object Storage." msgstr "管理由对象存储定义的账户。" -msgid "Manages actual objects,such as files, on the storage nodes." -msgstr "在存储节点管理实际的对象，诸如文件。" - msgid "" "Manages the lifecycle of compute instances in an OpenStack environment. " "Responsibilities include spawning, scheduling and decommissioning of virtual " diff --git a/doc/install-guide-rst/source/locale/install-guide-rst.pot b/doc/install-guide-rst/source/locale/install-guide-rst.pot index e69de29bb2..6f7a188c24 100644 --- a/doc/install-guide-rst/source/locale/install-guide-rst.pot +++ b/doc/install-guide-rst/source/locale/install-guide-rst.pot @@ -0,0 +1,5624 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) 2015, OpenStack contributors +# This file is distributed under the same license as the Installation Guide package. +# FIRST AUTHOR , YEAR. +# +#, fuzzy +msgid "" +msgstr "" +"Project-Id-Version: Installation Guide 0.1\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2015-08-19 06:16+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-nova.rst:110 ../cinder-controller-node.rst:282 +#: ../cinder-storage-node.rst:340 ../glance-install.rst:236 +#: ../glance-install.rst:304 ../heat-install.rst:324 +#: ../neutron-network-node.rst:259 ../neutron-network-node.rst:284 +#: ../neutron-network-node.rst:389 ../nova-compute-install.rst:194 +#: ../nova-controller-install.rst:280 +msgid "" +"(Optional) To assist with troubleshooting, enable verbose logging in the " +"``[DEFAULT]`` section:" +msgstr "" + +#: ../neutron-network-node.rst:293 +msgid "" +"(Optional) Tunneling protocols such as GRE include additional packet headers " +"that increase overhead and decrease space available for the payload or user " +"data. Without knowledge of the virtual network infrastructure, instances " +"attempt to send packets using the default Ethernet :term:`maximum " +"transmission unit (MTU)` of 1500 bytes. :term:`Internet protocol (IP)` " +"networks contain the :term:`path MTU discovery (PMTUD)` mechanism to detect " +"end-to-end MTU and adjust packet size accordingly. However, some operating " +"systems and networks block or otherwise lack support for PMTUD causing " +"performance degradation or connectivity failure." +msgstr "" + +#: ../swift-finalize-installation.rst:5 +msgid "**Configure hashes and default storage policy**" +msgstr "" + +#: ../overview.rst:81 +msgid "**Higher-level services**" +msgstr "" + +#: ../basics-networking-neutron.rst:59 +msgid "" +"**Minimal architecture example with OpenStack Networking (neutron)—Network " +"layout**" +msgstr "" + +#: ../basics-networking-nova.rst:47 +msgid "" +"**Minimal architecture example with legacy networking (nova-network)—Network " +"layout**" +msgstr "" + +#: ../overview.rst:0 +msgid "**OpenStack services**" +msgstr "" + +#: ../basic_environment.rst:0 +msgid "**Passwords**" +msgstr "" + +#: ../app_reserved_uids.rst:0 +msgid "**Reserved user IDs**" +msgstr "" + +#: ../overview.rst:64 +msgid "**Shared services**" +msgstr "" + +#: ../overview.rst:47 +msgid "**Storage**" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:246 ../neutron-controller-node.rst:334 +msgid "**To configure Compute to use Networking**" +msgstr "" + +#: ../networking-nova.rst:10 ../networking-nova.rst:72 +msgid "**To configure legacy networking**" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:96 ../basics-networking-neutron.rst:193 +#: ../basics-networking-neutron.rst:252 ../basics-networking-nova.rst:84 +#: ../basics-networking-nova.rst:176 +msgid "**To configure name resolution:**" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:82 ../basics-networking-neutron.rst:127 +#: ../basics-networking-neutron.rst:224 ../basics-networking-nova.rst:70 +#: ../basics-networking-nova.rst:112 +msgid "**To configure networking:**" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:8 ../neutron-controller-node.rst:5 +msgid "**To configure prequisites**" +msgstr "" + +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-services.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../keystone-install.rst:12 ../keystone-services.rst:10 +#: ../neutron-network-node.rst:8 +msgid "**To configure prerequisites**" +msgstr "" + +#: ../neutron-network-node.rst:268 +msgid "**To configure the DHCP agent**" +msgstr "" + +#: ../neutron-network-node.rst:238 +msgid "**To configure the Layer-3 (L3) agent**" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:165 ../neutron-controller-node.rst:289 +#: ../neutron-network-node.rst:168 +msgid "**To configure the Modular Layer 2 (ML2) plug-in**" +msgstr "" + +#: ../basics-ntp.rst:39 ../basics-ntp.rst:116 +msgid "**To configure the NTP service**" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:224 ../neutron-network-node.rst:426 +msgid "**To configure the Open vSwitch (OVS) service**" +msgstr "" + +#: ../basics-packages.rst:434 +msgid "**To configure the message queue service**" +msgstr "" + +#: ../neutron-network-node.rst:344 +msgid "**To configure the metadata agent**" +msgstr "" + +#: ../neutron-initial-networks.rst:208 +msgid "" +"**To create a router on the tenant network and attach the external and " +"tenant networks to it**" +msgstr "" + +#: ../neutron-initial-networks.rst:70 +msgid "**To create a subnet on the external network**" +msgstr "" + +#: ../neutron-initial-networks.rst:163 +msgid "**To create a subnet on the tenant network**" +msgstr "" + +#: ../neutron-initial-networks.rst:31 +msgid "**To create the external network**" +msgstr "" + +#: ../networking-nova.rst:134 +msgid "**To create the network**" +msgstr "" + +#: ../keystone-services.rst:61 +msgid "**To create the service entity and API endpoint**" +msgstr "" + +#: ../neutron-initial-networks.rst:130 +msgid "**To create the tenant network**" +msgstr "" + +# #-#-#-#-# basics-packages.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-packages.rst:353 ../neutron-controller-node.rst:376 +msgid "**To finalize installation**" +msgstr "" + +# #-#-#-#-# basics-packages.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-packages.rst:187 ../keystone-install.rst:526 +#: ../neutron-compute-node.rst:288 ../neutron-network-node.rst:480 +msgid "**To finalize the installation**" +msgstr "" + +#: ../basics-packages.rst:258 +msgid "**To install and configure the database server**" +msgstr "" + +#: ../networking-nova.rst:46 +msgid "**To install legacy networking components**" +msgstr "" + +#: ../basics-ntp.rst:17 ../basics-ntp.rst:94 +msgid "**To install the NTP service**" +msgstr "" + +#: ../neutron-controller-node.rst:115 +msgid "**To install the Networking components**" +msgstr "" + +#: ../basics-packages.rst:411 +msgid "**To install the message queue service**" +msgstr "" + +#: ../neutron-initial-networks.rst:261 +msgid "**To verify network connectivity**" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:367 ../neutron-controller-node.rst:469 +#: ../neutron-network-node.rst:558 +msgid "**Verify operation**" +msgstr "" + +#: ../index.rst:122 +msgid ":ref:`search`" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:41 ../launch-instance-nova.rst:52 +msgid "" +"A flavor specifies a virtual resource allocation profile which includes " +"processor, memory, and storage." +msgstr "" + +#: ../basic_environment.rst:67 +msgid "" +"A single disk partition on each node works for most basic installations. " +"However, you should consider :term:`Logical Volume Manager (LVM)` for " +"installations with optional services such as Block Storage." +msgstr "" + +#: ../neutron-initial-networks.rst:203 +msgid "" +"A virtual router passes network traffic between two or more virtual " +"networks. Each router requires one or more :term:`interfaces ` " +"and/or gateways that provide access to specific networks. In this case, you " +"create a router and attach your tenant and external networks to it." +msgstr "" + +#: ../basic_environment.rst:79 +msgid "" +"Ability to take periodic \"snap shots\" throughout the installation process " +"and \"roll back\" to a working configuration in the event of a problem." +msgstr "" + +#: ../index.rst:31 +msgid "Abstract" +msgstr "" + +#: ../networking-neutron.rst:22 +msgid "" +"Accepts and routes API requests to the appropriate OpenStack Networking plug-" +"in for action." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:378 ../launch-instance-nova.rst:342 +msgid "" +"Access your instance using SSH from the controller node or any host on the " +"external network and use the :command:`fdisk` command to verify presence of " +"the volume as the ``/dev/vdb`` block storage device:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:305 ../launch-instance-nova.rst:269 +msgid "" +"Access your instance using SSH from the controller node or any host on the " +"external network:" +msgstr "" + +#: ../swift-initial-rings.rst:16 +msgid "Account ring" +msgstr "" + +#: ../swift.rst:5 +msgid "Add Object Storage" +msgstr "" + +#: ../nova-controller-install.rst:164 +msgid "Add a ``[database]`` section, and configure database access:" +msgstr "" + +#: ../networking.rst:3 +msgid "Add a networking component" +msgstr "" + +#: ../neutron-network-node.rst:459 +msgid "" +"Add a port to the external bridge that connects to the physical external " +"network interface. Replace ``INTERFACE_NAME`` with the actual interface " +"name. For example, *eth2* or *ens256*:" +msgstr "" + +#: ../swift-initial-rings.rst:34 ../swift-initial-rings.rst:115 +#: ../swift-initial-rings.rst:194 +msgid "Add each storage node to the ring:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:225 ../launch-instance-nova.rst:229 +msgid "Add rules to the ``default`` security group:" +msgstr "" + +#: ../cinder.rst:3 +msgid "Add the Block Storage service" +msgstr "" + +#: ../nova.rst:3 +msgid "Add the Compute service" +msgstr "" + +#: ../keystone.rst:3 +msgid "Add the Identity service" +msgstr "" + +#: ../glance.rst:3 +msgid "Add the Image service" +msgstr "" + +#: ../heat.rst:3 +msgid "Add the Orchestration module" +msgstr "" + +#: ../ceilometer.rst:3 +msgid "Add the Telemetry module" +msgstr "" + +#: ../ceilometer-swift.rst:34 +msgid "" +"Add the ``ResellerAdmin`` role to the ``service`` tenant and ``ceilometer`` " +"user:" +msgstr "" + +#: ../keystone-users.rst:75 +msgid "Add the ``admin`` role to the ``admin`` project and user:" +msgstr "" + +#: ../ceilometer-controller-install.rst:254 +msgid "Add the ``admin`` role to the ``ceilometer`` user." +msgstr "" + +#: ../cinder-controller-node.rst:70 +msgid "Add the ``admin`` role to the ``cinder`` user:" +msgstr "" + +#: ../glance-install.rst:77 +msgid "Add the ``admin`` role to the ``glance`` user and ``service`` project:" +msgstr "" + +#: ../heat-install.rst:64 +msgid "Add the ``admin`` role to the ``heat`` user:" +msgstr "" + +#: ../neutron-controller-node.rst:63 +msgid "Add the ``admin`` role to the ``neutron`` user:" +msgstr "" + +#: ../nova-controller-install.rst:67 +msgid "Add the ``admin`` role to the ``nova`` user:" +msgstr "" + +#: ../swift-controller-node.rst:54 +msgid "Add the ``admin`` role to the ``swift`` user:" +msgstr "" + +#: ../heat-install.rst:88 +msgid "Add the ``heat_stack_owner`` role to the ``demo`` tenant and user:" +msgstr "" + +#: ../basics-packages.rst:446 +msgid "Add the ``openstack`` user:" +msgstr "" + +#: ../ceilometer-swift.rst:92 +msgid "" +"Add the ``swift`` system user to the ``ceilometer`` system group to permit " +"access to the Telemetry configuration files by the Object Storage service:" +msgstr "" + +#: ../keystone-users.rst:164 +msgid "Add the ``user`` role to the ``demo`` project and user:" +msgstr "" + +#: ../horizon.rst:3 +msgid "Add the dashboard" +msgstr "" + +#: ../neutron-network-node.rst:453 +msgid "Add the external bridge:" +msgstr "" + +#: ../launch-instance-nova.rst:26 +msgid "Add the public key to your OpenStack environment:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:236 ../basics-networking-nova.rst:124 +msgid "Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on." +msgstr "" + +#: ../basics-networking-neutron.rst:246 +msgid "Additional compute nodes should use 10.0.1.32, 10.0.1.33, and so on." +msgstr "" + +#: ../neutron-concepts.rst:44 +msgid "" +"Additionally, you can allocate IP addresses on external networks to ports on " +"the internal network. Whenever something is connected to a subnet, that " +"connection is called a port. You can associate external network IP addresses " +"with ports to VMs. This way, entities on the outside network can access VMs." +msgstr "" + +#: ../neutron-controller-node.rst:311 +msgid "" +"After you configure the ML2 plug-in, changing values in the ``type_drivers`` " +"option can lead to database inconsistency." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:68 +msgid "After you create this file, run this command:" +msgstr "" + +#: ../dashboard-next-step.rst:9 +msgid "" +"After you install and configure the dashboard, you can complete the " +"following tasks:" +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:5 +msgid "" +"All Debian packages for API services, except the ``heat-api`` package, " +"register the service in the Identity service catalog. This feature is " +"helpful because API endpoints are difficult to remember." +msgstr "" + +#: ../basics-networking.rst:46 +msgid "" +"All nodes require Internet access for administrative purposes such as " +"package installation, security updates, :term:`DNS`, and :term:`Network Time " +"Protocol (NTP)`. In most cases, nodes should obtain Internet access through " +"the management network interface. To highlight the importance of network " +"separation, the example architectures use `private address space `__ for the management network and assume that " +"network infrastructure provides Internet access via :term:`Network Address " +"Translation (NAT)`. To illustrate the flexibility of :term:`IaaS`, the " +"example architectures use public IP address space for the external network " +"and assume that network infrastructure provides direct Internet access to " +"instances in your OpenStack environment. In environments with only one block " +"of public IP address space, both the management and external networks must " +"ultimately obtain Internet access using it. For simplicity, the diagrams in " +"this guide only show Internet access for OpenStack services." +msgstr "" + +#: ../dashboard-install.rst:85 +msgid "Allow all hosts to access the dashboard::" +msgstr "" + +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-storage-node.rst:42 ../swift-storage-node.rst:61 +msgid "" +"Also add this content to the :file:`/etc/hosts` file on all other nodes in " +"your environment." +msgstr "" + +#: ../basic_environment.rst:185 +msgid "" +"Also, the Networking service assumes default values for kernel network " +"parameters and modifies firewall rules. To avoid most issues during your " +"initial installation, we recommend using a stock deployment of a supported " +"distribution on your hosts. However, if you choose to automate deployment of " +"your hosts, review the configuration and policies applied to them before " +"proceeding further." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:138 +msgid "" +"Alternatively, if you do not want to install this package, run this script " +"to enable remote root access:" +msgstr "" + +#: ../basic_environment.rst:21 +msgid "" +"Although most environments include Identity, Image service, Compute, at " +"least one networking service, and the dashboard, the Object Storage service " +"can operate independently. If your use case only involves Object Storage, " +"you can skip to :ref:`swift` after configuring the appropriate nodes for it. " +"However, the dashboard requires at least the Image service and Compute." +msgstr "" + +#: ../launch-instance.rst:11 +msgid "" +"An instance is a VM that OpenStack provisions on a compute node. This guide " +"shows you how to launch a minimal instance using the :term:`CirrOS` image " +"that you added to your environment in the :doc:`glance` chapter. In these " +"steps, you use the command-line interface (CLI) on your controller node or " +"any system with the appropriate OpenStack client libraries. To use the " +"dashboard, see the `OpenStack User Guide `__." +msgstr "" + +#: ../debconf/debconf-concepts.rst:42 +msgid "" +"Another way to disable the ``debconf`` package is to prefix the :command:" +"`apt` command with ``DEBIAN_FRONTEND=noninteractive``, as follows:" +msgstr "" + +#: ../neutron-concepts.rst:22 +msgid "" +"Any given Networking set up has at least one external network. Unlike the " +"other networks, the external network is not merely a virtually defined " +"network. Instead, it represents a view into a slice of the physical, " +"external network accessible outside the OpenStack installation. IP addresses " +"on the external network are accessible by anybody physically on the outside " +"network. Because the external network merely represents a view into the " +"outside network, DHCP is disabled on this network." +msgstr "" + +#: ../keystone-users.rst:89 +msgid "" +"Any roles that you create must map to roles specified in the :file:`policy." +"json` file in the configuration file directory of each OpenStack service. " +"The default policy for most services grants administrative access to the " +"``admin`` role. For more information, see the `Operations Guide - Managing " +"Projects and Users `__." +msgstr "" + +#: ../app_reserved_uids.rst:3 +msgid "Appendix A. Reserved user IDs" +msgstr "" + +#: ../overview.rst:3 +msgid "Architecture" +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:96 +msgid "As an example, here are screenshots from the ``cinder-common`` package:" +msgstr "" + +#: ../keystone-verify.rst:83 +msgid "" +"As the ``admin`` user, list projects to verify that the ``admin`` user can " +"execute admin-only CLI commands and that the Identity service contains the " +"projects that you created in :doc:`keystone-users`:" +msgstr "" + +#: ../keystone-verify.rst:126 +msgid "" +"As the ``admin`` user, list roles to verify that the Identity service " +"contains the role that you created in :doc:`keystone-users`:" +msgstr "" + +#: ../keystone-verify.rst:106 +msgid "" +"As the ``admin`` user, list users to verify that the Identity service " +"contains the users that you created in :doc:`keystone-users`:" +msgstr "" + +#: ../keystone-verify.rst:34 +msgid "" +"As the ``admin`` user, request an authentication token from the Identity " +"version 2.0 API:" +msgstr "" + +#: ../keystone-verify.rst:171 +msgid "" +"As the ``demo`` user, attempt to list users to verify that it cannot execute " +"admin-only CLI commands:" +msgstr "" + +#: ../keystone-verify.rst:146 +msgid "" +"As the ``demo`` user, request an authentication token from the Identity " +"version 3 API:" +msgstr "" + +#: ../app_reserved_uids.rst:96 +msgid "Assigned during package installation" +msgstr "" + +#: ../launch-instance-neutron.rst:268 +msgid "Associate the floating IP address with your instance:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:346 ../launch-instance-nova.rst:310 +msgid "Attach the ``demo-volume1`` volume to the ``demo-instance1`` instance:" +msgstr "" + +#: ../neutron-initial-networks.rst:229 +msgid "Attach the router to the ``demo`` tenant subnet:" +msgstr "" + +#: ../neutron-initial-networks.rst:236 +msgid "Attach the router to the external network by setting it as the gateway:" +msgstr "" + +#: ../dashboard-verify.rst:22 +msgid "Authenticate using ``admin`` or ``demo`` user credentials." +msgstr "" + +#: ../cinder-storage-node.rst:320 +msgid "" +"Back-end names are arbitrary. As an example, this guide uses the name of the " +"driver as the name of the back end." +msgstr "" + +#: ../basic_environment.rst:3 +msgid "Basic environment" +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:5 +msgid "" +"Because most OpenStack services must access the Identity service, you must " +"configure the IP address of the ``keystone`` server to be able to access it. " +"You must also configure the ``admin_tenant_name``, ``admin_user``, and " +"``admin_password`` options for each service to work." +msgstr "" + +#: ../networking-nova.rst:121 +msgid "" +"Before launching your first instance, you must create the necessary virtual " +"network infrastructure to which the instance will connect. This network " +"typically provides Internet access *from* instances. You can enable Internet " +"access *to* individual instances using a :term:`floating IP address` and " +"suitable :term:`security group` rules. The ``admin`` tenant owns this " +"network because it provides external network access for multiple tenants." +msgstr "" + +#: ../neutron-initial-networks.rst:5 +msgid "" +"Before launching your first instance, you must create the necessary virtual " +"network infrastructure to which the instances connect, including the :ref:" +"`external-network` and :ref:`tenant-network`. After creating this " +"infrastructure, we recommend that you :ref:`verify-connectivity` and resolve " +"any issues before proceeding further. :ref:`Initial networks " +"` provides a basic architectural overview of the components " +"that Networking implements for the initial networks and shows how network " +"traffic flows from the instance to the external network or Internet." +msgstr "" + +#: ../swift-initial-rings.rst:5 +msgid "" +"Before starting the Object Storage services, you must create the initial " +"account, container, and object rings. The ring builder creates configuration " +"files that each node uses to determine and deploy the storage architecture. " +"For simplicity, this guide uses one region and zone with 2^10 (1024) maximum " +"partitions, 3 replicas of each object, and 1 hour minimum time between " +"moving a partition more than once. For Object Storage, a partition indicates " +"a directory on a storage device rather than a conventional partition table. " +"For more information, see the `Deployment Guide `__." +msgstr "" + +#: ../basic_environment.rst:42 +msgid "Before you begin" +msgstr "" + +#: ../keystone-install.rst:14 +msgid "" +"Before you configure the OpenStack Identity service, you must create a " +"database and an administration token." +msgstr "" + +#: ../neutron-controller-node.rst:7 +msgid "" +"Before you configure the OpenStack Networking (neutron) service, you must " +"create a database, service credentials, and API endpoint." +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:10 ../neutron-network-node.rst:10 +msgid "" +"Before you install and configure OpenStack Networking, you must configure " +"certain kernel networking parameters." +msgstr "" + +#: ../heat-install.rst:11 +msgid "" +"Before you install and configure Orchestration, you must create a database, " +"service credentials, and API endpoints." +msgstr "" + +#: ../ceilometer-controller-install.rst:13 +msgid "" +"Before you install and configure Telemetry, you must install ``MongoDB``, " +"create a MongoDB database, service credentials, and API endpoint." +msgstr "" + +#: ../cinder-controller-node.rst:13 +msgid "" +"Before you install and configure the Block Storage service, you must create " +"a database, service credentials, and API endpoint." +msgstr "" + +#: ../nova-controller-install.rst:10 +msgid "" +"Before you install and configure the Compute service, you must create a " +"database, service credentials, and API endpoint." +msgstr "" + +#: ../glance-install.rst:20 +msgid "" +"Before you install and configure the Image service, you must create a " +"database, service credentials, and API endpoint." +msgstr "" + +#: ../glance.rst:26 +msgid "" +"Before you proceed, ensure that the controller node has at least several " +"gigabytes of space available in this directory." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:122 +msgid "" +"By default in Debian, you can access the MySQL server from either localhost " +"through the socket file or 127.0.0.1. To access it over the network, you " +"must edit the :file:`/etc/mysql/my.cnf` file, and the ``mysql.user`` table. " +"To do so, Debian provides a helper script in the ``openstack-deploy`` " +"package. To use it, install the package:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:266 ../neutron-controller-node.rst:354 +msgid "" +"By default, Compute uses an internal firewall service. Since Networking " +"includes a firewall service, you must disable the Compute firewall service " +"by using the ``nova.virt.firewall.NoopFirewallDriver`` firewall driver." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:25 +msgid "" +"By default, ``dbconfig-common`` does not provide access to database servers " +"over a network. If you want the ``dbconfig-common`` package to prompt for " +"remote database servers that are accessed over a network and not through a " +"UNIX socket file, reconfigure it, as follows:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:248 ../neutron-controller-node.rst:336 +msgid "" +"By default, distribution packages configure Compute to use legacy " +"networking. You must reconfigure Compute to manage networks through " +"Networking." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:20 +msgid "" +"By default, the ``dbconfig-common`` package configures the OpenStack " +"services to use SQLite. So if you use debconf in non-interactive mode and " +"without pre-seeding, the OpenStack services that you install will use SQLite." +msgstr "" + +#: ../basics-ntp.rst:41 +msgid "" +"By default, the controller node synchronizes the time via a pool of public " +"servers. However, you can optionally edit the :file:`/etc/ntp.conf` file to " +"configure alternative servers such as those provided by your organization." +msgstr "" + +#: ../swift-initial-rings.rst:22 ../swift-initial-rings.rst:103 +#: ../swift-initial-rings.rst:182 +msgid "Change to the :file:`/etc/swift` directory." +msgstr "" + +#: ../launch-instance-neutron.rst:278 +msgid "Check the status of your floating IP address:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:149 ../launch-instance-nova.rst:168 +msgid "Check the status of your instance:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:408 ../ceilometer-nova.rst:88 +#: ../heat-install.rst:294 +msgid "" +"Comment out any ``auth_host``, ``auth_port``, and ``auth_protocol`` options " +"because the ``identity_uri`` option replaces them." +msgstr "" + +#: ../dashboard-install.rst:100 +msgid "Comment out any other session storage configuration." +msgstr "" + +#: ../basics-ntp.rst:123 +msgid "" +"Comment out or remove all but one ``server`` key and change it to reference " +"the controller node." +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:262 ../cinder-storage-node.rst:264 +#: ../glance-install.rst:208 ../glance-install.rst:287 +#: ../nova-compute-install.rst:114 ../nova-controller-install.rst:218 +msgid "" +"Comment out or remove any other options in the ``[keystone_authtoken]`` " +"section." +msgstr "" + +#: ../swift-controller-node.rst:120 +msgid "Complete OpenStack environments already include some of these packages." +msgstr "" + +#: ../basic_environment.rst:56 +msgid "Compute Node: 1 processor, 2 GB memory, and 10 GB storage" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:222 ../basics-networking-nova.rst:110 +msgid "Compute node" +msgstr "" + +#: ../overview.rst:111 +msgid "Conceptual architecture" +msgstr "" + +#: ../debconf/debconf.rst:3 +msgid "Configure OpenStack with debconf" +msgstr "" + +#: ../dashboard-install.rst:110 +msgid "" +"Configure ``user`` as the default role for users that you create via the " +"dashboard::" +msgstr "" + +#: ../networking-nova.rst:40 +msgid "Configure compute node" +msgstr "" + +#: ../networking-nova.rst:6 +msgid "Configure controller node" +msgstr "" + +#: ../swift-storage-node.rst:47 +msgid "Configure shared items on both storage nodes:" +msgstr "" + +#: ../ceilometer-cinder.rst:3 +msgid "Configure the Block Storage service" +msgstr "" + +#: ../ceilometer-nova.rst:3 +msgid "Configure the Compute service" +msgstr "" + +#: ../ceilometer-nova.rst:123 +msgid "Configure the Compute service to send notifications to the message bus." +msgstr "" + +#: ../ceilometer-glance.rst:3 +msgid "Configure the Image service" +msgstr "" + +#: ../ceilometer-swift.rst:3 +msgid "Configure the Object Storage service" +msgstr "" + +#: ../dashboard-install.rst:89 +msgid "Configure the ``memcached`` session storage service::" +msgstr "" + +#: ../keystone-services.rst:32 +msgid "Configure the authentication token:" +msgstr "" + +#: ../dashboard-install.rst:80 +msgid "" +"Configure the dashboard to use OpenStack services on the ``controller`` " +"node::" +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:3 +msgid "Configure the database with dbconfig-common" +msgstr "" + +#: ../keystone-services.rst:48 +msgid "Configure the endpoint URL:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:84 ../basics-networking-neutron.rst:129 +#: ../basics-networking-neutron.rst:226 ../basics-networking-nova.rst:72 +#: ../basics-networking-nova.rst:114 +msgid "Configure the first interface as the management interface:" +msgstr "" + +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-storage-node.rst:26 ../swift-storage-node.rst:29 +#: ../swift-storage-node.rst:39 +msgid "Configure the management interface:" +msgstr "" + +#: ../basics-ntp.rst:118 +msgid "" +"Configure the network and compute nodes to reference the controller node." +msgstr "" + +#: ../basics-networking-neutron.rst:137 ../basics-networking-neutron.rst:238 +msgid "Configure the second interface as the instance tunnels interface:" +msgstr "" + +#: ../swift-storage-node.rst:27 +msgid "Configure unique items on the first storage node:" +msgstr "" + +#: ../swift-storage-node.rst:37 +msgid "Configure unique items on the second storage node:" +msgstr "" + +#: ../glance-verify.rst:91 +msgid "Confirm upload of the image and validate attributes:" +msgstr "" + +#: ../swift-initial-rings.rst:96 +msgid "Container ring" +msgstr "" + +#: ../index.rst:72 +msgid "Contents" +msgstr "" + +#: ../basics-ntp.rst:191 +msgid "" +"Contents in the *condition* column should indicate ``sys.peer`` for at least " +"one server." +msgstr "" + +#: ../basics-ntp.rst:220 +msgid "Contents in the *condition* column should indicate ``sys.peer``." +msgstr "" + +#: ../basics-ntp.rst:178 ../basics-ntp.rst:208 +msgid "" +"Contents in the *refid* column typically reference IP addresses of upstream " +"servers." +msgstr "" + +#: ../basics-ntp.rst:203 +msgid "" +"Contents in the *remote* column should indicate the hostname of the " +"controller node." +msgstr "" + +#: ../basics-ntp.rst:173 +msgid "" +"Contents in the *remote* column should indicate the hostname or IP address " +"of one or more NTP servers." +msgstr "" + +#: ../basic_environment.rst:52 +msgid "Controller Node: 1 processor, 2 GB memory, and 5 GB storage" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-ntp.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:80 ../basics-networking-nova.rst:68 +#: ../basics-ntp.rst:15 +msgid "Controller node" +msgstr "" + +#: ../swift-initial-rings.rst:255 +msgid "" +"Copy the :file:`account.ring.gz`, :file:`container.ring.gz`, and :file:" +"`object.ring.gz` files to the :file:`/etc/swift` directory on each storage " +"node and any additional nodes running the proxy service." +msgstr "" + +#: ../swift-storage-node.rst:49 +msgid "" +"Copy the contents of the :file:`/etc/hosts` file from the controller node " +"and add the following to it:" +msgstr "" + +#: ../cinder-storage-node.rst:36 +msgid "" +"Copy the contents of the :file:`/etc/hosts` file from the controller node to " +"the storage node and add the following to it::" +msgstr "" + +#: ../keystone-openrc.rst:3 +msgid "Create OpenStack client environment scripts" +msgstr "" + +#: ../cinder-verify.rst:49 +msgid "Create a 1 GB volume:" +msgstr "" + +#: ../launch-instance-neutron.rst:249 +msgid "" +"Create a :term:`floating IP address` on the ``ext-net`` external network:" +msgstr "" + +#: ../cinder-controller-node.rst:53 +msgid "Create a ``cinder`` user:" +msgstr "" + +#: ../glance-verify.rst:31 +msgid "Create a temporary local directory:" +msgstr "" + +#: ../heat-verify.rst:20 +msgid "" +"Create a test template in the :file:`test-stack.yml` file with the following " +"content:" +msgstr "" + +#: ../keystone-users.rst:24 +msgid "" +"Create an administrative project, user, and role for administrative " +"operations in your environment:" +msgstr "" + +#: ../neutron-network-node.rst:331 +msgid "" +"Create and edit the :file:`/etc/neutron/dnsmasq-neutron.conf` file to enable " +"the DHCP MTU option (26) and configure it to 1454 bytes:" +msgstr "" + +#: ../keystone-openrc.rst:17 +msgid "" +"Create client environment scripts for the ``admin`` and ``demo`` projects " +"and users. Future portions of this guide reference these scripts to load " +"appropriate credentials for client operations." +msgstr "" + +#: ../networking-nova.rst:120 +msgid "Create initial network" +msgstr "" + +#: ../neutron-initial-networks.rst:3 +msgid "Create initial networks" +msgstr "" + +#: ../swift-initial-rings.rst:3 +msgid "Create initial rings" +msgstr "" + +#: ../keystone-users.rst:3 +msgid "Create projects, users, and roles" +msgstr "" + +#: ../cinder-controller-node.rst:118 +msgid "Create the Block Storage service API endpoints:" +msgstr "" + +#: ../nova-controller-install.rst:95 +msgid "Create the Compute service API endpoint:" +msgstr "" + +#: ../keystone-services.rst:104 +msgid "Create the Identity service API endpoint:" +msgstr "" + +#: ../glance-install.rst:106 +msgid "Create the Image service API endpoint:" +msgstr "" + +#: ../cinder-storage-node.rst:111 +msgid "Create the LVM physical volume :file:`/dev/sdb1`:" +msgstr "" + +#: ../cinder-storage-node.rst:123 +msgid "Create the LVM volume group ``cinder-volumes``:" +msgstr "" + +#: ../neutron-controller-node.rst:92 +msgid "Create the Networking service API endpoint:" +msgstr "" + +#: ../swift-controller-node.rst:82 +msgid "Create the Object Storage service API endpoint:" +msgstr "" + +#: ../heat-install.rst:152 +msgid "Create the Orchestration service API endpoints:" +msgstr "" + +#: ../ceilometer-controller-install.rst:282 +msgid "Create the Telemetry module API endpoint:" +msgstr "" + +#: ../ceilometer-swift.rst:22 +msgid "Create the ``ResellerAdmin`` role:" +msgstr "" + +#: ../keystone-users.rst:27 +msgid "Create the ``admin`` project:" +msgstr "" + +#: ../keystone-users.rst:63 +msgid "Create the ``admin`` role:" +msgstr "" + +#: ../keystone-users.rst:46 +msgid "Create the ``admin`` user:" +msgstr "" + +#: ../ceilometer-controller-install.rst:266 +msgid "Create the ``ceilometer`` service entity:" +msgstr "" + +#: ../ceilometer-controller-install.rst:237 +msgid "Create the ``ceilometer`` user:" +msgstr "" + +#: ../cinder-controller-node.rst:25 +msgid "Create the ``cinder`` database:" +msgstr "" + +#: ../cinder-controller-node.rst:82 +msgid "Create the ``cinder`` service entities:" +msgstr "" + +#: ../keystone-users.rst:116 +msgid "Create the ``demo`` project:" +msgstr "" + +#: ../keystone-users.rst:135 +msgid "Create the ``demo`` user:" +msgstr "" + +#: ../glance-install.rst:32 +msgid "Create the ``glance`` database:" +msgstr "" + +#: ../glance-install.rst:90 +msgid "Create the ``glance`` service entity:" +msgstr "" + +#: ../glance-install.rst:60 +msgid "Create the ``glance`` user:" +msgstr "" + +#: ../heat-install.rst:76 +msgid "Create the ``heat_stack_owner`` role:" +msgstr "" + +#: ../heat-install.rst:105 +msgid "Create the ``heat_stack_user`` role:" +msgstr "" + +#: ../heat-install.rst:125 +msgid "Create the ``heat`` and ``heat-cfn`` service entities:" +msgstr "" + +#: ../heat-install.rst:23 +msgid "Create the ``heat`` database::" +msgstr "" + +#: ../heat-install.rst:47 +msgid "Create the ``heat`` user:" +msgstr "" + +#: ../keystone-install.rst:26 +msgid "Create the ``keystone`` database:" +msgstr "" + +#: ../neutron-controller-node.rst:19 +msgid "Create the ``neutron`` database:" +msgstr "" + +#: ../neutron-controller-node.rst:75 +msgid "Create the ``neutron`` service entity:" +msgstr "" + +#: ../neutron-controller-node.rst:46 +msgid "Create the ``neutron`` user:" +msgstr "" + +#: ../nova-controller-install.rst:22 +msgid "Create the ``nova`` database:" +msgstr "" + +#: ../nova-controller-install.rst:79 +msgid "Create the ``nova`` service entity:" +msgstr "" + +#: ../nova-controller-install.rst:50 +msgid "Create the ``nova`` user:" +msgstr "" + +#: ../keystone-users.rst:99 +msgid "Create the ``service`` project:" +msgstr "" + +#: ../swift-controller-node.rst:66 +msgid "Create the ``swift`` service entity:" +msgstr "" + +#: ../swift-controller-node.rst:37 +msgid "Create the ``swift`` user:" +msgstr "" + +#: ../keystone-users.rst:152 +msgid "Create the ``user`` role:" +msgstr "" + +#: ../swift-initial-rings.rst:24 +msgid "Create the base :file:`account.builder` file:" +msgstr "" + +#: ../swift-initial-rings.rst:105 +msgid "Create the base :file:`container.builder` file:" +msgstr "" + +#: ../swift-initial-rings.rst:184 +msgid "Create the base :file:`object.builder` file:" +msgstr "" + +#: ../heat-install.rst:343 +msgid "Create the heat domain in Identity service:" +msgstr "" + +#: ../swift-storage-node.rst:94 +msgid "Create the mount point directory structure:" +msgstr "" + +# #-#-#-#-# networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-initial-networks.pot (Installation Guide 0.1) #-#-#-#-# +#: ../networking-nova.rst:142 ../neutron-initial-networks.rst:40 +#: ../neutron-initial-networks.rst:139 +msgid "Create the network:" +msgstr "" + +#: ../neutron-initial-networks.rst:211 +msgid "Create the router:" +msgstr "" + +#: ../keystone-services.rst:3 +msgid "Create the service entity and API endpoint" +msgstr "" + +#: ../keystone-services.rst:67 +msgid "Create the service entity for the Identity service:" +msgstr "" + +#: ../neutron-initial-networks.rst:72 ../neutron-initial-networks.rst:165 +msgid "Create the subnet:" +msgstr "" + +#: ../dashboard-next-step.rst:17 +msgid "" +"Customize your dashboard. See section `Customize the dashboad `__ in the `OpenStack Cloud Administrator Guide `__ for information on setting up " +"colors, logos, and site titles." +msgstr "" + +#: ../basic_environment.rst:127 +msgid "Database password (no variable used)" +msgstr "" + +#: ../basic_environment.rst:160 +msgid "Database password for Compute service" +msgstr "" + +#: ../basic_environment.rst:144 +msgid "Database password for Image service" +msgstr "" + +#: ../basic_environment.rst:136 +msgid "Database password for the Block Storage service" +msgstr "" + +#: ../basic_environment.rst:156 +msgid "Database password for the Networking service" +msgstr "" + +#: ../basic_environment.rst:148 +msgid "Database password for the Orchestration service" +msgstr "" + +#: ../basic_environment.rst:132 +msgid "Database password for the Telemetry service" +msgstr "" + +#: ../basic_environment.rst:140 +msgid "Database password for the dashboard" +msgstr "" + +#: ../basic_environment.rst:166 +msgid "Database password of Data processing service" +msgstr "" + +#: ../basic_environment.rst:170 +msgid "Database password of Database service" +msgstr "" + +#: ../basic_environment.rst:154 +msgid "Database password of Identity service" +msgstr "" + +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-finalize-installation.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../glance-install.rst:134 ../nova-compute-install.rst:36 +#: ../nova-controller-install.rst:123 ../swift-controller-node.rst:110 +#: ../swift-finalize-installation.rst:9 ../swift-storage-node.rst:183 +msgid "" +"Default configuration files vary by distribution. You might need to add " +"these sections and options rather than modifying existing sections and " +"options. Also, an ellipsis (...) in the configuration snippets indicates " +"potential default configuration options that you should retain." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:90 ../basics-networking-neutron.rst:135 +#: ../basics-networking-neutron.rst:232 ../basics-networking-nova.rst:78 +#: ../basics-networking-nova.rst:120 ../cinder-storage-node.rst:32 +msgid "Default gateway: 10.0.0.1" +msgstr "" + +#: ../swift-storage-node.rst:33 ../swift-storage-node.rst:43 +msgid "Default gateway: ``10.0.0.1``" +msgstr "" + +#: ../neutron-network-node.rst:469 +msgid "" +"Depending on your network interface driver, you may need to disable :term:" +"`generic receive offload (GRO)` to achieve suitable throughput between your " +"instances and the external network." +msgstr "" + +# #-#-#-#-# app_reserved_uids.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basic_environment.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# overview.pot (Installation Guide 0.1) #-#-#-#-# +#: ../app_reserved_uids.rst:20 ../basic_environment.rst:126 ../overview.rst:24 +msgid "Description" +msgstr "" + +#: ../nova-compute-install.rst:220 +msgid "" +"Determine whether your compute node supports hardware acceleration for " +"virtual machines:" +msgstr "" + +#: ../basics-packages.rst:17 +msgid "" +"Disable or remove any automatic update services because they can impact your " +"OpenStack environment." +msgstr "" + +#: ../swift-initial-rings.rst:253 +msgid "Distribute ring configuration files" +msgstr "" + +#: ../basics-packages.rst:11 +msgid "" +"Distributions release OpenStack packages as part of the distribution or " +"using other methods because of differing release schedules. Perform these " +"procedures on all nodes." +msgstr "" + +#: ../keystone-users.rst:132 +msgid "" +"Do not repeat this step when creating additional users for this project." +msgstr "" + +#: ../swift-verify.rst:51 +msgid "Download a test file:" +msgstr "" + +#: ../ceilometer-verify.rst:32 +msgid "Download an image from the Image service:" +msgstr "" + +#: ../glance-verify.rst:37 +msgid "Download the source image into it:" +msgstr "" + +#: ../cinder-storage-node.rst:150 +msgid "" +"Each item in the filter array begins with ``a`` for **accept** or ``r`` for " +"**reject** and includes a regular expression for the device name. The array " +"must end with ``r/.*/`` to reject any remaining devices. You can use the :" +"command:`vgs -vvvv` command to test filters." +msgstr "" + +#: ../neutron-concepts.rst:56 +msgid "" +"Each plug-in that Networking uses has its own concepts. While not vital to " +"operating the VNI and OpenStack environment, understanding these concepts " +"can help you set up Networking. All Networking installations use a core plug-" +"in and a security group plug-in (or just the No-Op security group plug-in). " +"Additionally, Firewall-as-a-Service (FWaaS) and Load-Balancer-as-a-Service " +"(LBaaS) plug-ins are available." +msgstr "" + +#: ../neutron-concepts.rst:18 +msgid "" +"Each router has one gateway that connects to a network, and many interfaces " +"connected to subnets. Subnets can access machines on other subnets connected " +"to the same router." +msgstr "" + +#: ../keystone-services.rst:129 +msgid "" +"Each service that you add to your OpenStack environment requires one or more " +"service entities and one API endpoint in the Identity service." +msgstr "" + +#: ../app_reserved_uids.rst:98 +msgid "Each user belongs to a user group with the same name as the user." +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:349 ../ceilometer-nova.rst:35 +msgid "" +"Edit the :file:`/etc/ceilometer/ceilometer.conf` file and complete the " +"following actions:" +msgstr "" + +# #-#-#-#-# ceilometer-cinder.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-cinder.rst:12 ../cinder-controller-node.rst:205 +#: ../cinder-storage-node.rst:207 +msgid "" +"Edit the :file:`/etc/cinder/cinder.conf` file and complete the following " +"actions:" +msgstr "" + +#: ../ceilometer-glance.rst:9 +msgid "" +"Edit the :file:`/etc/glance/glance-api.conf` and :file:`/etc/glance/glance-" +"registry.conf` files and complete the following actions:" +msgstr "" + +#: ../glance-install.rst:167 +msgid "" +"Edit the :file:`/etc/glance/glance-api.conf` file and complete the following " +"actions:" +msgstr "" + +#: ../glance-install.rst:246 +msgid "" +"Edit the :file:`/etc/glance/glance-registry.conf` file and complete the " +"following actions:" +msgstr "" + +#: ../heat-install.rst:237 +msgid "" +"Edit the :file:`/etc/heat/heat.conf` file and complete the following actions:" +msgstr "" + +#: ../basics-networking-neutron.rst:100 +msgid "Edit the :file:`/etc/hosts:` file to contain the following:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:197 ../basics-networking-neutron.rst:256 +#: ../basics-networking-nova.rst:88 ../basics-networking-nova.rst:180 +msgid "Edit the :file:`/etc/hosts` file to contain the following:" +msgstr "" + +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../nova-compute-install.rst:66 ../nova-controller-install.rst:161 +msgid "" +"Edit the :file:`/etc/nova/nova.conf` file and complete the following actions:" +msgstr "" + +#: ../ceilometer-nova.rst:125 +msgid "" +"Edit the :file:`/etc/nova/nova.conf` file and configure notifications in the " +"``[DEFAULT]`` section:" +msgstr "" + +#: ../basics-ntp.rst:46 +msgid "" +"Edit the :file:`/etc/ntp.conf` file and add, change, or remove the following " +"keys as necessary for your environment:" +msgstr "" + +#: ../basics-ntp.rst:121 +msgid "Edit the :file:`/etc/ntp.conf` file:" +msgstr "" + +#: ../swift-storage-node.rst:116 +msgid "Edit the :file:`/etc/rsyncd.conf` file and add the following to it:" +msgstr "" + +#: ../ceilometer-swift.rst:53 +msgid "" +"Edit the :file:`/etc/swift/proxy-server.conf` file and complete the " +"following actions:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:13 ../neutron-network-node.rst:13 +msgid "" +"Edit the :file:`/etc/sysctl.conf` file to contain the following parameters:" +msgstr "" + +#: ../keystone-openrc.rst:21 +msgid "Edit the :file:`admin-openrc.sh` file and add the following content:" +msgstr "" + +#: ../keystone-openrc.rst:37 +msgid "Edit the :file:`demo-openrc.sh` file and add the following content:" +msgstr "" + +#: ../swift-storage-node.rst:101 +msgid "Edit the :file:`etc/fstab` file and add the following to it:" +msgstr "" + +#: ../overview.rst:39 +msgid "" +"Enables Network-Connectivity-as-a-Service for other OpenStack services, such " +"as OpenStack Compute. Provides an API for users to define networks and the " +"attachments into them. Has a pluggable architecture that supports many " +"popular networking vendors and technologies." +msgstr "" + +#: ../overview.rst:129 +msgid "Example architectures" +msgstr "" + +#: ../neutron-initial-networks.rst:178 +msgid "Example using ``192.168.1.0/24``:" +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:42 ../glance-install.rst:49 +#: ../heat-install.rst:36 ../keystone-install.rst:43 +#: ../neutron-controller-node.rst:35 ../nova-controller-install.rst:39 +msgid "Exit the database access client." +msgstr "" + +#: ../index.rst:62 +msgid "" +"Explanations of configuration options and sample configuration files are " +"included." +msgstr "" + +#: ../neutron-initial-networks.rst:22 +msgid "External network" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:34 ../basics-networking-nova.rst:23 +msgid "External on 203.0.113.0/24 with gateway 203.0.113.1" +msgstr "" + +#: ../overview.rst:122 +msgid "Figure 1.1 Conceptual architecture" +msgstr "" + +#: ../overview.rst:201 +msgid "" +"Figure 1.2 Minimal architecture example with OpenStack Networking (neutron)—" +"Hardware requirements" +msgstr "" + +#: ../overview.rst:212 +msgid "" +"Figure 1.3 Minimal architecture example with OpenStack Networking (neutron)—" +"Network layout" +msgstr "" + +#: ../overview.rst:221 +msgid "" +"Figure 1.4 Minimal architecture example with OpenStack Networking (neutron)—" +"Service layout" +msgstr "" + +#: ../overview.rst:285 +msgid "" +"Figure 1.5 Minimal architecture example with legacy networking (nova-network)" +"—Hardware requirements" +msgstr "" + +#: ../overview.rst:296 +msgid "" +"Figure 1.6 Minimal architecture example with legacy networking (nova-network)" +"—Network layout" +msgstr "" + +#: ../overview.rst:305 +msgid "" +"Figure 1.7 Minimal architecture example with legacy networking (nova-network)" +"—Service layout" +msgstr "" + +#: ../swift-finalize-installation.rst:3 +msgid "Finalize installation" +msgstr "" + +#: ../basic_environment.rst:114 +msgid "" +"For OpenStack services, this guide uses `SERVICE_PASS` to reference service " +"account passwords and `SERVICE_DBPASS` to reference database passwords." +msgstr "" + +#: ../basic_environment.rst:44 +msgid "" +"For best performance, we recommend that your environment meets or exceeds " +"the hardware requirements in :ref:`figure-neutron-network-hw` or :ref:" +"`figure-legacy-network-hw`. However, OpenStack does not require a " +"significant amount of resources and the following minimum requirements " +"should support a proof-of-concept environment with core services and " +"several :term:`CirrOS` instances:" +msgstr "" + +#: ../dashboard-next-step.rst:35 +msgid "" +"For details about browsers that support noVNC, see `README `__ and `browser support `__." +msgstr "" + +#: ../debconf/debconf-rabbitmq.rst:5 +msgid "" +"For every package that must connect to a Messaging Server, the Debian " +"package enables you to configure the IP address for that server and the user " +"name and password that is used to connect. The following example shows " +"configuration with the ``ceilometer-common`` package:" +msgstr "" + +#: ../neutron-initial-networks.rst:94 +msgid "" +"For example, using ``203.0.113.0/24`` with floating IP address range " +"``203.0.113.101`` to ``203.0.113.200``:" +msgstr "" + +#: ../networking-nova.rst:152 +msgid "" +"For example, using an exclusive slice of ``203.0.113.0/24`` with IP address " +"range ``203.0.113.24`` to ``203.0.113.31``:" +msgstr "" + +#: ../glance-verify.rst:81 +msgid "" +"For information about disk and container formats for images, see `Disk and " +"container formats for images `__ in the ``OpenStack Virtual Machine Image Guide``." +msgstr "" + +#: ../glance-verify.rst:75 +msgid "" +"For information about the :command:`glance image-create` parameters, see " +"`Image service command-line client `__ " +"in the ``OpenStack Command-Line Interface Reference``." +msgstr "" + +#: ../glance.rst:29 +msgid "" +"For information on requirements for other back ends, see `Configuration " +"Reference `__." +msgstr "" + +#: ../glance-verify.rst:9 +msgid "" +"For more information about how to download and build images, see `OpenStack " +"Virtual Machine Image Guide `__. For information about how to manage images, see the " +"`OpenStack User Guide `__." +msgstr "" + +#: ../cinder-verify.rst:8 +msgid "" +"For more information about how to manage volumes, see the `OpenStack User " +"Guide `__." +msgstr "" + +#: ../basic_environment.rst:93 +msgid "" +"For more information about system requirements, see the `OpenStack " +"Operations Guide `_." +msgstr "" + +#: ../networking.rst:13 +msgid "" +"For more information, see the `Networking `__ chapter of the OpenStack Cloud " +"Administrator Guide." +msgstr "" + +#: ../keystone-services.rst:29 +msgid "" +"For security reasons, do not use the temporary authentication token for " +"longer than necessary to initialize the Identity service." +msgstr "" + +#: ../glance.rst:21 +msgid "" +"For simplicity, this guide describes configuring the Image service to use " +"the ``file`` back end, which uploads and stores in a directory on the " +"controller node hosting the Image service. By default, this directory is :" +"file:`/var/lib/glance/images/`." +msgstr "" + +#: ../keystone-users.rst:12 +msgid "For simplicity, this guide implicitly uses the ``default`` domain." +msgstr "" + +#: ../basics-ntp.rst:61 +msgid "" +"For the ``restrict`` keys, you essentially remove the ``nopeer`` and " +"``noquery`` options." +msgstr "" + +#: ../neutron-concepts.rst:37 +msgid "" +"For the outside network to access VMs, and vice versa, routers between the " +"networks are needed. Each router has one gateway that is connected to a " +"network and many interfaces that are connected to subnets. Like a physical " +"router, subnets can access machines on other subnets that are connected to " +"the same router, and machines can access the outside network through the " +"gateway for the router." +msgstr "" + +#: ../swift-storage-node.rst:87 +msgid "Format the :file:`/dev/sdb1` and :file:`/dev/sdc1` partitions as XFS:" +msgstr "" + +#: ../neutron-initial-networks.rst:263 +msgid "From a host on the external network, ping the tenant router gateway:" +msgstr "" + +#: ../basics-networking-neutron.rst:380 +msgid "From the *compute* node, :command:`ping` a site on the Internet:" +msgstr "" + +#: ../basics-networking-neutron.rst:411 +msgid "" +"From the *compute* node, :command:`ping` the instance tunnels interface on " +"the *network* node:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:395 ../basics-networking-nova.rst:253 +msgid "" +"From the *compute* node, :command:`ping` the management interface on the " +"*controller* node:" +msgstr "" + +#: ../basics-networking-nova.rst:238 +msgid "From the *compute* node, ``ping`` a site on the Internet:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:285 ../basics-networking-nova.rst:207 +msgid "From the *controller* node, :command:`ping` a site on the Internet:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:316 ../basics-networking-nova.rst:222 +msgid "" +"From the *controller* node, :command:`ping` the management interface on the " +"*compute* node:" +msgstr "" + +#: ../basics-networking-neutron.rst:300 +msgid "" +"From the *controller* node, :command:`ping` the management interface on the " +"*network* node:" +msgstr "" + +#: ../basics-networking-neutron.rst:332 +msgid "From the *network* node, :command:`ping` a site on the Internet:" +msgstr "" + +#: ../basics-networking-neutron.rst:364 +msgid "" +"From the *network* node, :command:`ping` the instance tunnels interface on " +"the *compute* node:" +msgstr "" + +#: ../basics-networking-neutron.rst:347 +msgid "" +"From the *network* node, :command:`ping` the management interface on the " +"*controller* node:" +msgstr "" + +#: ../debconf/debconf-concepts.rst:63 +msgid "" +"Generally, the ``-common`` packages install the configuration files. For " +"example, the ``glance-common`` package installs the :file:`glance-api.conf` " +"and :file:`glance-registry.conf` files. So, for the Image service, you must " +"re-configure the ``glance-common`` package. The same applies for ``cinder-" +"common``, ``nova-common``, and ``heat-common`` packages." +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:10 +msgid "Generally, this section looks like this:" +msgstr "" + +#: ../launch-instance-nova.rst:20 +msgid "Generate a key pair:" +msgstr "" + +#: ../keystone-install.rst:46 +msgid "" +"Generate a random value to use as the administration token during initial " +"configuration:" +msgstr "" + +#: ../ceilometer-controller-install.rst:343 +msgid "Generate a random value to use as the telemetry secret:" +msgstr "" + +#: ../launch-instance-neutron.rst:19 +msgid "Generate and add a key pair:" +msgstr "" + +#: ../keystone-install.rst:32 +msgid "Grant proper access to the :file:`keystone` database:" +msgstr "" + +#: ../cinder-controller-node.rst:31 +msgid "Grant proper access to the ``cinder`` database:" +msgstr "" + +#: ../glance-install.rst:38 +msgid "Grant proper access to the ``glance`` database:" +msgstr "" + +#: ../heat-install.rst:27 +msgid "Grant proper access to the ``heat`` database::" +msgstr "" + +#: ../neutron-controller-node.rst:25 +msgid "" +"Grant proper access to the ``neutron`` database, replacing " +"``NEUTRON_DBPASS`` with a suitable password:" +msgstr "" + +#: ../nova-controller-install.rst:28 +msgid "Grant proper access to the ``nova`` database:" +msgstr "" + +#: ../horizon.rst:13 +msgid "Horizon enables you to customize the brand of the dashboard." +msgstr "" + +#: ../horizon.rst:15 +msgid "" +"Horizon provides a set of core classes and reusable templates and tools." +msgstr "" + +#: ../basic_environment.rst:83 +msgid "" +"However, VMs will reduce performance of your instances, particularly if your " +"hypervisor and/or processor lacks support for hardware acceleration of " +"nested VMs." +msgstr "" + +#: ../app_reserved_uids.rst:21 +msgid "ID" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:86 ../basics-networking-nova.rst:74 +msgid "IP address: 10.0.0.11" +msgstr "" + +#: ../basics-networking-neutron.rst:131 +msgid "IP address: 10.0.0.21" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:228 ../basics-networking-nova.rst:116 +msgid "IP address: 10.0.0.31" +msgstr "" + +#: ../cinder-storage-node.rst:28 +msgid "IP address: 10.0.0.41" +msgstr "" + +#: ../basics-networking-neutron.rst:139 +msgid "IP address: 10.0.1.21" +msgstr "" + +#: ../basics-networking-neutron.rst:240 +msgid "IP address: 10.0.1.31" +msgstr "" + +#: ../swift-storage-node.rst:31 +msgid "IP address: ``10.0.0.51``" +msgstr "" + +#: ../swift-storage-node.rst:41 +msgid "IP address: ``10.0.0.52``" +msgstr "" + +#: ../neutron-network-node.rst:304 +msgid "" +"Ideally, you can prevent these problems by enabling :term:`jumbo frames " +"` on the physical network that contains your tenant virtual " +"networks. Jumbo frames support MTUs up to approximately 9000 bytes which " +"negates the impact of GRE overhead on virtual networks. However, many " +"network devices lack support for jumbo frames and OpenStack administrators " +"often lack control over network infrastructure. Given the latter " +"complications, you can also prevent MTU problems by reducing the instance " +"MTU to account for GRE overhead. Determining the proper MTU value often " +"takes experimentation, but 1454 bytes works in most environments. You can " +"configure the DHCP server that assigns IP addresses to your instances to " +"also adjust the MTU." +msgstr "" + +#: ../cinder-verify.rst:91 +msgid "" +"If the status does not indicate ``available``, check the logs in the :file:`/" +"var/log/cinder` directory on the controller and volume nodes for more " +"information." +msgstr "" + +#: ../nova-compute-install.rst:157 +msgid "" +"If the web browser to access remote consoles resides on a host that cannot " +"resolve the ``controller`` hostname, you must replace ``controller`` with " +"the management interface IP address of the controller node." +msgstr "" + +#: ../nova-compute-install.rst:227 +msgid "" +"If this command returns a value of ``one or greater``, your compute node " +"supports hardware acceleration which typically requires no additional " +"configuration." +msgstr "" + +#: ../nova-compute-install.rst:231 +msgid "" +"If this command returns a value of ``zero``, your compute node does not " +"support hardware acceleration and you must configure ``libvirt`` to use QEMU " +"instead of KVM." +msgstr "" + +#: ../neutron-initial-networks.rst:257 +msgid "" +"If you are building your OpenStack nodes as virtual machines, you must " +"configure the hypervisor to permit promiscuous mode on the external network." +msgstr "" + +#: ../debconf/debconf-concepts.rst:13 +msgid "" +"If you are familiar with these packages and pre-seeding, you can proceed to :" +"doc:`../keystone`." +msgstr "" + +#: ../basic_environment.rst:89 +msgid "" +"If you choose to install on VMs, make sure your hypervisor permits :term:" +"`promiscuous mode` and disables MAC address filtering on the :term:`external " +"network`." +msgstr "" + +#: ../debconf/debconf-concepts.rst:50 +msgid "" +"If you configure a package with ``debconf`` incorrectly, you can re-" +"configure it, as follows:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:326 ../launch-instance-nova.rst:290 +msgid "" +"If your environment includes the Block Storage service, you can attach a " +"volume to the instance." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:319 ../launch-instance-nova.rst:283 +msgid "" +"If your host does not contain the public/private key pair created in an " +"earlier step, SSH prompts for the default password associated with the " +"``cirros`` user." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:411 ../launch-instance-nova.rst:375 +msgid "" +"If your instance does not launch or seem to work as you expect, see the " +"`OpenStack Operations Guide `__ for more " +"information or use one of the :doc:`many other options ` " +"to seek assistance. We want your environment to work!" +msgstr "" + +#: ../cinder-storage-node.rst:158 +msgid "" +"If your storage nodes use LVM on the operating system disk, you must also " +"add the associated device to the filter. For example, if the :file:`/dev/" +"sda` device contains the operating system:" +msgstr "" + +#: ../cinder-storage-node.rst:120 +msgid "" +"If your system uses a different device name, adjust these steps accordingly." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:180 ../launch-instance-nova.rst:199 +msgid "" +"If your web browser runs on a host that cannot resolve the ``controller`` " +"host name, you can replace ``controller`` with the IP address of the " +"management interface on your controller node." +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:22 ../neutron-network-node.rst:21 +msgid "Implement the changes:" +msgstr "" + +#: ../debconf/debconf-concepts.rst:69 +msgid "" +"In ``debconf``, the higher the priority for a screen, the greater the chance " +"that the user sees that screen. If a ``debconf`` screen has ``medium`` " +"priority and you configure the Debian system to show only ``critical`` " +"prompts, which is the default in Debian, the user does not see that " +"``debconf`` screen. Instead, the default for the related package is used. In " +"the Debian OpenStack packages, a number of ``debconf`` screens are set with " +"``medium`` priority. Consequently, if you want to respond to all ``debconf`` " +"screens from the Debian OpenStack packages, you must run the following " +"command and select the ``medium`` priority before you install any packages:" +msgstr "" + +#: ../neutron-concepts.rst:31 +msgid "" +"In addition to external networks, any Networking set up has one or more " +"internal networks. These software-defined networks connect directly to the " +"VMs. Only the VMs on any given internal network, or those on subnets " +"connected through interfaces to a similar router, can access VMs connected " +"to that network directly." +msgstr "" + +#: ../cinder-verify.rst:16 +msgid "" +"In each client environment script, configure the Block Storage client to use " +"API version 2.0:" +msgstr "" + +#: ../glance-verify.rst:16 +msgid "" +"In each client environment script, configure the Image service client to use " +"API version 2.0:" +msgstr "" + +#: ../nova-compute-install.rst:69 +msgid "" +"In the ``[DEFAULT]`` and [oslo_messaging_rabbit] sections, configure " +"``RabbitMQ`` message queue access:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:385 ../cinder-controller-node.rst:237 +#: ../cinder-storage-node.rst:239 ../nova-compute-install.rst:88 +#: ../nova-controller-install.rst:193 +msgid "" +"In the ``[DEFAULT]`` and ``[keystone_authtoken]`` sections, configure " +"Identity service access:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:366 ../ceilometer-nova.rst:50 +#: ../cinder-controller-node.rst:219 ../cinder-storage-node.rst:221 +#: ../heat-install.rst:252 ../nova-controller-install.rst:175 +msgid "" +"In the ``[DEFAULT]`` and ``[oslo_messaging_rabbit]`` sections, configure " +"``RabbitMQ`` message queue access:" +msgstr "" + +#: ../heat-install.rst:309 +msgid "" +"In the ``[DEFAULT]`` section, configure information about the heat Identity " +"service domain:" +msgstr "" + +#: ../ceilometer-glance.rst:13 +msgid "" +"In the ``[DEFAULT]`` section, configure notifications and RabbitMQ message " +"broker access:" +msgstr "" + +#: ../ceilometer-cinder.rst:15 +msgid "In the ``[DEFAULT]`` section, configure notifications:" +msgstr "" + +#: ../nova-controller-install.rst:230 +msgid "" +"In the ``[DEFAULT]`` section, configure the VNC proxy to use the management " +"interface IP address of the controller node:" +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:265 ../nova-controller-install.rst:221 +msgid "" +"In the ``[DEFAULT]`` section, configure the ``my_ip`` option to use the " +"management interface IP address of the controller node:" +msgstr "" + +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-storage-node.rst:267 ../nova-compute-install.rst:117 +msgid "In the ``[DEFAULT]`` section, configure the ``my_ip`` option:" +msgstr "" + +#: ../glance-install.rst:222 ../glance-install.rst:290 +msgid "" +"In the ``[DEFAULT]`` section, configure the ``noop`` notification driver to " +"disable notifications because they only pertain to the optional Telemetry " +"service:" +msgstr "" + +#: ../cinder-storage-node.rst:323 +msgid "" +"In the ``[DEFAULT]`` section, configure the location of the Image service:" +msgstr "" + +#: ../heat-install.rst:298 +msgid "" +"In the ``[DEFAULT]`` section, configure the metadata and wait condition URLs:" +msgstr "" + +#: ../neutron-network-node.rst:370 +msgid "In the ``[DEFAULT]`` section, configure the metadata host:" +msgstr "" + +#: ../neutron-network-node.rst:378 +msgid "" +"In the ``[DEFAULT]`` section, configure the metadata proxy shared secret:" +msgstr "" + +#: ../nova-compute-install.rst:131 +msgid "" +"In the ``[DEFAULT]`` section, enable and configure remote console access:" +msgstr "" + +#: ../cinder-storage-node.rst:310 +msgid "In the ``[DEFAULT]`` section, enable the LVM back end:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:216 ../neutron-network-node.rst:230 +msgid "In the ``[agent]`` section, enable GRE tunnels:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:352 ../cinder-controller-node.rst:208 +#: ../cinder-storage-node.rst:210 ../glance-install.rst:170 +#: ../glance-install.rst:249 ../heat-install.rst:240 +msgid "In the ``[database]`` section, configure database access:" +msgstr "" + +#: ../ceilometer-swift.rst:75 +msgid "In the ``[filter:ceilometer]`` section, configure notifications:" +msgstr "" + +#: ../ceilometer-swift.rst:56 +msgid "" +"In the ``[filter:keystoneauth]`` section, add the ``ResellerAdmin`` role:" +msgstr "" + +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../nova-compute-install.rst:162 ../nova-controller-install.rst:240 +msgid "" +"In the ``[glance]`` section, configure the location of the Image service:" +msgstr "" + +#: ../glance-install.rst:211 +msgid "" +"In the ``[glance_store]`` section, configure the local file system store and " +"location of image files:" +msgstr "" + +#: ../heat-install.rst:271 +msgid "" +"In the ``[keystone_authtoken]`` and ``[ec2authtoken]`` sections, configure " +"Identity service access:" +msgstr "" + +#: ../glance-install.rst:182 ../glance-install.rst:261 +msgid "" +"In the ``[keystone_authtoken]`` and ``[paste_deploy]`` sections, configure " +"Identity service access:" +msgstr "" + +#: ../ceilometer-nova.rst:69 +msgid "" +"In the ``[keystone_authtoken]`` section, configure Identity service access:" +msgstr "" + +#: ../neutron-network-node.rst:187 +msgid "" +"In the ``[ml2_type_flat]`` section, configure the external flat provider " +"network:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:184 ../neutron-controller-node.rst:314 +#: ../neutron-network-node.rst:196 +msgid "" +"In the ``[ml2_type_gre]`` section, configure the tunnel identifier (id) " +"range:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:271 ../neutron-controller-node.rst:359 +msgid "In the ``[neutron]`` section, configure access parameters:" +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:274 ../cinder-storage-node.rst:332 +msgid "In the ``[oslo_concurrency]`` section, configure the lock path:" +msgstr "" + +#: ../neutron-compute-node.rst:204 +msgid "" +"In the ``[ovs]`` section, enable tunnels and configure the local tunnel " +"endpoint:" +msgstr "" + +#: ../neutron-network-node.rst:216 +msgid "" +"In the ``[ovs]`` section, enable tunnels, configure the local tunnel " +"endpoint, and map the external flat provider network to the ``br-ex`` " +"external network bridge:" +msgstr "" + +#: ../ceilometer-swift.rst:66 +msgid "In the ``[pipeline:main]`` section, add ``ceilometer``:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:428 ../ceilometer-nova.rst:38 +msgid "In the ``[publisher]`` section, configure the telemetry secret:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:193 ../neutron-network-node.rst:205 +msgid "" +"In the ``[securitygroup]`` section, enable security groups, enable :term:" +"`ipset`, and configure the OVS :term:`iptables` firewall driver:" +msgstr "" + +#: ../neutron-controller-node.rst:323 +msgid "" +"In the ``[securitygroup]`` section, enable security groups, enable ipset, " +"and configure the OVS iptables firewall driver:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:411 ../ceilometer-nova.rst:92 +msgid "" +"In the ``[service_credentials]`` section, configure service credentials:" +msgstr "" + +#: ../cinder-storage-node.rst:143 +msgid "" +"In the ``devices`` section, add a filter that accepts the :file:`/dev/sdb` " +"device and rejects all other devices::" +msgstr "" + +# #-#-#-#-# dashboard-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../dashboard-install.rst:3 ../glance-install.rst:3 +#: ../keystone-install.rst:3 +msgid "Install and configure" +msgstr "" + +#: ../swift-storage-node.rst:64 +msgid "" +"Install and configure :term:`NTP ` using the " +"instructions in :doc:`basics-ntp`." +msgstr "" + +#: ../cinder-storage-node.rst:45 +msgid "" +"Install and configure :term:`NTP ` using the " +"instructions in :ref:`the section called \"Other nodes\" `." +msgstr "" + +#: ../cinder-storage-node.rst:177 +msgid "Install and configure Block Storage volume components" +msgstr "" + +#: ../heat-install.rst:3 +msgid "Install and configure Orchestration" +msgstr "" + +#: ../nova-compute-install.rst:2 +msgid "Install and configure a compute node" +msgstr "" + +#: ../cinder-storage-node.rst:3 +msgid "Install and configure a storage node" +msgstr "" + +#: ../neutron-compute-node.rst:3 +msgid "Install and configure compute node" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:3 ../cinder-controller-node.rst:3 +#: ../neutron-controller-node.rst:3 ../nova-controller-install.rst:2 +msgid "Install and configure controller node" +msgstr "" + +#: ../neutron-network-node.rst:3 +msgid "Install and configure network node" +msgstr "" + +#: ../swift-storage-node.rst:180 +msgid "Install and configure storage node components" +msgstr "" + +#: ../swift-controller-node.rst:3 +msgid "Install and configure the controller node" +msgstr "" + +#: ../swift-storage-node.rst:3 +msgid "Install and configure the storage nodes" +msgstr "" + +#: ../basics-packages.rst:413 +msgid "Install the package:" +msgstr "" + +# #-#-#-#-# basics-packages.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-packages.rst:260 ../swift-controller-node.rst:116 +#: ../swift-storage-node.rst:193 +msgid "Install the packages:" +msgstr "" + +#: ../swift-storage-node.rst:67 +msgid "Install the supporting utility packages:" +msgstr "" + +#: ../basics-networking-neutron.rst:26 +msgid "Instance tunnels on 10.0.1.0/24 without a gateway" +msgstr "" + +#: ../networking-neutron.rst:19 +msgid "It includes the following components:" +msgstr "" + +#: ../neutron-network-node.rst:338 +msgid "Kill any existing dnsmasq processes:" +msgstr "" + +#: ../launch-instance.rst:3 +msgid "Launch an instance" +msgstr "" + +#: ../launch-instance.rst:20 +msgid "" +"Launch an instance using :doc:`OpenStack Networking (neutron) ` or :doc:`legacy networking (nova-network) `. For more information, see the `OpenStack User Guide `__." +msgstr "" + +#: ../launch-instance-neutron.rst:3 +msgid "Launch an instance with OpenStack Networking (neutron)" +msgstr "" + +#: ../launch-instance-nova.rst:3 +msgid "Launch an instance with legacy networking (nova-network)" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:110 ../launch-instance-nova.rst:129 +msgid "Launch the instance:" +msgstr "" + +#: ../overview.rst:113 +msgid "" +"Launching a virtual machine or instance involves many interactions among " +"several services. The following diagram provides the conceptual architecture " +"of a typical OpenStack environment." +msgstr "" + +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-nova.rst:5 ../networking-nova.rst:3 +msgid "Legacy networking (nova-network)" +msgstr "" + +#: ../networking-nova.rst:7 +msgid "" +"Legacy networking primarily involves compute nodes. However, you must " +"configure the controller node to use legacy networking." +msgstr "" + +#: ../neutron-initial-networks.rst:63 +msgid "" +"Like a physical network, a virtual network requires a :term:`subnet` " +"assigned to it. The external network shares the same subnet and :term:" +"`gateway` associated with the physical network connected to the external " +"interface on the network node. You should specify an exclusive slice of this " +"subnet for :term:`router` and floating IP addresses to prevent interference " +"with other devices on the external network." +msgstr "" + +#: ../neutron-initial-networks.rst:158 +msgid "" +"Like the external network, your tenant network also requires a subnet " +"attached to it. You can specify any valid subnet because the architecture " +"isolates tenant networks. By default, this subnet uses DHCP so your " +"instances can obtain IP addresses." +msgstr "" + +#: ../nova-verify.rst:40 +msgid "" +"List API endpoints in the Identity service to verify connectivity with the " +"Identity service:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:378 ../neutron-network-node.rst:567 +msgid "List agents to verify successful launch of the neutron agents:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:44 ../launch-instance-nova.rst:55 +msgid "List available flavors:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:65 ../launch-instance-nova.rst:76 +msgid "List available images:" +msgstr "" + +#: ../ceilometer-verify.rst:39 +msgid "" +"List available meters again to validate detection of the image download:" +msgstr "" + +#: ../ceilometer-verify.rst:18 +msgid "List available meters:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:78 ../launch-instance-nova.rst:89 +msgid "List available networks:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:93 ../launch-instance-nova.rst:112 +msgid "List available security groups:" +msgstr "" + +#: ../swift-verify.rst:44 +msgid "List containers:" +msgstr "" + +#: ../nova-verify.rst:130 +msgid "" +"List images in the Image service catalog to verify connectivity with the " +"Image service:" +msgstr "" + +#: ../neutron-controller-node.rst:480 +msgid "" +"List loaded extensions to verify successful launch of the ``neutron-server`` " +"process:" +msgstr "" + +#: ../nova-verify.rst:18 +msgid "" +"List service components to verify successful launch and registration of each " +"process:" +msgstr "" + +#: ../cinder-verify.rst:30 +msgid "List service components to verify successful launch of each process:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:335 ../launch-instance-neutron.rst:364 +#: ../launch-instance-nova.rst:299 ../launch-instance-nova.rst:328 +msgid "List volumes:" +msgstr "" + +#: ../keystone-openrc.rst:60 +msgid "" +"Load the :file:`admin-openrc.sh` file to populate environment variables with " +"the location of the Identity service and the ``admin`` project and user " +"credentials:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:18 ../basics-networking-nova.rst:15 +msgid "Management on 10.0.0.0/24 with gateway 10.0.0.1" +msgstr "" + +#: ../overview.rst:33 +msgid "" +"Manages the lifecycle of compute instances in an OpenStack environment. " +"Responsibilities include spawning, scheduling and decommissioning of virtual " +"machines on demand." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:5 +msgid "" +"Many of the OpenStack services need to be configured to access a database. " +"These are configured through a DSN (Database Source Name) directive as " +"follows:" +msgstr "" + +#: ../basic_environment.rst:72 +msgid "" +"Many users build their test environment on a :term:`virtual machine (VM)`. " +"The primary benefits of VMs include the following:" +msgstr "" + +#: ../basics-packages.rst:398 +msgid "Message queue" +msgstr "" + +#: ../networking-neutron.rst:39 +msgid "Messaging queue" +msgstr "" + +#: ../overview.rst:77 +msgid "" +"Monitors and meters the OpenStack cloud for billing, benchmarking, " +"scalability, and statistical purposes." +msgstr "" + +#: ../basics-packages.rst:251 +msgid "" +"Most OpenStack services use an SQL database to store information. The " +"database typically runs on the controller node. The procedures in this guide " +"use MariaDB or MySQL depending on the distribution. OpenStack services also " +"support other SQL databases including `PostgreSQL `__." +msgstr "" + +#: ../launch-instance-neutron.rst:8 +msgid "" +"Most cloud images support :term:`public key authentication` rather than " +"conventional user name/password authentication. Before launching an " +"instance, you must generate a public/private key pair." +msgstr "" + +#: ../launch-instance-nova.rst:8 +msgid "" +"Most cloud images support :term:`public key authentication` rather than " +"conventional user name/password authentication. Before launching an " +"instance, you must you must generate a public/private key pair using :" +"command:`ssh-keygen` and add the public key to your OpenStack environment." +msgstr "" + +#: ../swift-storage-node.rst:109 +msgid "Mount the devices:" +msgstr "" + +#: ../app_reserved_uids.rst:19 +msgid "Name" +msgstr "" + +#: ../basic_environment.rst:54 +msgid "Network Node: 1 processor, 512 MB memory, and 5 GB storage" +msgstr "" + +#: ../basics-ntp.rst:6 +msgid "Network Time Protocol (NTP)" +msgstr "" + +#: ../basics-networking-nova.rst:35 +msgid "" +"Network interface names vary by distribution. Traditionally, interfaces use " +"\"eth\" followed by a sequential number. To cover all variations, this guide " +"simply refers to the first interface as the interface with the lowest number " +"and the second interface as the interface with the highest number." +msgstr "" + +#: ../basics-networking-neutron.rst:46 +msgid "" +"Network interface names vary by distribution. Traditionally, interfaces use " +"\"eth\" followed by a sequential number. To cover all variations, this guide " +"simply refers to the first interface as the interface with the lowest " +"number, the second interface as the interface with the middle number, and " +"the third interface as the interface with the highest number." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:88 ../basics-networking-neutron.rst:133 +#: ../basics-networking-neutron.rst:141 ../basics-networking-neutron.rst:230 +#: ../basics-networking-neutron.rst:242 ../basics-networking-nova.rst:76 +#: ../basics-networking-nova.rst:118 ../cinder-storage-node.rst:30 +msgid "Network mask: 255.255.255.0 (or /24)" +msgstr "" + +#: ../swift-storage-node.rst:32 ../swift-storage-node.rst:42 +msgid "Network mask: ``255.255.255.0`` (or ``/24``)" +msgstr "" + +#: ../basics-networking-neutron.rst:125 +msgid "Network node" +msgstr "" + +#: ../basics-networking.rst:3 +msgid "Networking" +msgstr "" + +#: ../neutron-concepts.rst:3 +msgid "Networking (neutron) concepts" +msgstr "" + +#: ../neutron-concepts.rst:50 +msgid "" +"Networking also supports *security groups*. Security groups enable " +"administrators to define firewall rules in groups. A VM can belong to one or " +"more security groups, and Networking applies the rules in those security " +"groups to block or unblock ports, port ranges, or traffic types for that VM." +msgstr "" + +#: ../neutron-concepts.rst:13 +msgid "" +"Networking provides the networks, subnets, and routers object abstractions. " +"Each abstraction has functionality that mimics its physical counterpart: " +"networks contain subnets, and routers route traffic between different subnet " +"and networks." +msgstr "" + +#: ../basic_environment.rst:194 +msgid "Networking, NTP, OpenStack service dependencies" +msgstr "" + +# #-#-#-#-# ceilometer-next-steps.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-next-steps.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# dashboard-next-step.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-next-step.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# networking-next-steps.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-next-steps.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-next-steps.rst:3 ../cinder-next-steps.rst:3 +#: ../dashboard-next-step.rst:3 ../heat-next-step.rst:3 +#: ../networking-next-steps.rst:3 ../swift-next-steps.rst:3 +msgid "Next steps" +msgstr "" + +#: ../swift-initial-rings.rst:175 +msgid "Object ring" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:166 ../launch-instance-nova.rst:185 +msgid "" +"Obtain a :term:`Virtual Network Computing (VNC)` session URL for your " +"instance and access it from a web browser:" +msgstr "" + +#: ../neutron-network-node.rst:398 +msgid "" +"On the *controller* node, open the :file:`/etc/nova/nova.conf` file and edit " +"the ``[neutron]`` section to enable the metadata proxy and configure the " +"secret:" +msgstr "" + +#: ../neutron-network-node.rst:412 +msgid "On the *controller* node, restart the Compute :term:`API` service:" +msgstr "" + +#: ../neutron-initial-networks.rst:33 +msgid "" +"On the controller node, source the ``admin`` credentials to gain access to " +"admin-only CLI commands:" +msgstr "" + +#: ../networking-nova.rst:136 +msgid "On the controller node, source the ``admin`` tenant credentials:" +msgstr "" + +#: ../neutron-initial-networks.rst:132 +msgid "" +"On the controller node, source the ``demo`` credentials to gain access to " +"user-only CLI commands:" +msgstr "" + +#: ../basic_environment.rst:76 +msgid "" +"One physical server can support multiple nodes, each with almost any number " +"of network interfaces." +msgstr "" + +#: ../cinder-storage-node.rst:132 +msgid "" +"Only instances can access Block Storage volumes. However, the underlying " +"operating system manages the devices associated with the volumes. By " +"default, the LVM volume scanning tool scans the :file:`/dev` directory for " +"block storage devices that contain volumes. If projects use LVM on their " +"volumes, the scanning tool detects these volumes and attempts to cache them " +"which can cause a variety of problems with both the underlying operating " +"system and project volumes. You must reconfigure LVM to scan only the " +"devices that contain the ``cinder-volume`` volume group. Edit the :file:`/" +"etc/lvm/lvm.conf` file and complete the following actions:" +msgstr "" + +#: ../neutron-network-node.rst:272 +msgid "" +"Open the :file:`/etc/neutron/dhcp_agent.ini` file and edit the ``[DEFAULT]`` " +"section, configure the interface and DHCP drivers and enable deletion of " +"defunct DHCP namespaces:" +msgstr "" + +#: ../neutron-network-node.rst:322 +msgid "" +"Open the :file:`/etc/neutron/dhcp_agent.ini` file and edit the ``[DEFAULT]`` " +"section. Enable the :term:`dnsmasq` configuration file:" +msgstr "" + +#: ../neutron-network-node.rst:242 +msgid "" +"Open the :file:`/etc/neutron/l3_agent.ini` file edit the ``[DEFAULT]`` " +"section. Configure the interface driver, external network bridge, and enable " +"deletion of defunct router namespaces:" +msgstr "" + +#: ../neutron-network-node.rst:349 +msgid "" +"Open the :file:`/etc/neutron/metadata_agent.ini` file and edit the " +"``[DEFAULT]`` section, configure access parameters:" +msgstr "" + +#: ../neutron-controller-node.rst:296 +msgid "" +"Open the :file:`/etc/neutron/plugins/ml2/ml2_conf.ini` file and edit the " +"``[ml2]`` section, to enable the flat, VLAN, generic routing encapsulation " +"(GRE), and virtual extensible LAN (VXLAN) network type drivers, GRE tenant " +"networks, and the OVS mechanism driver:" +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:170 ../neutron-network-node.rst:173 +msgid "" +"Open the :file:`/etc/neutron/plugins/ml2/ml2_conf.ini` file and edit the " +"``[ml2]`` section. Enable the :term:`flat `, :term:`VLAN `, :term:`generic routing encapsulation (GRE)`, and :term:`virtual " +"extensible LAN (VXLAN)` network type drivers, GRE tenant networks, and the " +"OVS mechanism driver:" +msgstr "" + +#: ../neutron-compute-node.rst:252 +msgid "" +"Open the :file:`/etc/nova/nova.conf` file and edit the ``[DEFAULT]`` " +"section. Configure the :term:`APIs ` and drivers:" +msgstr "" + +#: ../networking-nova.rst:12 +msgid "" +"Open the :file:`/etc/nova/nova.conf` file and edit the ``[DEFAULT]`` " +"section. Configure the network and security group APIs:" +msgstr "" + +#: ../networking-nova.rst:74 +msgid "" +"Open the :file:`/etc/nova/nova.conf` file and edit the ``[DEFAULT]`` " +"section. Configure the network parameters:" +msgstr "" + +#: ../neutron-controller-node.rst:340 +msgid "" +"Open the :file:`/etc/nova/nova.conf` file on the controller node and edit " +"the ``[DEFAULT]`` section to configure the APIs and drivers:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:5 ../networking-neutron.rst:3 +msgid "OpenStack Networking (neutron)" +msgstr "" + +#: ../neutron-concepts.rst:5 +msgid "" +"OpenStack Networking (neutron) manages all networking facets for the Virtual " +"Networking Infrastructure (VNI) and the access layer aspects of the Physical " +"Networking Infrastructure (PNI) in your OpenStack environment. OpenStack " +"Networking enables tenants to create advanced virtual network topologies " +"which may inlude services such as a :term:`firewall`, a :term:`load " +"balancer`, and a :term:`virtual private network (VPN)`." +msgstr "" + +#: ../networking-neutron.rst:13 +msgid "" +"OpenStack Networking allows you to create and attach interface devices " +"managed by other OpenStack services to networks. Plug-ins can be implemented " +"to accommodate different networking equipment and software, providing " +"flexibility to OpenStack architecture and deployment." +msgstr "" + +#: ../networking-neutron.rst:41 +msgid "" +"OpenStack Networking mainly interacts with OpenStack Compute to provide " +"networks and connectivity for its instances." +msgstr "" + +#: ../networking-neutron.rst:34 +msgid "OpenStack Networking plug-ins and agents" +msgstr "" + +#: ../basic_environment.rst:176 +msgid "" +"OpenStack and supporting services require administrative privileges during " +"installation and operation. In some cases, services perform modifications to " +"the host that can interfere with deployment automation tools such as " +"Ansible, Chef, and Puppet. For example, some OpenStack services add a root " +"wrapper to ``sudo`` that can interfere with security policies. See the " +"`Cloud Administrator Guide `__ for more information." +msgstr "" + +#: ../app_reserved_uids.rst:23 +msgid "OpenStack ceilometer daemons" +msgstr "" + +#: ../app_reserved_uids.rst:32 +msgid "OpenStack cinder daemons" +msgstr "" + +# #-#-#-#-# glance-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-services.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-users.pot (Installation Guide 0.1) #-#-#-#-# +#: ../glance-verify.rst:88 ../keystone-services.rst:85 +#: ../keystone-users.rst:43 +msgid "" +"OpenStack generates IDs dynamically, so you will see different values in the " +"example command output." +msgstr "" + +#: ../app_reserved_uids.rst:41 +msgid "OpenStack glance daemons" +msgstr "" + +#: ../app_reserved_uids.rst:50 +msgid "OpenStack heat daemons" +msgstr "" + +#: ../overview.rst:131 +msgid "" +"OpenStack is highly configurable to meet different needs with various " +"compute, networking, and storage options. This guide enables you to choose " +"your own OpenStack adventure using a combination of core and optional " +"services. This guide uses the following example architectures:" +msgstr "" + +#: ../app_reserved_uids.rst:59 +msgid "OpenStack keystone daemons" +msgstr "" + +#: ../app_reserved_uids.rst:68 +msgid "OpenStack neutron daemons" +msgstr "" + +#: ../app_reserved_uids.rst:77 +msgid "OpenStack nova daemons" +msgstr "" + +#: ../basics-packages.rst:9 +msgid "OpenStack packages" +msgstr "" + +#: ../overview.rst:13 +msgid "" +"OpenStack provides an :term:`Infrastructure-as-a-Service (IaaS)` " +"solution through a variety of complemental services. Each service offers an :" +"term:`application programming interface (API)` that facilitates this " +"integration. The following table provides a list of OpenStack services:" +msgstr "" + +#: ../app_reserved_uids.rst:5 +msgid "" +"OpenStack reserves certain user IDs to run specific services and own " +"specific files. These user IDs are set up according to the distribution " +"packages. The following table gives an overview." +msgstr "" + +#: ../basics-packages.rst:6 +msgid "OpenStack service dependencies" +msgstr "" + +#: ../basic_environment.rst:100 +msgid "" +"OpenStack services support various security methods including password, " +"policy, and encryption. Additionally, supporting services including the " +"database server and message broker support at least password security." +msgstr "" + +#: ../app_reserved_uids.rst:86 +msgid "OpenStack swift daemons" +msgstr "" + +#: ../app_reserved_uids.rst:95 +msgid "OpenStack trove daemons" +msgstr "" + +#: ../basics-packages.rst:400 +msgid "" +"OpenStack uses a :term:`message queue` to coordinate operations and status " +"information among services. The message queue service typically runs on the " +"controller node. OpenStack supports several message queue services including " +"`RabbitMQ `__, `Qpid `__, " +"and `ZeroMQ `__. However, most distributions that package " +"OpenStack support a particular message queue service. This guide implements " +"the RabbitMQ message queue service because most distributions support it. If " +"you prefer to implement a different message queue service, consult the " +"documentation associated with it." +msgstr "" + +#: ../keystone-services.rst:92 +msgid "" +"OpenStack uses three API endpoint variants for each service: admin, " +"internal, and public. The admin API endpoint allows modifying users and " +"tenants by default, while the public and internal APIs do not. In a " +"production environment, the variants might reside on separate networks that " +"service different types of users for security reasons. For instance, the " +"public API network might be reachable from outside the cloud for management " +"tools, the admin API network might be protected, while the internal API " +"network is connected to each host. Also, OpenStack supports multiple regions " +"for scalability. For simplicity, this guide uses the management network for " +"all endpoint variations and the default ``RegionOne`` region." +msgstr "" + +#: ../dashboard-install.rst:115 +msgid "Optionally, configure the time zone::" +msgstr "" + +#: ../overview.rst:174 ../overview.rst:257 +msgid "" +"Optionally, the Block Storage node runs a Telemetry agent to collect meters. " +"Also, it can contain a second network interface on a separate storage " +"network to improve performance of storage services." +msgstr "" + +#: ../overview.rst:165 ../overview.rst:248 +msgid "" +"Optionally, the compute node runs a Telemetry agent to collect meters. Also, " +"it can contain a third network interface on a separate storage network to " +"improve performance of storage services." +msgstr "" + +#: ../overview.rst:145 ../overview.rst:235 +msgid "" +"Optionally, the controller node runs portions of Block Storage, Object " +"Storage, Orchestration, Telemetry, Database, and Data processing services. " +"These components provide additional features for your environment." +msgstr "" + +#: ../overview.rst:184 ../overview.rst:267 +msgid "" +"Optionally, these nodes can contain a second network interface on a separate " +"storage network to improve performance of storage services." +msgstr "" + +#: ../overview.rst:84 +msgid "" +"Orchestrates multiple composite cloud applications by using either the " +"native :term:`HOT ` template format or " +"the AWS CloudFormation template format, through both an OpenStack-native " +"REST API and a CloudFormation-compatible Query API." +msgstr "" + +#: ../basics-ntp.rst:92 +msgid "Other nodes" +msgstr "" + +#: ../overview.rst:6 +msgid "Overview" +msgstr "" + +#: ../basic_environment.rst:125 +msgid "Password name" +msgstr "" + +#: ../basic_environment.rst:138 +msgid "Password of Block Storage service user ``cinder``" +msgstr "" + +#: ../basic_environment.rst:162 +msgid "Password of Compute service user ``nova``" +msgstr "" + +#: ../basic_environment.rst:172 +msgid "Password of Database service user ``trove``" +msgstr "" + +#: ../basic_environment.rst:146 +msgid "Password of Image service user ``glance``" +msgstr "" + +#: ../basic_environment.rst:158 +msgid "Password of Networking service user ``neutron``" +msgstr "" + +#: ../basic_environment.rst:168 +msgid "Password of Object Storage service user ``swift``" +msgstr "" + +#: ../basic_environment.rst:150 +msgid "Password of Orchestration domain" +msgstr "" + +#: ../basic_environment.rst:152 +msgid "Password of Orchestration service user ``heat``" +msgstr "" + +#: ../basic_environment.rst:134 +msgid "Password of Telemetry service user ``ceilometer``" +msgstr "" + +#: ../basic_environment.rst:130 +msgid "Password of user ``admin``" +msgstr "" + +#: ../basic_environment.rst:142 +msgid "Password of user ``demo``" +msgstr "" + +#: ../basic_environment.rst:164 +msgid "Password of user guest of RabbitMQ" +msgstr "" + +#: ../neutron-controller-node.rst:471 +msgid "Perform the following commands on the controller node." +msgstr "" + +#: ../neutron-compute-node.rst:369 +msgid "Perform the following commands on the controller node:" +msgstr "" + +# #-#-#-#-# cinder-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-verify.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-verify.rst:14 ../nova-verify.rst:9 +msgid "Perform these commands on the controller node." +msgstr "" + +#: ../swift-storage-node.rst:191 +msgid "Perform these steps on each storage node." +msgstr "" + +#: ../ceilometer-swift.rst:50 +msgid "" +"Perform these steps on the controller and any other nodes that run the " +"Object Storage proxy service." +msgstr "" + +# #-#-#-#-# ceilometer-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-verify.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-verify.rst:9 ../swift-verify.rst:12 +msgid "Perform these steps on the controller node." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:227 ../launch-instance-nova.rst:231 +msgid "Permit :term:`ICMP` (ping):" +msgstr "" + +#: ../basics-packages.rst:456 +msgid "" +"Permit configuration, write, and read access for the ``openstack`` user:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:238 ../launch-instance-nova.rst:242 +msgid "Permit secure shell (SSH) access:" +msgstr "" + +#: ../networking-neutron.rst:26 +msgid "" +"Plugs and unplugs ports, creates networks or subnets, and provides IP " +"addressing. These plug-ins and agents differ depending on the vendor and " +"technologies used in the particular cloud. OpenStack Networking ships with " +"plug-ins and agents for Cisco virtual and physical switches, NEC OpenFlow " +"products, Open vSwitch, Linux bridging, and the VMware NSX product." +msgstr "" + +#: ../cinder-controller-node.rst:291 +msgid "Populate the Block Storage database:" +msgstr "" + +#: ../heat-install.rst:354 +msgid "Populate the Orchestration database:" +msgstr "" + +#: ../debconf/debconf-concepts.rst:95 +msgid "Pre-seed debconf prompts" +msgstr "" + +#: ../overview.rst:23 +msgid "Project name" +msgstr "" + +#: ../dashboard-next-step.rst:12 +msgid "" +"Provide users with a public IP address, a username, and a password so they " +"can access the dashboard through a web browser. In case of any SSL " +"certificate connection problems, point the server IP address to a domain " +"name, and give users access." +msgstr "" + +#: ../overview.rst:27 +msgid "" +"Provides a web-based self-service portal to interact with underlying " +"OpenStack services, such as launching an instance, assigning IP addresses " +"and configuring access controls." +msgstr "" + +#: ../overview.rst:67 +msgid "" +"Provides an authentication and authorization service for other OpenStack " +"services. Provides a catalog of endpoints for all OpenStack services." +msgstr "" + +#: ../overview.rst:97 +msgid "" +"Provides capabilties to provision and scale Hadoop clusters in OpenStack by " +"specifying parameters like Hadoop version, cluster topology and nodes " +"hardware details." +msgstr "" + +#: ../overview.rst:59 +msgid "" +"Provides persistent block storage to running instances. Its pluggable driver " +"architecture facilitates the creation and management of block storage " +"devices." +msgstr "" + +#: ../overview.rst:91 +msgid "" +"Provides scalable and reliable Cloud Database-as-a-Service functionality for " +"both relational and non-relational database engines." +msgstr "" + +#: ../debconf/debconf-rabbitmq.rst:3 +msgid "RabbitMQ credentials parameters" +msgstr "" + +#: ../swift-initial-rings.rst:86 ../swift-initial-rings.rst:167 +#: ../swift-initial-rings.rst:245 +msgid "Rebalance the ring:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:92 ../basics-networking-neutron.rst:189 +#: ../basics-networking-neutron.rst:248 ../basics-networking-nova.rst:80 +#: ../basics-networking-nova.rst:172 +msgid "Reboot the system to activate the changes." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:73 ../basics-networking-nova.rst:61 +msgid "" +"Reconfiguring network interfaces will interrupt network connectivity. We " +"recommend using a local terminal session for these procedures." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:3 +msgid "Register API endpoints" +msgstr "" + +#: ../keystone-users.rst:113 +msgid "" +"Regular (non-admin) tasks should use an unprivileged project and user. As an " +"example, this guide creates the ``demo`` project and user." +msgstr "" + +#: ../ceilometer-verify.rst:67 +msgid "Remove the previously downloaded image file :file:`/tmp/cirros.img`:" +msgstr "" + +#: ../glance-verify.rst:102 +msgid "Remove the temporary local directory and source image:" +msgstr "" + +#: ../swift-initial-rings.rst:53 ../swift-initial-rings.rst:134 +#: ../swift-initial-rings.rst:212 +msgid "" +"Repeat this command for each storage device on each storage node. In the " +"example architecture, use the command in four variations:" +msgstr "" + +#: ../ceilometer-controller-install.rst:437 +msgid "" +"Replace TELEMETRY_SECRET with the telemetry secret that you generated in a " +"previous step." +msgstr "" + +#: ../basics-packages.rst:454 +msgid "Replace `RABBIT_PASS` with a suitable password." +msgstr "" + +#: ../keystone-openrc.rst:34 +msgid "" +"Replace ``ADMIN_PASS`` with the password you chose for the ``admin`` user in " +"the Identity service." +msgstr "" + +#: ../ceilometer-controller-install.rst:361 +msgid "" +"Replace ``CEILOMETER_DBPASS`` with the password you chose for the Telemetry " +"module database. You must escape special characters such as ':', '/', '+', " +"and '@' in the connection string in accordance with RFC2396." +msgstr "" + +#: ../ceilometer-nova.rst:83 +msgid "" +"Replace ``CEILOMETER_PASS`` with the password you chose for the Telemetry " +"module database." +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:403 +#: ../ceilometer-controller-install.rst:425 ../ceilometer-nova.rst:107 +msgid "" +"Replace ``CEILOMETER_PASS`` with the password you chose for the " +"``ceilometer`` user in the Identity service." +msgstr "" + +#: ../cinder-controller-node.rst:40 +msgid "Replace ``CINDER_DBPASS`` with a suitable password." +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:216 ../cinder-storage-node.rst:218 +msgid "" +"Replace ``CINDER_DBPASS`` with the password you chose for the Block Storage " +"database." +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:257 ../cinder-storage-node.rst:259 +msgid "" +"Replace ``CINDER_PASS`` with the password you chose for the ``cinder`` user " +"in the Identity service." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:112 ../launch-instance-nova.rst:131 +msgid "Replace ``DEMO_NET_ID`` with the ID of the ``demo-net`` tenant network." +msgstr "" + +#: ../keystone-openrc.rst:50 +msgid "" +"Replace ``DEMO_PASS`` with the password you chose for the ``demo`` user in " +"the Identity service." +msgstr "" + +#: ../neutron-initial-networks.rst:84 +msgid "" +"Replace ``EXTERNAL_NETWORK_CIDR`` with the subnet associated with the " +"physical network." +msgstr "" + +#: ../neutron-initial-networks.rst:87 +msgid "" +"Replace ``EXTERNAL_NETWORK_GATEWAY`` with the gateway associated with the " +"physical network, typically the \".1\" IP address." +msgstr "" + +#: ../swift-verify.rst:41 +msgid "" +"Replace ``FILE`` with the name of a local file to upload to the ``demo-" +"container1`` container." +msgstr "" + +#: ../swift-verify.rst:58 +msgid "" +"Replace ``FILE`` with the name of the file uploaded to the ``demo-" +"container1`` container." +msgstr "" + +#: ../neutron-initial-networks.rst:80 +msgid "" +"Replace ``FLOATING_IP_START`` and ``FLOATING_IP_END`` with the first and " +"last IP addresses of the range that you want to allocate for floating IP " +"addresses." +msgstr "" + +#: ../glance-install.rst:47 +msgid "Replace ``GLANCE_DBPASS`` with a suitable password." +msgstr "" + +#: ../glance-install.rst:179 ../glance-install.rst:258 +msgid "" +"Replace ``GLANCE_DBPASS`` with the password you chose for the Image service " +"database." +msgstr "" + +#: ../glance-install.rst:203 ../glance-install.rst:282 +msgid "" +"Replace ``GLANCE_PASS`` with the password you chose for the ``glance`` user " +"in the Identity service." +msgstr "" + +#: ../heat-install.rst:34 +msgid "Replace ``HEAT_DBPASS`` with a suitable password." +msgstr "" + +#: ../heat-install.rst:249 +msgid "" +"Replace ``HEAT_DBPASS`` with the password you chose for the Orchestration " +"database." +msgstr "" + +#: ../heat-install.rst:352 +msgid "Replace ``HEAT_DOMAIN_PASS`` with a suitable password." +msgstr "" + +#: ../heat-install.rst:321 +msgid "" +"Replace ``HEAT_DOMAIN_PASS`` with the password you chose for the admin user " +"of the ``heat`` user domain in the Identity service." +msgstr "" + +#: ../heat-install.rst:289 +msgid "" +"Replace ``HEAT_PASS`` with the password you chose for the ``heat`` user in " +"the Identity service." +msgstr "" + +#: ../neutron-compute-node.rst:213 +msgid "" +"Replace ``INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS`` with the IP address of the " +"instance tunnels network interface on your compute node." +msgstr "" + +#: ../neutron-network-node.rst:227 +msgid "" +"Replace ``INSTANCE_TUNNELS_INTERFACE_IP_ADDRESS`` with the IP address of the " +"instance tunnels network interface on your network node." +msgstr "" + +#: ../networking-nova.rst:96 +msgid "" +"Replace ``INTERFACE_NAME`` with the actual interface name for the external " +"network. For example, *eth1* or *ens224*. You can also leave these two " +"parameters undefined if you are serving multiple networks with individual " +"bridges for each." +msgstr "" + +#: ../basics-networking-nova.rst:130 +msgid "" +"Replace ``INTERFACE_NAME`` with the actual interface name. For example, " +"*eth1* or *ens224*." +msgstr "" + +#: ../basics-networking-neutron.rst:147 +msgid "" +"Replace ``INTERFACE_NAME`` with the actual interface name. For example, " +"*eth2* or *ens256*." +msgstr "" + +#: ../keystone-install.rst:41 +msgid "Replace ``KEYSTONE_DBPASS`` with a suitable password." +msgstr "" + +#: ../nova-compute-install.rst:126 ../nova-compute-install.rst:150 +msgid "" +"Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the " +"management network interface on your compute node, typically 10.0.0.31 for " +"the first node in the :ref:`example architecture `." +msgstr "" + +#: ../cinder-storage-node.rst:275 +msgid "" +"Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the " +"management network interface on your storage node, typically 10.0.0.41 for " +"the first node in the :ref:`example architecture `." +msgstr "" + +#: ../swift-storage-node.rst:145 +msgid "" +"Replace ``MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address of the " +"management network on the storage node." +msgstr "" + +#: ../neutron-network-node.rst:387 +msgid "" +"Replace ``METADATA_SECRET`` with a suitable secret for the metadata proxy." +msgstr "" + +#: ../neutron-network-node.rst:409 +msgid "" +"Replace ``METADATA_SECRET`` with the secret you chose for the metadata proxy." +msgstr "" + +#: ../networking-nova.rst:144 +msgid "" +"Replace ``NETWORK_CIDR`` with the subnet associated with the physical " +"network." +msgstr "" + +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../neutron-compute-node.rst:285 ../neutron-controller-node.rst:373 +#: ../neutron-network-node.rst:367 +msgid "" +"Replace ``NEUTRON_PASS`` with the password you chose for the ``neutron`` " +"user in the Identity service." +msgstr "" + +#: ../nova-controller-install.rst:37 +msgid "Replace ``NOVA_DBPASS`` with a suitable password." +msgstr "" + +#: ../nova-controller-install.rst:172 +msgid "" +"Replace ``NOVA_DBPASS`` with the password you chose for the Compute database." +msgstr "" + +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../nova-compute-install.rst:109 ../nova-controller-install.rst:213 +msgid "" +"Replace ``NOVA_PASS`` with the password you chose for the ``nova`` user in " +"the Identity service." +msgstr "" + +#: ../basics-ntp.rst:55 +msgid "" +"Replace ``NTP_SERVER`` with the hostname or IP address of a suitable more " +"accurate (lower stratum) NTP server. The configuration supports multiple " +"``server`` keys." +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-glance.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-swift.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:382 ../ceilometer-glance.rst:26 +#: ../ceilometer-nova.rst:66 ../ceilometer-swift.rst:89 +#: ../cinder-controller-node.rst:234 ../cinder-storage-node.rst:236 +#: ../heat-install.rst:268 ../nova-compute-install.rst:85 +#: ../nova-controller-install.rst:190 +msgid "" +"Replace ``RABBIT_PASS`` with the password you chose for the ``openstack`` " +"account in ``RabbitMQ``." +msgstr "" + +#: ../swift-initial-rings.rst:42 ../swift-initial-rings.rst:123 +#: ../swift-initial-rings.rst:202 +msgid "" +"Replace ``STORAGE_NODE_MANAGEMENT_INTERFACE_IP_ADDRESS`` with the IP address " +"of the management network on the storage node. Replace ``DEVICE_NAME`` with " +"a storage device name on the same storage node. For example, using the first " +"storage node in :doc:`swift-storage-node` with the :file:`/dev/sdb1` storage " +"device and weight of 100:" +msgstr "" + +#: ../ceilometer-nova.rst:47 +msgid "" +"Replace ``TELEMETRY_SECRET`` with the telemetry secret you chose for the " +"Telemetry module." +msgstr "" + +#: ../neutron-initial-networks.rst:172 +msgid "" +"Replace ``TENANT_NETWORK_CIDR`` with the subnet you want to associate with " +"the tenant network." +msgstr "" + +#: ../neutron-initial-networks.rst:175 +msgid "" +"Replace ``TENANT_NETWORK_GATEWAY`` with the gateway you want to associate " +"with it, typically the \".1\" IP address." +msgstr "" + +#: ../dashboard-install.rst:119 +msgid "" +"Replace ``TIME_ZONE`` with an appropriate time zone identifier. For more " +"information, see the `list of time zones `__." +msgstr "" + +#: ../keystone-openrc.rst:68 +msgid "Request an authentication token:" +msgstr "" + +#: ../networking-nova.rst:22 +msgid "Restart the Compute services:" +msgstr "" + +#: ../ceilometer-verify.rst:56 +msgid "Retrieve usage statistics from the ``image.download`` meter:" +msgstr "" + +#: ../basic_environment.rst:128 +msgid "Root password for the database" +msgstr "" + +#: ../basics-ntp.rst:194 ../basics-ntp.rst:211 +msgid "Run this command on *all other* nodes:" +msgstr "" + +#: ../basics-ntp.rst:163 ../basics-ntp.rst:181 +msgid "Run this command on the *controller* node:" +msgstr "" + +#: ../basics-packages.rst:249 +msgid "SQL database" +msgstr "" + +#: ../index.rst:120 +msgid "Search in this guide" +msgstr "" + +#: ../basic_environment.rst:98 +msgid "Security" +msgstr "" + +#: ../overview.rst:22 +msgid "Service" +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:3 +msgid "Services and the [keystone_authtoken]" +msgstr "" + +#: ../cinder-storage-node.rst:34 +msgid "Set the hostname of the node to ``block1``." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:254 ../basics-networking-nova.rst:178 +msgid "Set the hostname of the node to ``compute1``." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:98 ../basics-networking-nova.rst:86 +msgid "Set the hostname of the node to ``controller``." +msgstr "" + +#: ../basics-networking-neutron.rst:195 +msgid "Set the hostname of the node to ``network``." +msgstr "" + +#: ../swift-storage-node.rst:35 +msgid "Set the hostname of the node to ``object1``." +msgstr "" + +#: ../swift-storage-node.rst:45 +msgid "Set the hostname of the node to ``object2``." +msgstr "" + +#: ../dashboard-next-step.rst:24 +msgid "" +"Set up session storage. See section `Set up session storage for the " +"dashboard `__ in the `OpenStack Cloud Administrator " +"Guide `__ for " +"information on user session data." +msgstr "" + +#: ../swift-verify.rst:20 +msgid "Show the service status:" +msgstr "" + +#: ../cinder-storage-node.rst:166 +msgid "" +"Similarly, if your compute nodes use LVM on the operating system disk, you " +"must also modify the filter in the :file:`/etc/lvm/lvm.conf` file on those " +"nodes to include only the operating system disk. For example, if the :file:`/" +"dev/sda` device contains the operating system:" +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:92 +msgid "" +"So, if using Debian, you wont need to care about database creation, access " +"rights and character sets. All that is handled for you by the packages." +msgstr "" + +#: ../app_reserved_uids.rst:11 +msgid "" +"Some OpenStack packages generate and assign user IDs automatically during " +"package installation. In these cases, the user ID value is not important. " +"The existence of the user ID is what matters." +msgstr "" + +#: ../neutron-network-node.rst:318 +msgid "" +"Some cloud images ignore the DHCP MTU option in which case you should " +"configure it using metadata, a script, or another suitable method." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:116 ../basics-networking-neutron.rst:213 +#: ../basics-networking-nova.rst:101 ../basics-networking-nova.rst:193 +msgid "" +"Some distributions add an extraneous entry in the :file:`/etc/hosts` file " +"that resolves the actual hostname to another loopback IP address such as " +"``127.0.1.1``. Note it's ``127.0.*1.1*``, do not remove the required " +"``127.0.0.1`` entry. You must comment out or remove this entry to prevent " +"name resolution problems." +msgstr "" + +#: ../basics-networking-neutron.rst:272 +msgid "" +"Some distributions add an extraneous entry in the :file:`/etc/hosts` file " +"that resolves the actual hostname to another loopback IP address such as " +"``127.0.1.1``. You must comment out or remove this entry to prevent name " +"resolution problems." +msgstr "" + +#: ../ceilometer-swift.rst:15 +msgid "" +"Source the ``admin`` credentials to gain access to admin-only CLI commands." +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-compute-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-network-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:228 ../ceilometer-verify.rst:11 +#: ../cinder-controller-node.rst:44 ../cinder-verify.rst:23 +#: ../glance-install.rst:51 ../glance-verify.rst:24 ../heat-install.rst:38 +#: ../heat-install.rst:336 ../neutron-compute-node.rst:371 +#: ../neutron-controller-node.rst:37 ../neutron-controller-node.rst:473 +#: ../neutron-network-node.rst:560 ../nova-controller-install.rst:41 +#: ../nova-verify.rst:11 ../swift-controller-node.rst:29 +msgid "" +"Source the ``admin`` credentials to gain access to admin-only CLI commands:" +msgstr "" + +#: ../heat-verify.rst:8 +msgid "Source the ``admin`` tenant credentials:" +msgstr "" + +#: ../cinder-verify.rst:42 +msgid "" +"Source the ``demo`` credentials to perform the following steps as a non-" +"administrative project:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-verify.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:329 ../launch-instance-nova.rst:293 +#: ../swift-verify.rst:14 +msgid "Source the ``demo`` credentials:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:13 ../launch-instance-nova.rst:14 +msgid "Source the ``demo`` tenant credentials:" +msgstr "" + +#: ../basics-packages.rst:436 +msgid "" +"Start the message queue service and configure it to start when the system " +"boots:" +msgstr "" + +#: ../overview.rst:50 +msgid "" +"Stores and retrieves arbitrary unstructured data objects via a :term:" +"`RESTful`, HTTP based API. It is highly fault tolerant with its data " +"replication and scale-out architecture. Its implementation is not like a " +"file server with mountable directories. In this case, it writes objects and " +"files to multiple drives, ensuring the data is replicated across a server " +"cluster." +msgstr "" + +#: ../overview.rst:72 +msgid "" +"Stores and retrieves virtual machine disk images. OpenStack Compute makes " +"use of this during instance provisioning." +msgstr "" + +#: ../ceilometer.rst:16 +msgid "" +"Telemetry provides a framework for monitoring and metering the OpenStack " +"cloud. It is also known as the ceilometer project." +msgstr "" + +#: ../ceilometer-nova.rst:5 +msgid "" +"Telemetry uses a combination of notifications and an agent to collect " +"Compute meters. Perform these steps on each compute node." +msgstr "" + +#: ../neutron-initial-networks.rst:124 +msgid "Tenant network" +msgstr "" + +#: ../basic_environment.rst:36 +msgid "" +"The :command:`systemctl enable` call on openSUSE outputs a warning message " +"when the service uses SysV Init scripts instead of native systemd files. " +"This warning can be ignored." +msgstr "" + +#: ../cinder-verify.rst:97 +msgid "" +"The :doc:`launch an instance ` chapter includes " +"instructions for attaching this volume to an instance." +msgstr "" + +#: ../neutron-network-node.rst:270 +msgid "The :term:`DHCP agent` provides DHCP services for virtual networks." +msgstr "" + +#: ../neutron-network-node.rst:240 +msgid "" +"The :term:`Layer-3 (L3) agent` provides routing services for virtual " +"networks." +msgstr "" + +#: ../overview.rst:8 +msgid "" +"The :term:`OpenStack` project is an open source cloud computing platform " +"that supports all types of cloud environments. The project aims for simple " +"implementation, massive scalability, and a rich set of features. Cloud " +"computing experts from around the world contribute to the project." +msgstr "" + +#: ../overview.rst:240 +msgid "" +"The :term:`compute node` runs the :term:`hypervisor` portion of Compute that " +"operates :term:`tenant` :term:`virtual machines ` or " +"instances. By default, Compute uses :term:`KVM ` as " +"the :term:`hypervisor`. Compute also provisions tenant networks and provides " +"firewalling (:term:`security groups `) services. You can run " +"more than one compute node." +msgstr "" + +#: ../overview.rst:156 +msgid "" +"The :term:`compute node` runs the :term:`hypervisor` portion of Compute that " +"operates :term:`tenant` :term:`virtual machines ` or " +"instances. By default, Compute uses :term:`KVM ` as " +"the :term:`hypervisor`. The compute node also runs the Networking plug-in " +"and an agent that connect tenant networks to instances and provide " +"firewalling (:term:`security groups `) services. You can run " +"more than one compute node." +msgstr "" + +#: ../overview.rst:139 +msgid "" +"The :term:`controller node ` runs the Identity " +"service, Image Service, management portions of Compute and Networking, " +"Networking plug-in, and the dashboard. It also includes supporting services " +"such as an SQL database, :term:`message queue`, and :term:`Network Time " +"Protocol (NTP)`." +msgstr "" + +#: ../overview.rst:229 +msgid "" +"The :term:`controller node ` runs the Identity " +"service, Image service, management portion of Compute, and the dashboard. It " +"also includes supporting services such as an SQL database, :term:`message " +"queue`, and :term:`Network Time Protocol (NTP)`." +msgstr "" + +#: ../neutron-network-node.rst:346 +msgid "" +"The :term:`metadata agent ` provides configuration " +"information such as credentials to instances." +msgstr "" + +#: ../cinder-storage-node.rst:130 +msgid "The Block Storage service creates logical volumes in this volume group." +msgstr "" + +#: ../cinder-controller-node.rst:114 +msgid "" +"The Block Storage service requires both the ``volume`` and ``volumev2`` " +"services. However, both services use the same API endpoint that references " +"the Block Storage version 2 API." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:184 ../launch-instance-nova.rst:203 +msgid "" +"The CirrOS image includes conventional user name/password authentication and " +"provides these credentials at the login prompt. After logging into CirrOS, " +"we recommend that you verify network connectivity using ``ping``." +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:55 +msgid "" +"The Debian OpenStack packages offer automation for this, so OpenStack users " +"do not have to manually edit the configuration files." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:57 +msgid "" +"The Debian package post installation scripts will then perform the below " +"commands for you:" +msgstr "" + +#: ../debconf/debconf-concepts.rst:18 +msgid "The Debian packages" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:375 ../launch-instance-nova.rst:339 +msgid "" +"The ID of the ``demo-volume1`` volume should indicate ``in-use`` status by " +"the ID of the ``demo-instance1`` instance." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:74 +msgid "" +"The Identity service is installed with MySQL as the database back end, " +"``keystonedb`` as database name, and the localhost socket file. The " +"corresponding DNS will then be:" +msgstr "" + +#: ../keystone-services.rst:88 +msgid "" +"The Identity service manages a catalog of API endpoints associated with the " +"services in your OpenStack environment. Services use this catalog to " +"determine how to communicate with other services in your environment." +msgstr "" + +#: ../keystone-services.rst:63 +msgid "" +"The Identity service manages a catalog of services in your OpenStack " +"environment. Services use this catalog to determine the other services " +"available in your environment." +msgstr "" + +#: ../keystone-services.rst:5 +msgid "" +"The Identity service provides a catalog of services and their locations. " +"Each service that you add to your OpenStack environment requires a :term:" +"`service` entity and several :term:`API endpoints` in the " +"catalog." +msgstr "" + +#: ../keystone-users.rst:5 +msgid "" +"The Identity service provides authentication services for each OpenStack " +"service. The authentication service uses a combination of :term:`domains " +"`, :term:`projects` (tenants), :term:`users`, and :" +"term:`roles`." +msgstr "" + +#: ../keystone-verify.rst:56 +msgid "" +"The Identity version 3 API adds support for domains that contain projects " +"and users. Projects and users can use the same names in different domains. " +"Therefore, in order to use the version 3 API, requests must also explicitly " +"contain at least the ``default`` domain or use IDs. For simplicity, this " +"guide explicitly uses the ``default`` domain so examples can use names " +"instead of IDs." +msgstr "" + +#: ../neutron-network-node.rst:170 +msgid "" +"The ML2 plug-in uses the :term:`Open vSwitch (OVS) ` mechanism " +"(agent) to build the virtual networking framework for instances." +msgstr "" + +#: ../neutron-compute-node.rst:167 +msgid "" +"The ML2 plug-in uses the Open vSwitch (OVS) mechanism (agent) to build the " +"virtual networking framework for instances." +msgstr "" + +#: ../neutron-controller-node.rst:291 +msgid "" +"The ML2 plug-in uses the Open vSwitch (OVS) mechanism (agent) to build the " +"virtual networking framework for instances. However, the controller node " +"does not need the OVS components because it does not handle instance network " +"traffic." +msgstr "" + +#: ../neutron-compute-node.rst:226 +msgid "" +"The OVS service provides the underlying virtual networking framework for " +"instances." +msgstr "" + +#: ../neutron-network-node.rst:428 +msgid "" +"The OVS service provides the underlying virtual networking framework for " +"instances. The integration bridge ``br-int`` handles internal instance " +"network traffic within OVS. The external bridge ``br-ex`` handles external " +"instance network traffic within OVS. The external bridge requires a port on " +"the physical external network interface to provide instances with external " +"network access. In essence, this port connects the virtual and physical " +"external networks in your environment." +msgstr "" + +#: ../swift-controller-node.rst:26 +msgid "" +"The Object Storage service does not use an SQL database on the controller " +"node. Instead, it uses distributed SQLite databases on each storage node." +msgstr "" + +#: ../cinder.rst:13 +msgid "" +"The OpenStack Block Storage service provides block storage devices to guest " +"instances. The method in which the storage is provisioned and consumed is " +"determined by the Block Storage driver, or drivers in the case of a multi-" +"backend configuration. There are a variety of drivers that are available: " +"NAS/SAN, NFS, iSCSI, Ceph, and more. The Block Storage API and scheduler " +"services typically run on the controller nodes. Depending upon the drivers " +"used, the volume service can run on controllers, compute nodes, or " +"standalone storage nodes. For more information, see the `Configuration " +"Reference `__." +msgstr "" + +#: ../glance.rst:11 +msgid "" +"The OpenStack Image service (glance) enables users to discover, register, " +"and retrieve virtual machine images. It offers a :term:`REST ` API " +"that enables you to query virtual machine image metadata and retrieve an " +"actual image. You can store virtual machine images made available through " +"the Image service in a variety of locations, from simple file systems to " +"object-storage systems like OpenStack Object Storage." +msgstr "" + +#: ../swift.rst:7 +msgid "" +"The OpenStack Object Storage services (swift) work together to provide " +"object storage and retrieval through a :term:`REST API `. Your " +"environment must at least include the Identity service (keystone) prior to " +"deploying Object Storage." +msgstr "" + +#: ../horizon.rst:5 +msgid "" +"The OpenStack dashboard, also known as `Horizon `__ is a Web interface that enables cloud " +"administrators and users to manage various OpenStack resources and services." +msgstr "" + +#: ../index.rst:33 +msgid "" +"The OpenStack system consists of several key projects that you install " +"separately. These projects work together depending on your cloud needs. " +"These projects include Compute, Identity Service, Networking, Image Service, " +"Block Storage, Object Storage, Telemetry, Orchestration, and Database. You " +"can install any of these projects separately and configure them stand-alone " +"or as connected entities." +msgstr "" + +#: ../heat.rst:12 +msgid "" +"The Orchestration module (heat) uses a heat orchestration template (HOT) to " +"create and manage cloud resources." +msgstr "" + +#: ../heat-verify.rst:14 +msgid "" +"The Orchestration module uses templates to describe stacks. To learn about " +"the template language, see `the Template Guide `__ in the `Heat developer " +"documentation `__." +msgstr "" + +#: ../heat-install.rst:119 +msgid "" +"The Orchestration service automatically assigns the ``heat_stack_user`` role " +"to users that it creates during stack deployment. By default, this role " +"restricts :term:`API` operations. To avoid conflicts, do not add this role " +"to users with the ``heat_stack_owner`` role." +msgstr "" + +#: ../glance-install.rst:233 ../glance-install.rst:301 +msgid "" +"The Telemetry chapter provides an Image service configuration that enables " +"notifications." +msgstr "" + +#: ../ceilometer-swift.rst:11 +msgid "" +"The Telemetry service requires access to the Object Storage service using " +"the ``ResellerAdmin`` role. Perform these steps on the controller node." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:83 +msgid "" +"The ``dbconfig-common`` package will configure MySQL for these access " +"rights, and create the database for you. Since OpenStack 2014.1.1, all " +"OpenStack packages in Debian are performing the following MySQL query after " +"database creation (if you decide to use MySQL as a back-end):" +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:11 +msgid "" +"The ``heat-common`` package and not the ``heat-api`` package configures the " +"Orchestration service." +msgstr "" + +#: ../swift-storage-node.rst:150 +msgid "" +"The ``rsync`` service requires no authentication, so consider running it on " +"a private network." +msgstr "" + +#: ../debconf/debconf-concepts.rst:117 +msgid "" +"The ``seen true`` option tells ``debconf`` that a specified screen was " +"already seen by the user so do not show it again. This option is useful for " +"upgrades." +msgstr "" + +#: ../swift-verify.rst:8 +msgid "" +"The ``swift`` client requires the ``-V 3`` parameter to use the Identity " +"version 3 API." +msgstr "" + +#: ../swift-initial-rings.rst:18 +msgid "" +"The account server uses the account ring to maintain lists of containers." +msgstr "" + +#: ../networking-neutron.rst:33 +msgid "" +"The common agents are L3 (layer 3), DHCP (dynamic host IP addressing), and a " +"plug-in agent." +msgstr "" + +#: ../neutron-compute-node.rst:5 +msgid "" +"The compute node handles connectivity and :term:`security groups ` for instances." +msgstr "" + +#: ../swift-initial-rings.rst:98 +msgid "" +"The container server uses the container ring to maintain lists of objects. " +"However, it does not track object locations." +msgstr "" + +#: ../horizon.rst:10 +msgid "" +"The dashboard enables web-based interactions with the OpenStack Compute " +"cloud controller through the OpenStack APIs." +msgstr "" + +#: ../dashboard-install.rst:8 +msgid "" +"The dashboard relies on functional core services including Identity, Image " +"service, Compute, and either Networking (neutron) or legacy networking (nova-" +"network). Environments with stand-alone services such as Object Storage " +"cannot use the dashboard. For more information, see the `developer " +"documentation `__." +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:22 +msgid "" +"The debconf system helps users configure the ``auth_uri``, ``identity_uri``, " +"``admin_tenant_name``, ``admin_user``, and ``admin_password`` options." +msgstr "" + +#: ../basic_environment.rst:7 +msgid "" +"The draft version of this guide focuses on the future Liberty release and " +"will not work for the current Kilo release. If you want to install Kilo, you " +"must use the `Kilo version `__ of this guide " +"instead." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:16 ../basics-networking-nova.rst:13 +msgid "The example architecture assumes use of the following networks:" +msgstr "" + +#: ../basics-networking-neutron.rst:7 +msgid "" +"The example architecture with OpenStack Networking (neutron) requires one " +"controller node, one network node, and at least one compute node. The " +"controller node contains one network interface on the :term:`management " +"network`. The network node contains one network interface on the management " +"network, one on the :term:`instance tunnels network`, and one on the :term:" +"`external network`. The compute node contains one network interface on the " +"management network and one on the instance tunnels network." +msgstr "" + +#: ../basics-networking-nova.rst:7 +msgid "" +"The example architecture with legacy networking (nova-network) requires a " +"controller node and at least one compute node. The controller node contains " +"one network interface on the :term:`management network`. The compute node " +"contains one network interface on the management network and one on the :" +"term:`external network`." +msgstr "" + +#: ../basics-networking-nova.rst:126 +msgid "" +"The external interface uses a special configuration without an IP address " +"assigned to it. Configure the second interface as the external interface:" +msgstr "" + +#: ../basics-networking-neutron.rst:143 +msgid "" +"The external interface uses a special configuration without an IP address " +"assigned to it. Configure the third interface as the external interface:" +msgstr "" + +#: ../neutron-initial-networks.rst:23 +msgid "" +"The external network typically provides Internet access for your instances. " +"By default, this network only allows Internet access *from* instances using :" +"term:`Network Address Translation (NAT)`. You can enable Internet access " +"*to* individual instances using a :term:`floating IP address` and suitable :" +"term:`security group` rules. The ``admin`` tenant owns this network because " +"it provides external network access for multiple tenants." +msgstr "" + +#: ../debconf/debconf-concepts.rst:103 +msgid "" +"The following example shows how to pre-seed an automated MySQL Server " +"installation:" +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:26 +msgid "The following screens show an example Image service configuration:" +msgstr "" + +#: ../basic_environment.rst:118 +msgid "" +"The following table provides a list of services that require passwords and " +"their associated references in the guide:" +msgstr "" + +#: ../neutron-network-node.rst:5 +msgid "" +"The network node primarily handles internal and external routing and :term:" +"`DHCP` services for virtual networks." +msgstr "" + +#: ../overview.rst:150 +msgid "" +"The network node runs the Networking plug-in and several agents that " +"provision tenant networks and provide switching, routing, :term:`NAT`, and :term:`DHCP` services. This node also " +"handles external (Internet) connectivity for tenant virtual machine " +"instances." +msgstr "" + +#: ../swift-initial-rings.rst:177 +msgid "" +"The object server uses the object ring to maintain lists of object locations " +"on local devices." +msgstr "" + +#: ../overview.rst:170 ../overview.rst:253 +msgid "" +"The optional Block Storage node contains the disks that the Block Storage " +"service provisions for tenant virtual machine instances. You can run more " +"than one of these nodes." +msgstr "" + +#: ../overview.rst:179 ../overview.rst:262 +msgid "" +"The optional Object Storage nodes contain the disks that the Object Storage " +"service uses for storing accounts, containers, and objects. You can run more " +"than two of these nodes. However, the minimal architecture example requires " +"two nodes." +msgstr "" + +#: ../debconf/debconf-rabbitmq.rst:34 +msgid "The other directives concerning RabbitMQ will stay untouched." +msgstr "" + +#: ../debconf/debconf-concepts.rst:86 +msgid "" +"The packages do not require pre-depends. If ``dbconfig-common`` is already " +"installed on the system, the user sees all prompts. However, you cannot " +"define the order in which the ``debconf`` screens appear. The user must make " +"sense of it even if the prompts appear in an illogical order." +msgstr "" + +#: ../keystone-openrc.rst:5 +msgid "" +"The previous section used a combination of environment variables and command " +"options to interact with the Identity service via the :command:`openstack` " +"client. To increase efficiency of client operations, OpenStack supports " +"simple client environment scripts also known as OpenRC files. These scripts " +"typically contain common options for all clients, but also support unique " +"options. For more information, see the `OpenStack User Guide `__." +msgstr "" + +#: ../swift-controller-node.rst:17 +msgid "" +"The proxy service relies on an authentication and authorization mechanism " +"such as the Identity service. However, unlike other services, it also offers " +"an internal mechanism that allows it to operate without any other OpenStack " +"services. However, for simplicity, this guide references the Identity " +"service in :doc:`keystone`. Before you configure the Object Storage service, " +"you must create service credentials and an API endpoint." +msgstr "" + +#: ../debconf/debconf-concepts.rst:20 +msgid "" +"The rules described here are from the `Debian Policy Manual `__. If any rule described in this chapter is " +"not respected, you have found a serious bug that must be fixed." +msgstr "" + +#: ../nova-compute-install.rst:144 +msgid "" +"The server component listens on all IP addresses and the proxy component " +"only listens on the management interface IP address of the compute node. The " +"base URL indicates the location where you can use a web browser to access " +"remote consoles of instances on this compute node." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:160 ../launch-instance-nova.rst:179 +msgid "" +"The status changes from ``BUILD`` to ``ACTIVE`` when your instance finishes " +"the build process." +msgstr "" + +#: ../neutron-initial-networks.rst:125 +msgid "" +"The tenant network provides internal network access for instances. The " +"architecture isolates this type of network from other tenants. The ``demo`` " +"tenant owns this network because it only provides network access for " +"instances within it." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:74 +msgid "" +"The values of ``AUTH_TOKEN``, ``KEYSTONE_ENDPOINT_IP``, ``PKG_ENDPOINT_IP``, " +"and ``REGION_NAME`` depend on the answer you will provide to the debconf " +"prompts. But the values of ``SERVICE_NAME``, ``SERVICE_TYPE``, " +"``SERVICE_DESC``, and ``SERVICE_URL`` are already pre-wired in each package, " +"so you don't have to remember them." +msgstr "" + +#: ../debconf/debconf-concepts.rst:40 +msgid "Then, ``debconf`` does not prompt you." +msgstr "" + +#: ../debconf/debconf-rabbitmq.rst:22 +msgid "" +"These debconf screens appear in: ``ceilometer-common``, ``cinder-common``, " +"``glance-common``, ``heat-common``, ``neutron-common``, and ``nova-common``." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:34 +msgid "" +"These screens appear when you re-configure the ``dbconfig-common`` package:" +msgstr "" + +#: ../launch-instance.rst:28 +msgid "" +"These steps reference example components created in previous chapters. You " +"must adjust certain values such as IP addresses to match your environment." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:14 +msgid "" +"This ``connection`` directive will be handled by the ``dbconfig-common`` " +"package, which provides a standard Debian interface. It enables you to " +"configure Debian database parameters. It includes localized prompts for many " +"languages and it supports the following database backends: SQLite, MySQL, " +"and PostgreSQL." +msgstr "" + +#: ../debconf/debconf-concepts.rst:58 +msgid "" +"This calls the post-installation script for the ``PACKAGE-NAME`` package " +"after the user responds to all prompts. If you cannot install a Debian " +"package in a non-interactive way, you have found a release-critical bug in " +"Debian. Report it to the Debian bug tracking system." +msgstr "" + +#: ../networking.rst:5 +msgid "" +"This chapter explains how to install and configure either OpenStack " +"Networking (neutron), or the legacy ``nova-network`` component. The ``nova-" +"network`` service enables you to deploy one network type per instance and is " +"suitable for basic network functionality. OpenStack Networking enables you " +"to deploy multiple network types per instance and includes :term:`plug-in` s " +"for a variety of products that support :term:`virtual networking`." +msgstr "" + +#: ../debconf/debconf-concepts.rst:5 +msgid "" +"This chapter explains how to use the Debian ``debconf`` and ``dbconfig-" +"common`` packages to configure OpenStack services. These packages enable " +"users to perform configuration tasks. When users install OpenStack packages, " +"``debconf`` prompts the user for responses, which seed the contents of " +"configuration files associated with that package. After package " +"installation, users can update the configuration of a package by using the :" +"command:`dpkg-reconfigure` program." +msgstr "" + +#: ../cinder.rst:27 +msgid "" +"This chapter omits the backup manager because it depends on the Object " +"Storage service." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-initial-rings.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:276 ../launch-instance-nova.rst:34 +#: ../networking-nova.rst:160 ../swift-initial-rings.rst:32 +#: ../swift-initial-rings.rst:113 ../swift-initial-rings.rst:192 +msgid "This command provides no output." +msgstr "" + +#: ../keystone-verify.rst:54 ../keystone-verify.rst:81 +#: ../keystone-verify.rst:104 ../keystone-verify.rst:124 +#: ../keystone-verify.rst:144 +msgid "This command uses the password for the ``admin`` user." +msgstr "" + +#: ../keystone-verify.rst:167 +msgid "" +"This command uses the password for the ``demo`` user and API port 5000 which " +"only allows regular (non-admin) access to the Identity service API." +msgstr "" + +#: ../horizon.rst:17 +msgid "This example deployment uses an Apache web server." +msgstr "" + +#: ../overview.rst:103 +msgid "" +"This guide describes how to deploy these services in a functional test " +"environment and, by example, teaches you how to build a production " +"environment. Realistically, you would use automation tools such as Ansible, " +"Chef, and Puppet to deploy and manage a production environment." +msgstr "" + +#: ../index.rst:65 +msgid "This guide documents OpenStack Liberty release." +msgstr "" + +#: ../index.rst:67 +msgid "" +"This guide is a work-in-progress and changing rapidly while we continue to " +"test and enhance the guidance. Please note where there are open \"to do\" " +"items and help where you are able." +msgstr "" + +#: ../keystone-users.rst:96 +msgid "" +"This guide uses a service project that contains a unique user for each " +"service that you add to your environment." +msgstr "" + +#: ../debconf/debconf-keystone-authtoken.rst:42 +msgid "" +"This information is stored in the configuration file for each service. For " +"example:" +msgstr "" + +#: ../basics-networking-neutron.rst:30 +msgid "" +"This network does not require a gateway because communication only occurs " +"among network and compute nodes in your OpenStack environment." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:22 ../basics-networking-nova.rst:19 +msgid "" +"This network requires a gateway to provide Internet access to all nodes for " +"administrative purposes such as package installation, security updates, :" +"term:`DNS`, and :term:`Network Time Protocol (NTP)`." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:38 ../basics-networking-nova.rst:27 +msgid "" +"This network requires a gateway to provide Internet access to instances in " +"your OpenStack environment." +msgstr "" + +#: ../networking-nova.rst:129 +msgid "" +"This network shares the same :term:`subnet` associated with the physical " +"network connected to the external :term:`interface` on the compute node. You " +"should specify an exclusive slice of this subnet to prevent interference " +"with other devices on the external network." +msgstr "" + +#: ../neutron-compute-node.rst:393 +msgid "" +"This output should indicate four agents alive on the network node and one " +"agent alive on the compute node." +msgstr "" + +#: ../nova-verify.rst:36 +msgid "" +"This output should indicate four service components enabled on the " +"controller node and one service component enabled on the compute node." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:39 +msgid "" +"This screen configures the IP addresses for the service. The configuration " +"script automatically detects the IP address used by the interface that is " +"connected to the default route (``/sbin/route`` and ``/sbin/ip``)." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:50 +msgid "" +"This screen configures the region name for the service. For example, ``us-" +"east-coast`` or ``europe-paris``." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:25 +msgid "This screen registers packages in the Identity service catalog:" +msgstr "" + +#: ../glance-install.rst:11 +msgid "" +"This section assumes proper installation, configuration, and operation of " +"the Identity service as described in the \":doc:`keystone-install`\" section " +"and the \":doc:`keystone-verify`\" section as well as setup of the :file:" +"`admin-openrc.sh` script as described in the \":doc:`keystone-openrc`\" " +"section." +msgstr "" + +#: ../dashboard-install.rst:16 +msgid "" +"This section assumes proper installation, configuration, and operation of " +"the Identity service using the Apache HTTP server and Memcached as described " +"in the \":doc:`keystone-install`\" section." +msgstr "" + +#: ../nova-compute-install.rst:17 +msgid "" +"This section assumes that you are following the instructions in this guide " +"step-by-step to configure the first compute node. If you want to configure " +"additional compute nodes, prepare them in a similar fashion to the first " +"compute node in the :ref:`example architectures ` section using the same networking service as your existing " +"environment. For either networking service, follow the :ref:`NTP " +"configuration ` and :doc:`OpenStack packages ` instructions. For OpenStack Networking (neutron), also follow " +"the :doc:`OpenStack Networking compute node ` " +"instructions. For legacy networking (nova-network), also follow the :doc:" +"`legacy networking compute node ` instructions. Each " +"additional compute node requires unique IP addresses." +msgstr "" + +#: ../networking-nova.rst:41 +msgid "" +"This section covers deployment of a simple :term:`flat network` that " +"provides IP addresses to your instances via :term:`DHCP`. If your " +"environment includes multiple compute nodes, the :term:`multi-host` feature " +"provides redundancy by spreading network functions across compute nodes." +msgstr "" + +#: ../cinder-storage-node.rst:5 +msgid "" +"This section describes how to install and configure storage nodes for the " +"Block Storage service. For simplicity, this configuration references one " +"storage node with an empty local block storage device :file:`/dev/sdb` that " +"contains a suitable partition table with one partition :file:`/dev/sdb1` " +"occupying the entire device. The service provisions logical volumes on this " +"device using the :term:`LVM ` driver and " +"provides them to instances via :term:`iSCSI` transport. You can follow these " +"instructions with minor modifications to horizontally scale your environment " +"with additional storage nodes." +msgstr "" + +#: ../swift-storage-node.rst:5 +msgid "" +"This section describes how to install and configure storage nodes that " +"operate the account, container, and object services. For simplicity, this " +"configuration references two storage nodes, each containing two empty local " +"block storage devices. Each of the devices, :file:`/dev/sdb` and :file:`/dev/" +"sdc`, must contain a suitable partition table with one partition occupying " +"the entire device. Although the Object Storage service supports any file " +"system with :term:`extended attributes (xattr)`, testing and benchmarking " +"indicate the best performance and reliability on :term:`XFS`. For more " +"information on horizontally scaling your environment, see the `Deployment " +"Guide `_." +msgstr "" + +#: ../cinder-controller-node.rst:5 +msgid "" +"This section describes how to install and configure the Block Storage " +"service, code-named cinder, on the controller node. This service requires at " +"least one additional storage node that provides volumes to instances." +msgstr "" + +#: ../nova-compute-install.rst:4 +msgid "" +"This section describes how to install and configure the Compute service on a " +"compute node. The service supports several :term:`hypervisors ` " +"to deploy :term:`instances ` or :term:`VMs `. For simplicity, this configuration uses the :term:`QEMU ` hypervisor with the :term:`KVM ` " +"extension on compute nodes that support hardware acceleration for virtual " +"machines. On legacy hardware, this configuration uses the generic QEMU " +"hypervisor. You can follow these instructions with minor modifications to " +"horizontally scale your environment with additional compute nodes." +msgstr "" + +#: ../nova-controller-install.rst:4 +msgid "" +"This section describes how to install and configure the Compute service, " +"code-named nova, on the controller node." +msgstr "" + +#: ../glance-install.rst:5 +msgid "" +"This section describes how to install and configure the Image service, code-" +"named glance, on the controller node. For simplicity, this configuration " +"stores images on the local file system." +msgstr "" + +#: ../keystone-install.rst:5 +msgid "" +"This section describes how to install and configure the OpenStack Identity " +"service, code-named keystone, on the controller node. For performance, this " +"configuration deploys the Apache HTTP server to handle requests and " +"Memcached to store tokens instead of an SQL database." +msgstr "" + +#: ../heat-install.rst:5 +msgid "" +"This section describes how to install and configure the Orchestration " +"module, code-named heat, on the controller node." +msgstr "" + +#: ../ceilometer-controller-install.rst:5 +msgid "" +"This section describes how to install and configure the Telemetry module, " +"code-named ceilometer, on the controller node. The Telemetry module uses " +"separate agents to collect measurements from each OpenStack service in your " +"environment." +msgstr "" + +#: ../dashboard-install.rst:5 +msgid "" +"This section describes how to install and configure the dashboard on the " +"controller node." +msgstr "" + +#: ../swift-controller-node.rst:5 +msgid "" +"This section describes how to install and configure the proxy service that " +"handles requests for the account, container, and object services operating " +"on the storage nodes. For simplicity, this guide installs and configures the " +"proxy service on the controller node. However, you can run the proxy service " +"on any node with network connectivity to the storage nodes. Additionally, " +"you can install and configure the proxy service on multiple nodes to " +"increase performance and redundancy. For more information, see the " +"`Deployment Guide `__." +msgstr "" + +#: ../cinder-verify.rst:5 +msgid "" +"This section describes how to verify operation of the Block Storage service " +"by creating a volume." +msgstr "" + +#: ../swift-verify.rst:4 +msgid "" +"This section describes how to verify operation of the Object Storage service." +msgstr "" + +#: ../heat-verify.rst:5 +msgid "" +"This section describes how to verify operation of the Orchestration module " +"(heat)." +msgstr "" + +#: ../ceilometer-verify.rst:5 +msgid "This section describes how to verify operation of the Telemetry module." +msgstr "" + +#: ../dashboard-verify.rst:5 +msgid "This section describes how to verify operation of the dashboard." +msgstr "" + +#: ../basic_environment.rst:12 +msgid "" +"This section explains how to configure each node in the :ref:`overview-" +"example-architectures`, including the two-node architecture with legacy " +"networking :ref:`figure-legacy-network-hw` and three-node architecture with " +"OpenStack Networking (neutron) :ref:`figure-neutron-network-hw`." +msgstr "" + +#: ../debconf/debconf-rabbitmq.rst:25 +msgid "" +"This will configure the below directives (example from :file:`nova.conf`):" +msgstr "" + +#: ../overview.rst:136 +msgid "" +"Three-node architecture with OpenStack Networking (neutron) and optional " +"nodes for Block Storage and Object Storage services." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:223 ../launch-instance-nova.rst:227 +msgid "To access your instance remotely" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:164 ../launch-instance-nova.rst:183 +msgid "To access your instance using a virtual console" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:324 ../launch-instance-nova.rst:288 +msgid "To attach a Block Storage volume to your instance" +msgstr "" + +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-swift.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-nova.rst:121 ../ceilometer-swift.rst:48 +msgid "To configure notifications" +msgstr "" + +# #-#-#-#-# ceilometer-cinder.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-swift.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-cinder.rst:10 ../ceilometer-controller-install.rst:11 +#: ../ceilometer-swift.rst:9 ../cinder-controller-node.rst:11 +#: ../cinder-storage-node.rst:17 ../glance-install.rst:18 +#: ../heat-install.rst:9 ../nova-controller-install.rst:8 +#: ../swift-controller-node.rst:15 ../swift-storage-node.rst:18 +msgid "To configure prerequisites" +msgstr "" + +#: ../dashboard-install.rst:53 +msgid "To configure the dashboard" +msgstr "" + +#: ../keystone-users.rst:22 +msgid "To create tenants, users, and roles" +msgstr "" + +#: ../swift-controller-node.rst:35 +msgid "To create the Identity service credentials, complete these steps:" +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:16 ../glance-install.rst:23 +#: ../heat-install.rst:14 ../keystone-install.rst:17 +#: ../neutron-controller-node.rst:10 ../nova-controller-install.rst:13 +msgid "To create the database, complete these steps:" +msgstr "" + +#: ../swift-initial-rings.rst:20 ../swift-initial-rings.rst:101 +#: ../swift-initial-rings.rst:180 +msgid "To create the ring perform the following steps on the controller node." +msgstr "" + +#: ../keystone-openrc.rst:15 +msgid "To create the scripts" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:235 ../cinder-controller-node.rst:51 +#: ../glance-install.rst:58 ../heat-install.rst:45 +#: ../neutron-controller-node.rst:44 ../nova-controller-install.rst:48 +msgid "To create the service credentials, complete these steps:" +msgstr "" + +#: ../basic_environment.rst:104 +msgid "" +"To ease the installation process, this guide only covers password security " +"where applicable. You can create secure passwords manually, generate them " +"using a tool such as `pwgen `__, or " +"by running the following command:" +msgstr "" + +# #-#-#-#-# ceilometer-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# ceilometer-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-storage-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# dashboard-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-compute-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../ceilometer-controller-install.rst:474 ../ceilometer-nova.rst:139 +#: ../cinder-controller-node.rst:298 ../cinder-storage-node.rst:350 +#: ../dashboard-install.rst:124 ../glance-install.rst:323 +#: ../heat-install.rst:361 ../nova-compute-install.rst:218 +#: ../nova-controller-install.rst:306 +msgid "To finalize installation" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:6 ../launch-instance-nova.rst:6 +msgid "To generate a key pair" +msgstr "" + +#: ../cinder-controller-node.rst:163 +msgid "To install and configure Block Storage controller components" +msgstr "" + +#: ../nova-controller-install.rst:119 +msgid "To install and configure Compute controller components" +msgstr "" + +#: ../nova-compute-install.rst:32 +msgid "To install and configure the Compute hypervisor components" +msgstr "" + +#: ../glance-install.rst:130 +msgid "To install and configure the Image service components" +msgstr "" + +#: ../heat-install.rst:194 +msgid "To install and configure the Orchestration components" +msgstr "" + +#: ../ceilometer-controller-install.rst:306 +msgid "To install and configure the Telemetry module components" +msgstr "" + +#: ../ceilometer-nova.rst:9 +msgid "To install and configure the agent" +msgstr "" + +#: ../swift-controller-node.rst:106 +msgid "To install and configure the controller node components" +msgstr "" + +#: ../dashboard-install.rst:21 +msgid "To install the dashboard components" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:37 ../launch-instance-nova.rst:48 +msgid "To launch an instance" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:38 ../launch-instance-nova.rst:49 +msgid "" +"To launch an instance, you must at least specify the flavor, image name, " +"network, security group, key, and instance name." +msgstr "" + +#: ../keystone-openrc.rst:54 +msgid "To load client environment scripts" +msgstr "" + +#: ../basic_environment.rst:58 +msgid "" +"To minimize clutter and provide more resources for OpenStack, we recommend a " +"minimal installation of your Linux distribution. Also, we strongly recommend " +"that you install a 64-bit version of your distribution on at least the " +"compute node. If you install a 32-bit version of your distribution on the " +"compute node, attempting to start an instance using a 64-bit image will fail." +msgstr "" + +#: ../debconf/debconf-concepts.rst:33 +msgid "" +"To opt out of using the ``debconf`` package, run the :command:`dpkg-" +"reconfigure` command and select non-interactive mode:" +msgstr "" + +#: ../ceilometer-glance.rst:5 +msgid "" +"To retrieve image-oriented events and samples, configure the Image service " +"to send notifications to the message bus. Perform these steps on the " +"controller node." +msgstr "" + +#: ../ceilometer-swift.rst:5 +msgid "" +"To retrieve storage-oriented events and samples, configure the Object " +"Storage service to send notifications to the message bus." +msgstr "" + +#: ../ceilometer-cinder.rst:5 +msgid "" +"To retrieve volume-oriented events and samples, you must configure the Block " +"Storage service to send notifications to the message bus. Perform these " +"steps on the controller and storage nodes." +msgstr "" + +#: ../keystone-openrc.rst:56 +msgid "" +"To run clients as a specific project and user, you can simply load the " +"associated client environment script prior to running them. For example:" +msgstr "" + +#: ../neutron-network-node.rst:473 +msgid "" +"To temporarily disable GRO on the external network interface while testing " +"your environment:" +msgstr "" + +#: ../dashboard-next-step.rst:32 +msgid "" +"To use the VNC client with the dashboard, the browser must support HTML5 " +"Canvas and HTML5 WebSockets." +msgstr "" + +#: ../overview.rst:226 +msgid "" +"Two-node architecture with legacy networking (nova-network) and optional " +"nodes for Block Storage and Object Storage services." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:44 +msgid "Unless you have a unique set up for your network, press **ENTER**." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:64 ../basics-networking-nova.rst:52 +msgid "" +"Unless you intend to use the exact configuration provided in this example " +"architecture, you must modify the networks in this procedure to match your " +"environment. Also, each node must resolve the other nodes by name in " +"addition to IP address. For example, the ``controller`` name must resolve to " +"``10.0.0.11``, the IP address of the management interface on the controller " +"node." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:44 +msgid "" +"Unlike other debconf prompts, you cannot pre-seed the responses for the " +"``dbconfig-common`` prompts by using ``debconf-set-selections``. Instead, " +"you must create a file in :file:`/etc/dbconfig-common`. For example, you " +"might create a keystone configuration file for ``dbconfig-common`` that is " +"located in :file:`/etc/dbconfig-common/keystone.conf`, as follows:" +msgstr "" + +#: ../keystone-verify.rst:28 +msgid "Unset the temporary ``OS_TOKEN`` and ``OS_URL`` environment variables:" +msgstr "" + +#: ../swift-verify.rst:34 +msgid "Upload a test file:" +msgstr "" + +#: ../glance-verify.rst:43 +msgid "" +"Upload the image to the Image service using the :term:`QCOW2 ` disk format, :term:`bare` container format, and public " +"visibility so all projects can access it:" +msgstr "" + +#: ../heat-verify.rst:51 +msgid "" +"Use the :command:`heat stack-create` command to create a stack from the " +"template:" +msgstr "" + +#: ../heat-verify.rst:65 +msgid "" +"Use the :command:`heat stack-list` command to verify successful creation of " +"the stack:" +msgstr "" + +#: ../ceilometer-cinder.rst:53 +msgid "" +"Use the ``cinder-volume-usage-audit`` command to retrieve meters on demand. " +"For more information, see `Block Storage audit script setup to get " +"notifications `__." +msgstr "" + +# #-#-#-#-# cinder-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-install.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-controller-node.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-controller-install.pot (Installation Guide 0.1) #-#-#-#-# +#: ../cinder-controller-node.rst:18 ../glance-install.rst:25 +#: ../heat-install.rst:16 ../keystone-install.rst:19 +#: ../neutron-controller-node.rst:12 ../nova-controller-install.rst:15 +msgid "" +"Use the database access client to connect to the database server as the " +"``root`` user:" +msgstr "" + +#: ../networking-neutron.rst:37 +msgid "" +"Used by most OpenStack Networking installations to route information between " +"the neutron-server and various agents, as well as a database to store " +"networking state for particular plug-ins." +msgstr "" + +#: ../launch-instance-neutron.rst:25 +msgid "Verify addition of the key pair:" +msgstr "" + +#: ../launch-instance-nova.rst:36 +msgid "Verify addition of the public key:" +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# neutron-initial-networks.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:280 ../basics-networking-nova.rst:202 +#: ../neutron-initial-networks.rst:246 +msgid "Verify connectivity" +msgstr "" + +#: ../cinder-verify.rst:80 +msgid "Verify creation and availability of the volume:" +msgstr "" + +#: ../networking-nova.rst:162 +msgid "Verify creation of the network:" +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:289 ../launch-instance-nova.rst:253 +msgid "" +"Verify network connectivity using :command:`ping` from the controller node " +"or any host on the external network:" +msgstr "" + +# #-#-#-#-# basics-ntp.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# cinder-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# dashboard-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# glance-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# heat-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# keystone-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# nova-verify.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# swift-verify.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-ntp.rst:157 ../cinder-verify.rst:3 ../dashboard-verify.rst:3 +#: ../glance-verify.rst:3 ../heat-verify.rst:3 ../keystone-verify.rst:3 +#: ../nova-verify.rst:2 ../swift-verify.rst:2 +msgid "Verify operation" +msgstr "" + +#: ../nova-verify.rst:4 +msgid "Verify operation of the Compute service." +msgstr "" + +#: ../keystone-verify.rst:5 +msgid "" +"Verify operation of the Identity service before installing other services." +msgstr "" + +#: ../glance-verify.rst:5 +msgid "" +"Verify operation of the Image service using `CirrOS `__, a small Linux image that helps you test your OpenStack " +"deployment." +msgstr "" + +#: ../ceilometer-verify.rst:3 +msgid "Verify the Telemetry installation" +msgstr "" + +#: ../launch-instance-nova.rst:208 +msgid "Verify the ``demo-net`` network:" +msgstr "" + +#: ../launch-instance-neutron.rst:189 +msgid "Verify the ``demo-net`` tenant network gateway:" +msgstr "" + +#: ../launch-instance-neutron.rst:204 +msgid "Verify the ``ext-net`` external network:" +msgstr "" + +#: ../swift-initial-rings.rst:71 ../swift-initial-rings.rst:152 +#: ../swift-initial-rings.rst:230 +msgid "Verify the ring contents:" +msgstr "" + +#: ../basics-ntp.rst:159 +msgid "" +"We recommend that you verify NTP synchronization before proceeding further. " +"Some nodes, particularly those that reference the controller node, can take " +"several minutes to synchronize." +msgstr "" + +#: ../neutron-initial-networks.rst:247 +msgid "" +"We recommend that you verify network connectivity and resolve any issues " +"before proceeding further. Following the external network subnet example " +"using ``203.0.113.0/24``, the tenant router gateway should occupy the lowest " +"IP address in the floating IP address range, ``203.0.113.101``. If you " +"configured your external physical network and virtual networks correctly, " +"you should be able to ``ping`` this IP address from any host on your " +"external physical network." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:282 ../basics-networking-nova.rst:204 +msgid "" +"We recommend that you verify network connectivity to the Internet and among " +"the nodes before proceeding further." +msgstr "" + +#: ../overview.rst:273 +msgid "" +"When you implement this architecture, skip the section :doc:`networking-" +"neutron`. To use optional services, you might need to build additional nodes." +msgstr "" + +#: ../overview.rst:189 +msgid "" +"When you implement this architecture, skip the section :doc:`networking-" +"nova`. Optional services might require additional nodes or additional " +"resources on existing nodes." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:14 +msgid "" +"When you install a package for an API service, you are prompted to register " +"that service. However, after you install or upgrade the package for an API " +"service, Debian immediately removes your response to this prompt from the " +"debconf database. Consequently, you are prompted to re-register the service " +"with the Identity service. If you already registered the API service, " +"respond ``no`` when you upgrade." +msgstr "" + +#: ../debconf/debconf-concepts.rst:25 +msgid "" +"When you install or upgrade a Debian package, all configuration file values " +"are preserved. Using the ``debconf`` database as a registry is considered a " +"bug in Debian. If you edit something in any OpenStack configuration file, " +"the ``debconf`` package reads that value when it prepares to prompt the " +"user. For example, to change the log in name for the RabbitMQ messaging " +"queue for a service, you can edit its value in the corresponding " +"configuration file." +msgstr "" + +#: ../debconf/debconf-api-endpoints.rst:31 +msgid "" +"You are prompted for the Identity service ``admin_token`` value. The " +"Identity Service uses this value to register the API service. When you set " +"up the ``keystone`` package, this value is configured automatically." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:63 ../launch-instance-nova.rst:74 +msgid "You can also reference a flavor by ID." +msgstr "" + +# #-#-#-#-# basics-networking-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# basics-networking-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../basics-networking-neutron.rst:41 ../basics-networking-nova.rst:30 +msgid "" +"You can modify these ranges and gateways to work with your particular " +"network infrastructure." +msgstr "" + +#: ../debconf/debconf-concepts.rst:97 +msgid "" +"You can pre-seed all ``debconf`` prompts. To pre-seed means to store " +"responses in the ``debconf`` database so that ``debconf`` does not prompt " +"the user for responses. Pre-seeding enables a hands-free installation for " +"users. The package maintainer creates scripts that automatically configure " +"the services." +msgstr "" + +#: ../keystone-users.rst:178 +msgid "You can repeat this procedure to create additional projects and users." +msgstr "" + +#: ../heat-install.rst:102 +msgid "You must add the ``heat_stack_owner`` role to users that manage stacks." +msgstr "" + +#: ../swift-storage-node.rst:20 +msgid "" +"You must configure each storage node before you install and configure the " +"Object Storage service on it. Similar to the controller node, each storage " +"node contains one network interface on the :term:`management network`. " +"Optionally, each storage node can contain a second network interface on a " +"separate network for replication. For more information, see :doc:" +"`basic_environment`." +msgstr "" + +#: ../cinder-storage-node.rst:19 +msgid "" +"You must configure the storage node before you install and configure the " +"volume service on it. Similar to the controller node, the storage node " +"contains one network interface on the :term:`management network`. The " +"storage node also needs an empty block storage device of suitable size for " +"your environment. For more information, see :doc:`basic_environment`." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:409 ../launch-instance-nova.rst:373 +msgid "You must create a partition table and file system to use the volume." +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:166 +msgid "" +"You must enable remote access before you install OpenStack services on " +"multiple nodes." +msgstr "" + +#: ../basics-ntp.rst:8 +msgid "" +"You must install :term:`Network Time Protocol (NTP)` to properly synchronize " +"services among nodes. We recommend that you configure the controller node to " +"reference more accurate (lower stratum) servers and other nodes to reference " +"the controller node." +msgstr "" + +#: ../keystone-services.rst:20 +msgid "" +"You must pass the value of the authentication token to the :command:" +"`openstack` command with the ``--os-token`` parameter or set the OS_TOKEN " +"environment variable. Similarly, you must also pass the value of the " +"Identity service URL to the :command:`openstack` command with the ``--os-" +"url`` parameter or set the OS_URL environment variable. This guide uses " +"environment variables to reduce command length." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:362 ../launch-instance-nova.rst:326 +msgid "You must reference volumes using the IDs instead of names." +msgstr "" + +#: ../launch-instance-nova.rst:93 +msgid "" +"You must source the ``admin`` tenant credentials for this step and then " +"source the ``demo`` tenant credentials for the remaining steps." +msgstr "" + +#: ../basic_environment.rst:30 +msgid "" +"You must use an account with administrative privileges to configure each " +"node. Either run the commands as the ``root`` user or configure the ``sudo`` " +"utility." +msgstr "" + +#: ../neutron-initial-networks.rst:90 +msgid "" +"You should disable :term:`DHCP` on this subnet because instances do not " +"connect directly to the external network and floating IP addresses require " +"manual assignment." +msgstr "" + +#: ../cinder-next-steps.rst:5 +msgid "" +"Your OpenStack environment now includes Block Storage. You can :doc:`launch " +"an instance ` or add more services to your environment in " +"the following chapters." +msgstr "" + +#: ../swift-next-steps.rst:5 +msgid "" +"Your OpenStack environment now includes Object Storage. You can :doc:`launch " +"an instance ` or add more services to your environment in " +"the following chapters." +msgstr "" + +#: ../heat-next-step.rst:5 +msgid "" +"Your OpenStack environment now includes Orchestration. You can :doc:`launch " +"an instance ` or add more services to your environment in " +"the following chapters." +msgstr "" + +#: ../ceilometer-next-steps.rst:5 +msgid "" +"Your OpenStack environment now includes Telemetry. You can :doc:`launch an " +"instance ` or add more services to your environment in the " +"previous chapters." +msgstr "" + +#: ../networking-next-steps.rst:5 +msgid "" +"Your OpenStack environment now includes the core components necessary to " +"launch a basic instance. You can :doc:`launch an instance ` or add more OpenStack services to your environment." +msgstr "" + +#: ../dashboard-next-step.rst:5 +msgid "" +"Your OpenStack environment now includes the dashboard. You can :doc:`launch " +"an instance ` or add more services to your environment in " +"the following chapters." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:76 ../launch-instance-nova.rst:87 +msgid "Your first instance uses the ``cirros-0.3.4-x86_64`` image." +msgstr "" + +#: ../launch-instance-neutron.rst:104 +msgid "" +"Your first instance uses the ``default`` security group. By default, this " +"security group implements a firewall that blocks remote access to instances. " +"If you would like to permit remote access to your instance, launch it and " +"then :ref:`configure remote access `." +msgstr "" + +#: ../launch-instance-nova.rst:123 +msgid "" +"Your first instance uses the ``default`` security group. By default, this " +"security group implements a firewall that blocks remote access to instances. " +"If you would like to permit remote access to your instance, launch it and " +"then :ref:`configure remote access `." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:90 ../launch-instance-nova.rst:109 +msgid "" +"Your first instance uses the ``demo-net`` tenant network. However, you must " +"reference this network using the ID instead of the name." +msgstr "" + +# #-#-#-#-# launch-instance-neutron.pot (Installation Guide 0.1) #-#-#-#-# +# #-#-#-#-# launch-instance-nova.pot (Installation Guide 0.1) #-#-#-#-# +#: ../launch-instance-neutron.rst:59 ../launch-instance-nova.rst:70 +msgid "Your first instance uses the ``m1.tiny`` flavor." +msgstr "" + +#: ../basic_environment.rst:129 +msgid "`ADMIN_PASS`" +msgstr "" + +#: ../overview.rst:57 +msgid "`Block Storage `_" +msgstr "" + +#: ../basic_environment.rst:131 +msgid "`CEILOMETER_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:133 +msgid "`CEILOMETER_PASS`" +msgstr "" + +#: ../basic_environment.rst:135 +msgid "`CINDER_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:137 +msgid "`CINDER_PASS`" +msgstr "" + +#: ../overview.rst:76 +msgid "`Ceilometer `_" +msgstr "" + +#: ../overview.rst:58 +msgid "`Cinder `_" +msgstr "" + +#: ../overview.rst:31 +msgid "`Compute `_" +msgstr "" + +#: ../basic_environment.rst:139 +msgid "`DASH_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:141 +msgid "`DEMO_PASS`" +msgstr "" + +#: ../overview.rst:25 +msgid "`Dashboard `_" +msgstr "" + +#: ../overview.rst:94 +msgid "" +"`Data processing service `_" +msgstr "" + +#: ../overview.rst:89 +msgid "" +"`Database service `_" +msgstr "" + +#: ../basic_environment.rst:143 +msgid "`GLANCE_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:145 +msgid "`GLANCE_PASS`" +msgstr "" + +#: ../overview.rst:71 +msgid "`Glance `_" +msgstr "" + +#: ../basic_environment.rst:147 +msgid "`HEAT_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:149 +msgid "`HEAT_DOMAIN_PASS`" +msgstr "" + +#: ../basic_environment.rst:151 +msgid "`HEAT_PASS`" +msgstr "" + +#: ../overview.rst:83 +msgid "`Heat `_" +msgstr "" + +#: ../overview.rst:26 +msgid "`Horizon `_" +msgstr "" + +#: ../overview.rst:65 +msgid "" +"`Identity service `_" +msgstr "" + +#: ../overview.rst:70 +msgid "" +"`Image service `_" +msgstr "" + +#: ../basic_environment.rst:153 +msgid "`KEYSTONE_DBPASS`" +msgstr "" + +#: ../overview.rst:66 +msgid "`Keystone `_" +msgstr "" + +#: ../basic_environment.rst:155 +msgid "`NEUTRON_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:157 +msgid "`NEUTRON_PASS`" +msgstr "" + +#: ../basic_environment.rst:159 +msgid "`NOVA_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:161 +msgid "`NOVA_PASS`" +msgstr "" + +#: ../overview.rst:37 +msgid "`Networking `_" +msgstr "" + +#: ../overview.rst:38 +msgid "`Neutron `_" +msgstr "" + +#: ../overview.rst:32 +msgid "`Nova `_" +msgstr "" + +#: ../overview.rst:48 +msgid "" +"`Object Storage `_" +msgstr "" + +#: ../overview.rst:82 +msgid "" +"`Orchestration `_" +msgstr "" + +#: ../basic_environment.rst:163 +msgid "`RABBIT_PASS`" +msgstr "" + +#: ../basic_environment.rst:165 +msgid "`SAHARA_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:167 +msgid "`SWIFT_PASS`" +msgstr "" + +#: ../overview.rst:96 +msgid "`Sahara `_" +msgstr "" + +#: ../overview.rst:49 +msgid "`Swift `_" +msgstr "" + +#: ../basic_environment.rst:169 +msgid "`TROVE_DBPASS`" +msgstr "" + +#: ../basic_environment.rst:171 +msgid "`TROVE_PASS`" +msgstr "" + +#: ../overview.rst:75 +msgid "" +"`Telemetry `_" +msgstr "" + +#: ../overview.rst:90 +msgid "`Trove `_" +msgstr "" + +#: ../debconf/debconf-dbconfig-common.rst:132 +msgid "and run the helper script:" +msgstr "" + +#: ../app_reserved_uids.rst:22 +msgid "ceilometer" +msgstr "" + +#: ../app_reserved_uids.rst:31 +msgid "cinder" +msgstr "" + +#: ../debconf/debconf-concepts.rst:3 +msgid "debconf concepts" +msgstr "" + +#: ../app_reserved_uids.rst:40 +msgid "glance" +msgstr "" + +#: ../app_reserved_uids.rst:49 +msgid "heat" +msgstr "" + +#: ../app_reserved_uids.rst:58 +msgid "keystone" +msgstr "" + +#: ../app_reserved_uids.rst:67 +msgid "neutron" +msgstr "" + +#: ../networking-neutron.rst:23 +msgid "neutron-server" +msgstr "" + +#: ../app_reserved_uids.rst:76 +msgid "nova" +msgstr "" + +#: ../app_reserved_uids.rst:85 +msgid "swift" +msgstr "" + +#: ../app_reserved_uids.rst:94 +msgid "trove" +msgstr "" diff --git a/doc/install-guide/locale/install-guide.pot b/doc/install-guide/locale/install-guide.pot index 0678f292b4..3f83fafc94 100644 --- a/doc/install-guide/locale/install-guide.pot +++ b/doc/install-guide/locale/install-guide.pot @@ -1,7 +1,7 @@ msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2015-08-11 06:17+0000\n" +"POT-Creation-Date: 2015-08-19 06:16+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -219,7 +219,7 @@ msgstr "" msgid "In the [DEFAULT] and [oslo_messaging_rabbit] sections, configure RabbitMQ message queue access:" msgstr "" -#: ./doc/install-guide/section_neutron-compute-node.xml:106(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:123(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:124(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:268(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:270(replaceable) ./doc/install-guide/section_basics-ntp.xml:81(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:42(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:54(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:55(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:73(replaceable) ./doc/install-guide/section_keystone-openrc.xml:31(replaceable) ./doc/install-guide/section_keystone-openrc.xml:44(replaceable) ./doc/install-guide/section_heat-install.xml:149(replaceable) ./doc/install-guide/section_heat-install.xml:150(replaceable) ./doc/install-guide/section_heat-install.xml:151(replaceable) ./doc/install-guide/section_heat-install.xml:167(replaceable) ./doc/install-guide/section_heat-install.xml:168(replaceable) ./doc/install-guide/section_heat-install.xml:169(replaceable) ./doc/install-guide/section_heat-install.xml:210(replaceable) ./doc/install-guide/section_heat-install.xml:224(replaceable) ./doc/install-guide/section_heat-install.xml:237(replaceable) ./doc/install-guide/section_heat-install.xml:238(replaceable) ./doc/install-guide/section_heat-install.xml:245(replaceable) ./doc/install-guide/section_heat-install.xml:261(replaceable) ./doc/install-guide/section_heat-install.xml:262(replaceable) ./doc/install-guide/section_heat-install.xml:333(replaceable) ./doc/install-guide/section_swift-controller-node.xml:87(replaceable) ./doc/install-guide/section_swift-controller-node.xml:88(replaceable) ./doc/install-guide/section_swift-controller-node.xml:89(replaceable) ./doc/install-guide/section_swift-controller-node.xml:183(replaceable) ./doc/install-guide/section_swift-controller-node.xml:184(replaceable) ./doc/install-guide/section_ceilometer-swift.xml:72(replaceable) ./doc/install-guide/section_dashboard-install.xml:73(replaceable) ./doc/install-guide/section_ceilometer-glance.xml:22(replaceable) ./doc/install-guide/section_keystone-services.xml:44(replaceable) ./doc/install-guide/section_keystone-services.xml:94(replaceable) ./doc/install-guide/section_keystone-services.xml:95(replaceable) ./doc/install-guide/section_keystone-services.xml:96(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:93(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:94(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:95(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:182(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:196(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:213(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:214(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:247(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:251(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:357(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:359(replaceable) ./doc/install-guide/section_glance-install.xml:104(replaceable) ./doc/install-guide/section_glance-install.xml:105(replaceable) ./doc/install-guide/section_glance-install.xml:106(replaceable) ./doc/install-guide/section_glance-install.xml:149(replaceable) ./doc/install-guide/section_glance-install.xml:159(replaceable) ./doc/install-guide/section_glance-install.xml:160(replaceable) ./doc/install-guide/section_glance-install.xml:217(replaceable) ./doc/install-guide/section_glance-install.xml:227(replaceable) ./doc/install-guide/section_glance-install.xml:228(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:90(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:99(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:173(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:174(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:175(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:260(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:276(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:293(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:294(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:313(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:392(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:239(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:328(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:372(replaceable) ./doc/install-guide/section_nova-compute-install.xml:68(replaceable) ./doc/install-guide/section_nova-compute-install.xml:85(replaceable) ./doc/install-guide/section_nova-compute-install.xml:86(replaceable) ./doc/install-guide/section_nova-compute-install.xml:122(replaceable) ./doc/install-guide/section_nova-compute-install.xml:147(replaceable) ./doc/install-guide/section_neutron-network-node.xml:108(replaceable) ./doc/install-guide/section_neutron-network-node.xml:125(replaceable) ./doc/install-guide/section_neutron-network-node.xml:126(replaceable) ./doc/install-guide/section_neutron-network-node.xml:379(replaceable) ./doc/install-guide/section_neutron-network-node.xml:380(replaceable) ./doc/install-guide/section_neutron-network-node.xml:397(replaceable) ./doc/install-guide/section_sahara-install.xml:45(replaceable) ./doc/install-guide/section_sahara-install.xml:51(replaceable) ./doc/install-guide/section_sahara-install.xml:52(replaceable) ./doc/install-guide/section_sahara-install.xml:182(replaceable) ./doc/install-guide/section_sahara-install.xml:183(replaceable) ./doc/install-guide/section_sahara-install.xml:184(replaceable) ./doc/install-guide/section_debconf-keystone_authtoken.xml:16(replaceable) ./doc/install-guide/section_debconf-keystone_authtoken.xml:17(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:156(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:170(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:187(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:188(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:250(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:113(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:114(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:115(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:131(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:132(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:133(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:186(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:203(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:204(replaceable) ./doc/install-guide/section_trove-install.xml:54(replaceable) ./doc/install-guide/section_trove-install.xml:55(replaceable) ./doc/install-guide/section_trove-install.xml:56(replaceable) ./doc/install-guide/section_trove-install.xml:67(replaceable) ./doc/install-guide/section_trove-install.xml:68(replaceable) ./doc/install-guide/section_trove-install.xml:69(replaceable) ./doc/install-guide/section_trove-install.xml:70(replaceable) ./doc/install-guide/section_trove-install.xml:71(replaceable) ./doc/install-guide/section_trove-install.xml:74(replaceable) ./doc/install-guide/section_trove-install.xml:84(replaceable) ./doc/install-guide/section_trove-install.xml:161(replaceable) ./doc/install-guide/section_trove-install.xml:166(replaceable) ./doc/install-guide/section_trove-install.xml:247(replaceable) ./doc/install-guide/section_trove-install.xml:248(replaceable) ./doc/install-guide/section_trove-install.xml:249(replaceable) ./doc/install-guide/section_nova-controller-install.xml:96(replaceable) ./doc/install-guide/section_nova-controller-install.xml:97(replaceable) ./doc/install-guide/section_nova-controller-install.xml:98(replaceable) ./doc/install-guide/section_nova-controller-install.xml:158(replaceable) ./doc/install-guide/section_nova-controller-install.xml:175(replaceable) ./doc/install-guide/section_nova-controller-install.xml:176(replaceable) ./doc/install-guide/section_nova-controller-install.xml:213(replaceable) ./doc/install-guide/section_keystone-install.xml:106(replaceable) ./doc/install-guide/section_keystone-install.xml:159(replaceable) ./doc/install-guide/section_keystone-install.xml:247(replaceable) ./doc/install-guide/section_keystone-install.xml:248(replaceable) ./doc/install-guide/section_keystone-install.xml:249(replaceable) ./doc/install-guide/section_keystone-install.xml:269(replaceable) ./doc/install-guide/section_keystone-install.xml:276(replaceable) +#: ./doc/install-guide/section_neutron-compute-node.xml:106(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:123(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:124(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:268(replaceable) ./doc/install-guide/section_neutron-compute-node.xml:270(replaceable) ./doc/install-guide/section_basics-ntp.xml:81(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:42(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:54(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:55(replaceable) ./doc/install-guide/section_ceilometer-nova.xml:73(replaceable) ./doc/install-guide/section_keystone-openrc.xml:31(replaceable) ./doc/install-guide/section_keystone-openrc.xml:44(replaceable) ./doc/install-guide/section_heat-install.xml:149(replaceable) ./doc/install-guide/section_heat-install.xml:150(replaceable) ./doc/install-guide/section_heat-install.xml:151(replaceable) ./doc/install-guide/section_heat-install.xml:167(replaceable) ./doc/install-guide/section_heat-install.xml:168(replaceable) ./doc/install-guide/section_heat-install.xml:169(replaceable) ./doc/install-guide/section_heat-install.xml:210(replaceable) ./doc/install-guide/section_heat-install.xml:224(replaceable) ./doc/install-guide/section_heat-install.xml:237(replaceable) ./doc/install-guide/section_heat-install.xml:238(replaceable) ./doc/install-guide/section_heat-install.xml:245(replaceable) ./doc/install-guide/section_heat-install.xml:261(replaceable) ./doc/install-guide/section_heat-install.xml:262(replaceable) ./doc/install-guide/section_heat-install.xml:333(replaceable) ./doc/install-guide/section_swift-controller-node.xml:87(replaceable) ./doc/install-guide/section_swift-controller-node.xml:88(replaceable) ./doc/install-guide/section_swift-controller-node.xml:89(replaceable) ./doc/install-guide/section_swift-controller-node.xml:183(replaceable) ./doc/install-guide/section_swift-controller-node.xml:184(replaceable) ./doc/install-guide/section_ceilometer-swift.xml:72(replaceable) ./doc/install-guide/section_dashboard-install.xml:73(replaceable) ./doc/install-guide/section_ceilometer-glance.xml:22(replaceable) ./doc/install-guide/section_keystone-services.xml:44(replaceable) ./doc/install-guide/section_keystone-services.xml:94(replaceable) ./doc/install-guide/section_keystone-services.xml:95(replaceable) ./doc/install-guide/section_keystone-services.xml:96(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:93(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:94(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:95(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:182(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:196(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:213(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:214(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:247(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:251(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:357(replaceable) ./doc/install-guide/section_neutron-controller-node.xml:359(replaceable) ./doc/install-guide/section_glance-install.xml:104(replaceable) ./doc/install-guide/section_glance-install.xml:105(replaceable) ./doc/install-guide/section_glance-install.xml:106(replaceable) ./doc/install-guide/section_glance-install.xml:149(replaceable) ./doc/install-guide/section_glance-install.xml:159(replaceable) ./doc/install-guide/section_glance-install.xml:160(replaceable) ./doc/install-guide/section_glance-install.xml:217(replaceable) ./doc/install-guide/section_glance-install.xml:227(replaceable) ./doc/install-guide/section_glance-install.xml:228(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:90(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:99(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:173(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:174(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:175(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:260(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:276(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:293(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:294(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:313(replaceable) ./doc/install-guide/section_ceilometer-controller.xml:392(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:245(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:334(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:378(replaceable) ./doc/install-guide/section_nova-compute-install.xml:68(replaceable) ./doc/install-guide/section_nova-compute-install.xml:85(replaceable) ./doc/install-guide/section_nova-compute-install.xml:86(replaceable) ./doc/install-guide/section_nova-compute-install.xml:122(replaceable) ./doc/install-guide/section_nova-compute-install.xml:147(replaceable) ./doc/install-guide/section_neutron-network-node.xml:108(replaceable) ./doc/install-guide/section_neutron-network-node.xml:125(replaceable) ./doc/install-guide/section_neutron-network-node.xml:126(replaceable) ./doc/install-guide/section_neutron-network-node.xml:379(replaceable) ./doc/install-guide/section_neutron-network-node.xml:380(replaceable) ./doc/install-guide/section_neutron-network-node.xml:397(replaceable) ./doc/install-guide/section_sahara-install.xml:45(replaceable) ./doc/install-guide/section_sahara-install.xml:51(replaceable) ./doc/install-guide/section_sahara-install.xml:52(replaceable) ./doc/install-guide/section_sahara-install.xml:182(replaceable) ./doc/install-guide/section_sahara-install.xml:183(replaceable) ./doc/install-guide/section_sahara-install.xml:184(replaceable) ./doc/install-guide/section_debconf-keystone_authtoken.xml:16(replaceable) ./doc/install-guide/section_debconf-keystone_authtoken.xml:17(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:156(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:170(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:187(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:188(replaceable) ./doc/install-guide/section_cinder-storage-node.xml:250(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:113(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:114(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:115(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:131(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:132(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:133(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:186(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:203(replaceable) ./doc/install-guide/section_cinder-controller-node.xml:204(replaceable) ./doc/install-guide/section_trove-install.xml:54(replaceable) ./doc/install-guide/section_trove-install.xml:55(replaceable) ./doc/install-guide/section_trove-install.xml:56(replaceable) ./doc/install-guide/section_trove-install.xml:67(replaceable) ./doc/install-guide/section_trove-install.xml:68(replaceable) ./doc/install-guide/section_trove-install.xml:69(replaceable) ./doc/install-guide/section_trove-install.xml:70(replaceable) ./doc/install-guide/section_trove-install.xml:71(replaceable) ./doc/install-guide/section_trove-install.xml:74(replaceable) ./doc/install-guide/section_trove-install.xml:84(replaceable) ./doc/install-guide/section_trove-install.xml:161(replaceable) ./doc/install-guide/section_trove-install.xml:166(replaceable) ./doc/install-guide/section_trove-install.xml:247(replaceable) ./doc/install-guide/section_trove-install.xml:248(replaceable) ./doc/install-guide/section_trove-install.xml:249(replaceable) ./doc/install-guide/section_nova-controller-install.xml:96(replaceable) ./doc/install-guide/section_nova-controller-install.xml:97(replaceable) ./doc/install-guide/section_nova-controller-install.xml:98(replaceable) ./doc/install-guide/section_nova-controller-install.xml:158(replaceable) ./doc/install-guide/section_nova-controller-install.xml:175(replaceable) ./doc/install-guide/section_nova-controller-install.xml:176(replaceable) ./doc/install-guide/section_nova-controller-install.xml:213(replaceable) ./doc/install-guide/section_keystone-install.xml:106(replaceable) ./doc/install-guide/section_keystone-install.xml:159(replaceable) ./doc/install-guide/section_keystone-install.xml:247(replaceable) ./doc/install-guide/section_keystone-install.xml:248(replaceable) ./doc/install-guide/section_keystone-install.xml:249(replaceable) ./doc/install-guide/section_keystone-install.xml:269(replaceable) ./doc/install-guide/section_keystone-install.xml:276(replaceable) msgid "controller" msgstr "" @@ -2685,11 +2685,11 @@ msgstr "" msgid "Reconfiguring network interfaces will interrupt network connectivity. We recommend using a local terminal session for these procedures." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:74(title) ./doc/install-guide/section_basics-networking-nova.xml:112(title) ./doc/install-guide/section_basics-networking-neutron.xml:86(title) ./doc/install-guide/section_basics-networking-neutron.xml:127(title) ./doc/install-guide/section_basics-networking-neutron.xml:210(title) +#: ./doc/install-guide/section_basics-networking-nova.xml:74(title) ./doc/install-guide/section_basics-networking-nova.xml:115(title) ./doc/install-guide/section_basics-networking-neutron.xml:86(title) ./doc/install-guide/section_basics-networking-neutron.xml:130(title) ./doc/install-guide/section_basics-networking-neutron.xml:216(title) msgid "To configure networking:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:76(para) ./doc/install-guide/section_basics-networking-nova.xml:114(para) ./doc/install-guide/section_basics-networking-neutron.xml:88(para) ./doc/install-guide/section_basics-networking-neutron.xml:129(para) ./doc/install-guide/section_basics-networking-neutron.xml:212(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:76(para) ./doc/install-guide/section_basics-networking-nova.xml:117(para) ./doc/install-guide/section_basics-networking-neutron.xml:88(para) ./doc/install-guide/section_basics-networking-neutron.xml:132(para) ./doc/install-guide/section_basics-networking-neutron.xml:218(para) msgid "Configure the first interface as the management interface:" msgstr "" @@ -2697,19 +2697,19 @@ msgstr "" msgid "IP address: 10.0.0.11" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:78(para) ./doc/install-guide/section_basics-networking-nova.xml:116(para) ./doc/install-guide/section_basics-networking-neutron.xml:90(para) ./doc/install-guide/section_basics-networking-neutron.xml:131(para) ./doc/install-guide/section_basics-networking-neutron.xml:138(para) ./doc/install-guide/section_basics-networking-neutron.xml:214(para) ./doc/install-guide/section_basics-networking-neutron.xml:225(para) ./doc/install-guide/section_cinder-storage-node.xml:32(para) ./doc/install-guide/section_swift-storage-node.xml:36(para) ./doc/install-guide/section_swift-storage-node.xml:51(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:78(para) ./doc/install-guide/section_basics-networking-nova.xml:119(para) ./doc/install-guide/section_basics-networking-neutron.xml:90(para) ./doc/install-guide/section_basics-networking-neutron.xml:134(para) ./doc/install-guide/section_basics-networking-neutron.xml:141(para) ./doc/install-guide/section_basics-networking-neutron.xml:220(para) ./doc/install-guide/section_basics-networking-neutron.xml:231(para) ./doc/install-guide/section_cinder-storage-node.xml:32(para) ./doc/install-guide/section_swift-storage-node.xml:36(para) ./doc/install-guide/section_swift-storage-node.xml:51(para) msgid "Network mask: 255.255.255.0 (or /24)" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:79(para) ./doc/install-guide/section_basics-networking-nova.xml:117(para) ./doc/install-guide/section_basics-networking-neutron.xml:91(para) ./doc/install-guide/section_basics-networking-neutron.xml:132(para) ./doc/install-guide/section_basics-networking-neutron.xml:215(para) ./doc/install-guide/section_cinder-storage-node.xml:33(para) ./doc/install-guide/section_swift-storage-node.xml:37(para) ./doc/install-guide/section_swift-storage-node.xml:52(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:79(para) ./doc/install-guide/section_basics-networking-nova.xml:120(para) ./doc/install-guide/section_basics-networking-neutron.xml:91(para) ./doc/install-guide/section_basics-networking-neutron.xml:135(para) ./doc/install-guide/section_basics-networking-neutron.xml:221(para) ./doc/install-guide/section_cinder-storage-node.xml:33(para) ./doc/install-guide/section_swift-storage-node.xml:37(para) ./doc/install-guide/section_swift-storage-node.xml:52(para) msgid "Default gateway: 10.0.0.1" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:82(para) ./doc/install-guide/section_basics-networking-nova.xml:161(para) ./doc/install-guide/section_basics-networking-neutron.xml:94(para) ./doc/install-guide/section_basics-networking-neutron.xml:178(para) ./doc/install-guide/section_basics-networking-neutron.xml:232(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:82(para) ./doc/install-guide/section_basics-networking-nova.xml:164(para) ./doc/install-guide/section_basics-networking-neutron.xml:94(para) ./doc/install-guide/section_basics-networking-neutron.xml:181(para) ./doc/install-guide/section_basics-networking-neutron.xml:238(para) msgid "Reboot the system to activate the changes." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:86(title) ./doc/install-guide/section_basics-networking-nova.xml:165(title) ./doc/install-guide/section_basics-networking-neutron.xml:98(title) ./doc/install-guide/section_basics-networking-neutron.xml:182(title) ./doc/install-guide/section_basics-networking-neutron.xml:236(title) +#: ./doc/install-guide/section_basics-networking-nova.xml:86(title) ./doc/install-guide/section_basics-networking-nova.xml:168(title) ./doc/install-guide/section_basics-networking-neutron.xml:98(title) ./doc/install-guide/section_basics-networking-neutron.xml:185(title) ./doc/install-guide/section_basics-networking-neutron.xml:242(title) msgid "To configure name resolution:" msgstr "" @@ -2717,83 +2717,83 @@ msgstr "" msgid "Set the hostname of the node to controller." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:92(para) ./doc/install-guide/section_basics-networking-nova.xml:170(para) ./doc/install-guide/section_basics-networking-neutron.xml:104(para) ./doc/install-guide/section_basics-networking-neutron.xml:187(para) ./doc/install-guide/section_basics-networking-neutron.xml:241(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:92(para) ./doc/install-guide/section_basics-networking-nova.xml:173(para) ./doc/install-guide/section_basics-networking-neutron.xml:104(para) ./doc/install-guide/section_basics-networking-neutron.xml:190(para) ./doc/install-guide/section_basics-networking-neutron.xml:247(para) msgid "Edit the /etc/hosts file to contain the following:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:100(para) ./doc/install-guide/section_basics-networking-nova.xml:178(para) ./doc/install-guide/section_basics-networking-neutron.xml:115(para) ./doc/install-guide/section_basics-networking-neutron.xml:198(para) ./doc/install-guide/section_basics-networking-neutron.xml:252(para) -msgid "Some distributions add an extraneous entry in the /etc/hosts file that resolves the actual hostname to another loopback IP address such as 127.0.1.1. You must comment out or remove this entry to prevent name resolution problems." +#: ./doc/install-guide/section_basics-networking-nova.xml:100(para) ./doc/install-guide/section_basics-networking-nova.xml:181(para) ./doc/install-guide/section_basics-networking-neutron.xml:115(para) ./doc/install-guide/section_basics-networking-neutron.xml:201(para) +msgid "Some distributions add an extraneous entry in the /etc/hosts file that resolves the actual hostname to another loopback IP address such as 127.0.1.1. Note it's 127.0.1.1, do not remove the required 127.0.0.1 entry. You must comment out or remove this entry to prevent name resolution problems." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:110(title) ./doc/install-guide/section_basics-networking-neutron.xml:208(title) +#: ./doc/install-guide/section_basics-networking-nova.xml:113(title) ./doc/install-guide/section_basics-networking-neutron.xml:214(title) msgid "Compute node" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:115(para) ./doc/install-guide/section_basics-networking-neutron.xml:213(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:118(para) ./doc/install-guide/section_basics-networking-neutron.xml:219(para) msgid "IP address: 10.0.0.31" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:119(para) ./doc/install-guide/section_basics-networking-neutron.xml:217(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:122(para) ./doc/install-guide/section_basics-networking-neutron.xml:223(para) msgid "Additional compute nodes should use 10.0.0.32, 10.0.0.33, and so on." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:124(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:127(para) msgid "The external interface uses a special configuration without an IP address assigned to it. Configure the second interface as the external interface:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:127(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:130(para) msgid "Replace INTERFACE_NAME with the actual interface name. For example, eth1 or ens224." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:132(para) ./doc/install-guide/section_basics-networking-neutron.xml:149(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:135(para) ./doc/install-guide/section_basics-networking-neutron.xml:152(para) msgid "Edit the /etc/network/interfaces file to contain the following:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:135(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:136(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:146(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:152(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:153(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:163(replaceable) ./doc/install-guide/section_neutron-network-node.xml:473(replaceable) ./doc/install-guide/section_neutron-network-node.xml:481(replaceable) ./doc/install-guide/section_nova-networking-compute-node.xml:45(replaceable) ./doc/install-guide/section_nova-networking-compute-node.xml:46(replaceable) +#: ./doc/install-guide/section_basics-networking-nova.xml:138(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:139(replaceable) ./doc/install-guide/section_basics-networking-nova.xml:149(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:155(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:156(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:166(replaceable) ./doc/install-guide/section_neutron-network-node.xml:473(replaceable) ./doc/install-guide/section_neutron-network-node.xml:481(replaceable) ./doc/install-guide/section_nova-networking-compute-node.xml:45(replaceable) ./doc/install-guide/section_nova-networking-compute-node.xml:46(replaceable) msgid "INTERFACE_NAME" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:141(para) ./doc/install-guide/section_basics-networking-neutron.xml:158(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:144(para) ./doc/install-guide/section_basics-networking-neutron.xml:161(para) msgid "Edit the /etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME file to contain the following:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:144(para) ./doc/install-guide/section_basics-networking-neutron.xml:161(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:147(para) ./doc/install-guide/section_basics-networking-neutron.xml:164(para) msgid "Do not change the HWADDR and UUID keys." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:152(para) ./doc/install-guide/section_basics-networking-neutron.xml:169(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:155(para) ./doc/install-guide/section_basics-networking-neutron.xml:172(para) msgid "Edit the /etc/sysconfig/network/ifcfg-INTERFACE_NAME file to contain the following:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:167(para) ./doc/install-guide/section_basics-networking-neutron.xml:238(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:170(para) ./doc/install-guide/section_basics-networking-neutron.xml:244(para) msgid "Set the hostname of the node to compute1." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:188(title) ./doc/install-guide/section_basics-networking-neutron.xml:262(title) ./doc/install-guide/section_neutron-initial-networks.xml:235(title) +#: ./doc/install-guide/section_basics-networking-nova.xml:194(title) ./doc/install-guide/section_basics-networking-neutron.xml:268(title) ./doc/install-guide/section_neutron-initial-networks.xml:235(title) msgid "Verify connectivity" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:189(para) ./doc/install-guide/section_basics-networking-neutron.xml:263(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:195(para) ./doc/install-guide/section_basics-networking-neutron.xml:269(para) msgid "We recommend that you verify network connectivity to the Internet and among the nodes before proceeding further." msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:193(para) ./doc/install-guide/section_basics-networking-neutron.xml:267(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:199(para) ./doc/install-guide/section_basics-networking-neutron.xml:273(para) msgid "From the controller node, a site on the Internet:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:207(para) ./doc/install-guide/section_basics-networking-neutron.xml:296(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:213(para) ./doc/install-guide/section_basics-networking-neutron.xml:302(para) msgid "From the controller node, the management interface on the compute node:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:210(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:299(replaceable) +#: ./doc/install-guide/section_basics-networking-nova.xml:216(replaceable) ./doc/install-guide/section_basics-networking-neutron.xml:305(replaceable) msgid "compute1" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:222(para) ./doc/install-guide/section_basics-networking-neutron.xml:355(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:228(para) ./doc/install-guide/section_basics-networking-neutron.xml:361(para) msgid "From the compute node, a site on the Internet:" msgstr "" -#: ./doc/install-guide/section_basics-networking-nova.xml:236(para) ./doc/install-guide/section_basics-networking-neutron.xml:369(para) +#: ./doc/install-guide/section_basics-networking-nova.xml:242(para) ./doc/install-guide/section_basics-networking-neutron.xml:375(para) msgid "From the compute node, the management interface on the controller node:" msgstr "" @@ -2823,63 +2823,67 @@ msgstr "" msgid "Minimal architecture example with OpenStack Networking (neutron)Network layout" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:125(title) +#: ./doc/install-guide/section_basics-networking-neutron.xml:128(title) msgid "Network node" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:130(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:133(para) msgid "IP address: 10.0.0.21" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:135(para) ./doc/install-guide/section_basics-networking-neutron.xml:222(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:138(para) ./doc/install-guide/section_basics-networking-neutron.xml:228(para) msgid "Configure the second interface as the instance tunnels interface:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:137(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:140(para) msgid "IP address: 10.0.1.21" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:141(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:144(para) msgid "The external interface uses a special configuration without an IP address assigned to it. Configure the third interface as the external interface:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:144(para) ./doc/install-guide/section_neutron-network-node.xml:470(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:147(para) ./doc/install-guide/section_neutron-network-node.xml:470(para) msgid "Replace INTERFACE_NAME with the actual interface name. For example, eth2 or ens256." msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:184(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:187(para) msgid "Set the hostname of the node to network." msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:224(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:230(para) msgid "IP address: 10.0.1.31" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:227(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:233(para) msgid "Additional compute nodes should use 10.0.1.32, 10.0.1.33, and so on." msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:281(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:258(para) +msgid "Some distributions add an extraneous entry in the /etc/hosts file that resolves the actual hostname to another loopback IP address such as 127.0.1.1. You must comment out or remove this entry to prevent name resolution problems." +msgstr "" + +#: ./doc/install-guide/section_basics-networking-neutron.xml:287(para) msgid "From the controller node, the management interface on the network node:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:284(replaceable) +#: ./doc/install-guide/section_basics-networking-neutron.xml:290(replaceable) msgid "network" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:311(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:317(para) msgid "From the network node, a site on the Internet:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:325(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:331(para) msgid "From the network node, the management interface on the controller node:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:340(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:346(para) msgid "From the network node, the instance tunnels interface on the compute node:" msgstr "" -#: ./doc/install-guide/section_basics-networking-neutron.xml:384(para) +#: ./doc/install-guide/section_basics-networking-neutron.xml:390(para) msgid "From the compute node, the instance tunnels interface on the network node:" msgstr "" diff --git a/doc/networking-guide/source/locale/networking-guide.pot b/doc/networking-guide/source/locale/networking-guide.pot index 8d40a55df5..9837ad5d0f 100644 --- a/doc/networking-guide/source/locale/networking-guide.pot +++ b/doc/networking-guide/source/locale/networking-guide.pot @@ -8,7 +8,7 @@ msgid "" msgstr "" "Project-Id-Version: Networking Guide 0.9\n" "Report-Msgid-Bugs-To: \n" -"POT-Creation-Date: 2015-08-15 06:17+0000\n" +"POT-Creation-Date: 2015-08-19 06:16+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" @@ -497,7 +497,7 @@ msgstr "" msgid "" "At least two compute nodes with two network interfaces: management and " "provider. The provider interface connects to a generic network that the " -"pysical network infrastructure switches/routes to external networks " +"physical network infrastructure switches/routes to external networks " "(typically the Internet). The Open vSwitch bridge ``br-provider`` must " "contain a port on the provider network interface." msgstr "" @@ -3146,7 +3146,7 @@ msgid "" "One controller node with two network interfaces: management and provider. " "The provider interface connects to a generic network that physical network " "infrastructure switches/routes to external networks (typically the " -"Internet). The Open vSwitch bridge ``br-provider`` must contain an port on " +"Internet). The Open vSwitch bridge ``br-provider`` must contain a port on " "the provider network interface." msgstr ""