This restructuring should hopefully make better sense of the
documentation currently available. This is in preparation for
bringing the version 0.5 component documentation up to date and
adding a getting started and installation guide.
Change-Id: Ie1e27bab4d2b8d7d033f75750fda842dd9dd3de7
Added a flow to complete automated failover for an amphora. Added new tasks
to retrieve ports, change port device ids for re-allocating to new amphora,
and added functionality to include existing ports on amphora creation.
Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com>
Co-Authored-By: Michael Johnson <johnsomor@gmail.com>
Change-Id: Ic0d3f2b9a48ebf66df78e1ef98aef92ad7ee5057
This patch updates the Active/Standby bluprint to:
1. fix asciiflow rendering problem.
2. update the datamodel impact section to include actual changes in
current review 206252.
3. update the api impact section to include the amphorae rest api
changes.
4. discuss further performance impact that must be taken care of when
developing services health checks for VRRP.
Change-Id: I6bddfc628ebf615f5c2966f2ef1837899cd122bf
There are common methods that all neutron based network drivers will most
likely implement the same way. To prevent duplicate code, a common base driver
for all neutron drivers has been created. In the process of splitting this out,
cleaning up of some existing code was done as well.
The network driver's plug_network and unplug_network methods took an
amphora_id as a parameter, but it was always assumed to be the compute_id.
This parameter has been changed to compute_id.
The octavia interface network model originally had just a single ip_address,
but to more accurately reflect what neutron and probably other networking
as a services will return, this has been changed to fixed_ips because
interfaces and ports can have multiple ip addresses.
Other cleanup includes calling the network drivers own get_network, get_subnet,
and get_port methods instead of calling the neutron client's show_network,
show_subnet, and show_port methods. Also, all of these changes required some
test changes as well.
Change-Id: Ie6ebc5bc8babe8562c280ba12a1feab21b4ff3f9
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
The amphora driver's post_vip_plug method required network specific information
about the amphora to complete implementations. It was not accepting anything
other than a loadbalancer object. Now it takes a dictionary of
AmphoraNetworkConfig objects that is keyed of amphora id. Each instance
contains network specific information required to set up the correct routing
on the amphora.
This patch sets up the routing correctly to solve the vip blackholing issue but
only for the ssh_driver. The argument has only been added to the post_vip_plug
method of the rest_api_driver but will need to be updated to handle this new
information and to also fix the vip blackholing problems.
Change-Id: I17ce89b6c050a2a36e0a802920e2dedb063f615b
Closes-Bug: #1453951
The network driver needs the ability to retrieve specific information about
subnets and ports and pass that information to other components. Having info
about the subnet gives us cidr and gateway data that is valuable when setting
up the amphora's routes for the separation of tenant data and management data.
Because of this need, methods to retrieve network, subnet, and port details
has been added.
This also adds a another data model AmphoraNetworkConfig that contains subnet
and port information for the vip, vrrp, and ha networks on an amphora. A
network task has been added that builds this data structure by calling the new
methods added to the network driver.
Change-Id: Ica912337c7d52659a9733096878664f734f27b00
This blueprint describes how Octavia implements its Active/Standby
solution. It will describe the high level topology and the proposed code
changes to realize the high availability loadbalancer scenario.
Change-Id: Ibb98b3974b7d4d5d253e6e2a48168dbfee28cc46
Member has subnet_id and we need to compare with network_id.
In order to do this CalculateDelta task now takes in a load balancer
loops through the amphora, collects the plugged networks
and gathers the network_ids from member subnet_ids and
builds the list accordingly.
Updates network_tasks CalculateDelta
Updates network_tasks adding method to handle deltas
Updates driver adding method to get network
Updates tests, spec and other required code
Change-Id: I698625e4e2e7352cb3000e22de808c33fa7636ed
There needed to be a method to update the security group rules whenever
a listener is added or removed. The update_vip method will not update those
rules based on what listener's are present.
Also changed the allocate_vip method to take in a load_balancer instead of
port_id, network_id, and/or ip_address. The reason for this is some driver
implementations may just want the vip to be the IP directly on the amphora.
The previous signature did not allow this.
Closes-Bug: #1453609
Closes-Bug: #1453610
Change-Id: Ie5765c231c6f6ba45042db9b111e6814cf50c465
Fixed some doc'ed docstrings as well to satisfy someone's OCD. I won't name
names but they're name rhymes with Hadam Arwell.
Change-Id: I0b6482cda29c556918c2b2eb8b03cdec30b0b7c3
vrrp_ip will typically be the ip through which the amphora communicates with
its vrrp peer.
ha_ip will typically be the ip that is shared between the amphorae.
Since it is possible each amphora may have a different ha_ip and vrrp_ip,
it makes sense to add them to the model/table. Adding them now because the
network driver will be assigning the values.
Changed the network driver spec and base class to mention the plug_vip method
should return a list of amphoras.
Change-Id: I04a97caf00bc6fa25f94e6470d3ed7da48880ae6
Updated spec to include method and description for network plug operations
potentially necessary on an amphora
Updated interface to include optional method and description for network plug
operations potentially necessary on an amphora
Change-Id: Iaee3033796d4890a549c25a7327cada81bdf0384
Contains the specification of the initial version of
the haproxy amphora RESTful API. Note that this is likely
to be expanded upon later as amphora lifecycle concerns and
network integration strategy become more concrete.
Implements: bp/appliance-api
Change-Id: Iecc2149c5c89fbdc98a3657f32940b30c8169fdb
This specification defines the housekeeping manager and related classes.
It will describe how pools of resources will be managed so that they
contain appropriate numbers of elements.
Change-Id: I7b17b92b2bca1b0aa696e39d955df49e7cda6f0d
This specification defines how Oslo messages will be
consumed and delegated to deploy workers on the
controller nodes.
Fixed spelling issues in controller spec
Renamed API Manager to Queue Consumer in controller
spec and graphviz file
Change-Id: I23292b3580cad2ee9b327de021b806d7b2449c38
* Remove reference to flows
* Added new finalize_amphora_call as taled about in midcycle
* fixed spelling
Change-Id: Iadd4915740ad864408e9b7e495ca0ff99d1ebec9
A byte order marker was added into the beginning of the
specs/version0.5/controller.dot file which caused graphviz
2.36 and earlier to fail, which caused sphinx to fail as well.
Change-Id: I431931d32d6db57d10a8ff143c7d9ac2d17ca428
with the lastest from the midcycle
* remove getHealth, getStats
* add getConfiguration
* remove some unneeded exceptions
* make several calls return task flow
flows
Change-Id: I6a11fac73a696f23f7c4df7410f66ecdd9fcf50e
Per the discussion in the 12-Nov-2014 openstack octavia meeting, remove
the definition of start(), stop(), suspend(), resume(), and backup().
Change-Id: Iefc9c295ec5188b871681ff1804b563ac4feff32
Here we define the overall strategy for dealing with secure TLS data
in Octavia. There are several areas that need attention, and they are
detailed in this spec. Barbican will be our default secure storage and
certificate signing service, but the interfaces should remain generic.
Sequence diagrams now included.
Change-Id: Icbbea8e37af0ce13fd959543403f2b01b8c7d17b
Implements: blueprint tls-data-security
This design represents the overall layout of components that will
make up the first major milestone release of Octavia (v0.5). The
intent here is to have a scalable service delivery layer, to get
communication with external components right, and not yet worry
about making the command and control layer scalable.
Change-Id: I09ab7185683b66ec2567119616bc54cf9d8cc000