Difference between revisions of "Translations:ReleaseNotes/Kilo/38/ja"

Latest revision as of 14:32, 2 May 2015

Information about message (contribute)

This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.

Message definition (ReleaseNotes/Kilo)

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False. NOTE: This is not a regression and has been a flaw in the design of the evacuate feature since its introduction. There is no easy fix for this, hence this workaround to limit the potential for damage. The proposed fix in liberty is here: https://review.openstack.org/#/c/161444/.

Translation* Evacuate のリカバリコードは（VM のディスク）データを破壊する可能性があります。nova-compute 起動時、ハイパーバイザが報告したインスタンスが障害発生中に現在のホストから別ホストに移動したか（つまり、evacuate されたか）チェックされます。もし移動された VM があると判断された場合、それらの VM は現在のホスト上から削除されます。これは、移動済みインスタンスが間違って選択され、予期せずインスタンスが削除される可能性があります。libvirt 系ノードでは、これは OS ホスト名の変更によって引き起こされます。VMware 系ノードでは、１つの vCenter 環境を（異なるホスト名を持つ）２つの異なるホストから管理しようとする際に引き起こされます。これらは Liberty で適切に修正される予定ですが、現時点では、予防措置として workarounds.destroy_after_evacuate=False を設定する事でこの挙動を無効化する事ができます。【注意】これはリグレッションではなく、evacuate 機能が実装された時からの設計上の欠陥です。この問題の修正は容易ではありません。それゆえ、この迂回策はダメージの可能性を制限するものです。Liberty で提案された修正はこちら: https://review.openstack.org/#/c/161444/.

Evacuate のリカバリコードは（VM のディスク）データを破壊する可能性があります。nova-compute 起動時、ハイパーバイザが報告したインスタンスが障害発生中に現在のホストから別ホストに移動したか（つまり、evacuate されたか）チェックされます。もし移動された VM があると判断された場合、それらの VM は現在のホスト上から削除されます。これは、移動済みインスタンスが間違って選択され、予期せずインスタンスが削除される可能性があります。libvirt 系ノードでは、これは OS ホスト名の変更によって引き起こされます。VMware 系ノードでは、１つの vCenter 環境を（異なるホスト名を持つ）２つの異なるホストから管理しようとする際に引き起こされます。これらは Liberty で適切に修正される予定ですが、現時点では、予防措置として workarounds.destroy_after_evacuate=False を設定する事でこの挙動を無効化する事ができます。【注意】これはリグレッションではなく、evacuate 機能が実装された時からの設計上の欠陥です。この問題の修正は容易ではありません。それゆえ、この迂回策はダメージの可能性を制限するものです。Liberty で提案された修正はこちら: https://review.openstack.org/#/c/161444/.

Revision as of 14:31, 2 May 2015 (view source) Yosshy (talk \| contribs) ← Older edit		Latest revision as of 14:32, 2 May 2015 (view source) Yosshy (talk \| contribs)
Line 1:		Line 1:
−	* Evacuate のリカバリコードは（VM のディスク）データを破壊する可能性があります。nova-compute 起動時、ハイパーバイザが報告したインスタンスが障害発生中に現在のホストから別ホストに移動したか（つまり、evacuate されたか）チェックされます。もし移動された VM があると判断された場合、それらの VM は現在のホスト上から削除されます。これは、移動済みインスタンスが間違って選択され、予期せずインスタンスが削除される可能性があります。libvirt 系ノードでは、これは OS ホスト名の変更によって引き起こされます。VMware 系ノードでは、１つの vCenter 環境を（異なるホスト名を持つ）２つの異なるホストから管理しようとする際に引き起こされます。これらは Liberty で適切に修正される予定ですが、現時点では、予防措置として workarounds.destroy_after_evacuate=False ~~を設定する事でこの挙動を無効化する事ができます。~~	+	* Evacuate のリカバリコードは（VM のディスク）データを破壊する可能性があります。nova-compute 起動時、ハイパーバイザが報告したインスタンスが障害発生中に現在のホストから別ホストに移動したか（つまり、evacuate されたか）チェックされます。もし移動された VM があると判断された場合、それらの VM は現在のホスト上から削除されます。これは、移動済みインスタンスが間違って選択され、予期せずインスタンスが削除される可能性があります。libvirt 系ノードでは、これは OS ホスト名の変更によって引き起こされます。VMware 系ノードでは、１つの vCenter 環境を（異なるホスト名を持つ）２つの異なるホストから管理しようとする際に引き起こされます。これらは Liberty で適切に修正される予定ですが、現時点では、予防措置として workarounds.destroy_after_evacuate=False を設定する事でこの挙動を無効化する事ができます。【注意】これはリグレッションではなく、evacuate 機能が実装された時からの設計上の欠陥です。この問題の修正は容易ではありません。それゆえ、この迂回策はダメージの可能性を制限するものです。Liberty で提案された修正はこちら: https://review.openstack.org/#/c/161444/.
−	~~注意：これはリグレッションではなく、evacuate~~ 機能が実装された時からの設計上の欠陥です。この問題の修正は容易ではありません。それゆえ、この迂回策はダメージの可能性を制限するものです。Liberty で提案された修正はこちら: https://review.openstack.org/#/c/161444/.