openstack
/
octavia
Code Issues Proposed changes

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
This commit is contained in:
Stephen Balukoff 2015-08-03 15:24:01 -07:00
parent a98e5d708f
commit 6d88d6a347
2 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
HACKING.rst
View File

@ -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

6
specs/version0.5/component-design.rst
View File

@ -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