OpenStack does not** currently provide users with a migration path from Neutron-LBaaS to Octavia. Such migration should take into account: data plane downtime, VIP migration, rollback options and more.
** it does provide a tool for cloud admins, see Alternatives.
nlbaas2octavia-lb-replicator is a script to allow users to capture everything about their Neutron LBaaS based load balancers, and eventually, create the very same load balancer (with all of its sub-objects) in Octavia.
Users need to have access to:
- Neutron API
- Octavia API
Users don't necessarily have to operate with admin permissions as long as they are working with API objects they are allowed to access.
-
A load balancer VIP might be associated with a Neutron floating-ip. In that case, The user may simply create the new Octavia loadbalancer using the same Neutron subnet of the exiting Neutron LBaaS loadbalancer (check the script help for --reuse_vip). Lastly, the user should disassociate the floating-ip from the Neutron LBaaS load balancer and associate it with the newly created Octavia load balancer. The script won't do it for you.
-
In a case where the load balancer VIP is the neuron subnet port, Users will need to delete their old loadbalancer before creating a new one in Octavia. For that, the script provides the option to store all of the load balancer data in a JSON file. Additionally, the script can read the very same JSON file to create a fully populated load balancer in Octavia.
-
nlbaas2octavia-lb-replicator does not handle with L7 rules since those were only supported by third-party drivers in Neutron LBaaS (excluding Octavia as a Neutron-LBaaS provider). While HAProxy itself is fully capable of handling L7 rules, the Neutron LBaaS plugin for it did not include it. To overcome this, users may either make additions to the script or copy L7 Rules manually.
-
Neutron API provides the option to dump a JSON output for a load balancer status, yet the Octavia fully populated JSON object requires some information that is absent from that Neutron output. To work around that (and assuming that a given load balancer might be deleted by the time users which to create a replica in Octavia), the script captures all of the information about each load balancer sub-object such as listeners, pools, health monitors and pool members.
The script is capable of reading Keystone authentication options either from OpenStack related environment variables or via CLI (using python argparse).
As a first step, the script will either query the Neutron API for all the details (see Design Decisions and Known limitations #2) or read a ready JSON file that stores information about a given load balancer.
The next step will depend on what option user chose. The script will either:
- Back up all of the information to a JSON file (if initially read from a file to begin with).
- Generate a JSON object that fits Octavia, and sent it to Octavia API in order to create a fully populated load balancer.
- Modify or delete any existing load balancer configuration.
- Moves floating IPs around.
Backup a load balancer to a JSON file
$ lb-replicator -l <LB_ID> --to_file
Read load balancer information from a JSON file and create it in Octavia
$ lb-replicator -l <LB_ID> --from_file --reuse_vip
Read load balancer information from a Neutron API and immediately create it in Octavia
$ lb-replicator -l <LB_ID>
-h, --help show this help message and exit
-l LB_ID, --lb_id LB_ID
Load balancer ID. When no --to/from a file specified,
will create it in Octavia.
-v, --reuse_vip When specified, use the same Load balancer VIP
address. Should only be used when the source load
balancer is already gone.
--to_file Save load balancer details to local a file. Does not
create it in Octavia.
--from_file Read load balancer details from a local file. Create in
Octavia.
-p PROJECT_NAME, --project_name PROJECT_NAME
Project ID or name. When not specified, will read it
from environment variable: OS_PROJECT_NAME.
-u USERNAME, --username USERNAME
Username ID or name. When not specified, will read it
from environment variable: OS_USERNAME.
-pa PASSWORD, --password PASSWORD
Password ID or name. When not specified, will read it
from environment variable: OS_PASSWORD.
-a AUTH_URL, --auth_url AUTH_URL
Auth URL. When not specified, will read it from
environment variable: OS_AUTH_URL.`
A database migration script that you may find here. Note that only cloud operators will be able to invoke such script.