From 6d88d6a347fafbda8a548e73511a5c6ec1b9cd83 Mon Sep 17 00:00:00 2001 From: Stephen Balukoff Date: Mon, 3 Aug 2015 15:24:01 -0700 Subject: [PATCH] Fixing a couple minor terminology errors Since I'm updating documentation anyway, and as these fixes don't fit well into v1 or v2 design documents, I figured a small commit here to correct the 'VM' terminology to be 'amphora' where appropriate is called for. Change-Id: I5f62f9fb62534f48de3d761c64419c08c66fed64 --- HACKING.rst | 14 +++++++------- specs/version0.5/component-design.rst | 6 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/HACKING.rst b/HACKING.rst index 178713b66d..2caf6cebfe 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -40,8 +40,8 @@ system, advanced logic behind decisions, or otherwise a high degree of intelligence should be done by centralized components (ex. controllers) within the Octavia system. Examples of this might include: * Generating haproxy configuration files -* Managing the lifecycle of Octavia VMs -* Moving a loadbalancer instance from one Octavia VM to another. +* Managing the lifecycle of Octavia amphorae +* Moving a loadbalancer instance from one Octavia amphora to another. On the other hand, tasks done extremely often, or which entail a significant load on the system should be pushed as far out to the most horizontally @@ -57,7 +57,7 @@ that will be present in a large operator environment. Also, as a secondary benefit of centralizing intelligence, minor feature additions and bugfixes can often be accomplished in a large operator -environment without having to touch every Octavia VM running in said +environment without having to touch every Octavia amphora running in said environment. All APIs are versioned @@ -71,10 +71,10 @@ in other components. It is also likely that in very large deployments, there might be tens- or hundreds-of-thousands of individual instances of a given component deployed -(most likely, the Octavia VMs). It is unreasonable to expect a large operator -to update all of these components at once. Therefore it is likely that for a -significant amount of time during a roll-out of a new version, both the old -and new versions of a given component must be able to be controlled or +(most likely, the Octavia amphorae). It is unreasonable to expect a large +operator to update all of these components at once. Therefore it is likely that +for a significant amount of time during a roll-out of a new version, both the +old and new versions of a given component must be able to be controlled or otherwise interfaced with by the new components. Both of the above considerations can be allowed for if we use versioning of diff --git a/specs/version0.5/component-design.rst b/specs/version0.5/component-design.rst index 93262db578..d44d3c0596 100644 --- a/specs/version0.5/component-design.rst +++ b/specs/version0.5/component-design.rst @@ -44,9 +44,9 @@ The only sensitive data used in Octavia 0.5 are the TLS private keys used with TERMINATED_HTTPS functionality. However, the back-end storage aspect of these secrets will be handled by Barbican. -Octavia VMs will also need to keep copies of these secrets locally in order -to facilitate seamless service restarts. These local stores should be made -on a memory filesystem. +Octavia amphorae will also need to keep copies of these secrets locally in +order to facilitate seamless service restarts. These local stores should be +made on a memory filesystem. Notifications impact