From e4c05c9c1cf089111ec082b418b86f698c8a9f9e Mon Sep 17 00:00:00 2001 From: Shilla Saebi Date: Fri, 26 Jun 2015 15:18:24 -0400 Subject: [PATCH] edit to ops guide doc - tales from the crypt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit removed Nova capitalization and changed to OpenStack Compute Referencing to services, use "Compute," instead of "nova” following doc conventions wiki removed extra . that didn’t belong capitalized Internet - per IBM style guide http://www.ibm.com/developerworks/library/styleguidelines/ removed “public” not necessary Change-Id: Iea68f560c9f215a25400629dd1c2ab5b5f640e86 --- doc/openstack-ops/app_crypt.xml | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/openstack-ops/app_crypt.xml b/doc/openstack-ops/app_crypt.xml index e9c5395c..8d109d21 100644 --- a/doc/openstack-ops/app_crypt.xml +++ b/doc/openstack-ops/app_crypt.xml @@ -97,7 +97,7 @@ instance. This was still true. When the ping reply was sent from the instance, it should be in a VLAN. True. When it came back to the cloud controller and on its way out to - the public internet, it should no longer have a VLAN. + the Internet, it should no longer have a VLAN. False. Uh oh. It looked as though the VLAN part of the packet was not being removed. That made no sense. @@ -119,10 +119,10 @@ In nova.conf, vlan_interface specifies what interface OpenStack should attach all VLANs to. The correct setting should have been: - vlan_interface=bond0. + vlan_interface=bond0 As this would be the server's bonded NIC. vlan20 is the VLAN that the data center gave us for - outgoing public internet access. It's a correct VLAN and + outgoing Internet access. It's a correct VLAN and is also attached to bond0. By mistake, I configured OpenStack to attach all tenant VLANs to vlan20 instead of bond0 thereby stacking one VLAN @@ -268,7 +268,7 @@ to oversee the development of cyberinfrastructure in Alberta, Canada) deployed an updated OpenStack cloud for their DAIR project (http://www.canarie.ca/en/dair-program/about). A few days into production, a compute node locks up. Upon rebooting @@ -334,7 +334,7 @@ A feature was introduced in Essex to periodically check and see if there were any _base files not in use. If there - were, Nova would delete them. This idea sounds innocent + were, OpenStack Compute would delete them. This idea sounds innocent enough and has some good qualities to it. But how did this feature end up turned on? It was disabled by default in Essex. As it should be. It was So, I found myself wondering what changed in the EC2 API on Havana that might cause this to happen. Was it a bug or a normal behavior that I now need to work around? - After digging into the Nova code, I noticed two areas in + After digging into the nova (OpenStack Compute) code, I noticed two areas in api/ec2/cloud.py potentially impacting my system: @@ -570,4 +570,4 @@ HTTP/1.1" status: 200 len: 931 time: 3.9426181 Performance increased greatly after deleting the old records and my new deployment continues to behave well. - \ No newline at end of file +