From b059439ddbc09fa8473545f22d6a069f4674806a Mon Sep 17 00:00:00 2001 From: Damian Dabrowski Date: Thu, 19 Jan 2023 22:36:18 +0100 Subject: [PATCH] Blueprint for separated haproxy service config Change-Id: I26febd71333bf2d98e214da19a733bf0964fe865 --- doc/source/index.rst | 9 + .../separated-haproxy-service-config.rst | 155 ++++++++++++++++++ 2 files changed, 164 insertions(+) create mode 100644 specs/antelope/separated-haproxy-service-config.rst diff --git a/doc/source/index.rst b/doc/source/index.rst index 401d264..8746d99 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -12,6 +12,15 @@ Spec Templates specs/templates/* +Antelope Specifications +----------------------- + +.. toctree:: + :glob: + :maxdepth: 1 + + specs/antelope/* + Xena Specifications ------------------- diff --git a/specs/antelope/separated-haproxy-service-config.rst b/specs/antelope/separated-haproxy-service-config.rst new file mode 100644 index 0000000..b3ce43e --- /dev/null +++ b/specs/antelope/separated-haproxy-service-config.rst @@ -0,0 +1,155 @@ +Separated Haproxy Service Config +################################# +:date: 2023-01-19 22:00 +:tags: separated haproxy service config, internal tls + +Currently all haproxy services are configured during exection of haproxy_server +role. +It may cause issues with variables scope and may complately break a service +until service role is executed. + +These issues may be avoided if the current behavior will be changed and +haproxy services will be configured separately at the beginning of each +service playbook. + +Problem description +=================== + +Preconfiguring all haproxy services may lead to some issues. +There are 2 examples: + +1. Variables scope + + Currently service definitions for haproxy roles stored in + inventory/group_vars/haproxy.yml contain variables like `neutron_plugin_type`. + It makes a problem because this is neutron's variable. + If someone wants to change its default value, they will probably set an + override in neutron group variables. It's problematic because haproxy is not + in neutron group, so all neutron's group variables won't have an effect for + haproxy role. In order to make haproxy respect this change, variable needs to + be defined for all hosts so both haproxy and neutron will have an access to it. + + Additionally, we are currently working on encrypting traffic between haproxy + and service backends. Proposed PoC [1] does the same thing as described above. + It makes use of `glance_backend_https` variable belonging to glance role. + +2. Strong dependency between haproxy role and service roles + + Some changes in haproxy service need immediate reaction from service role. + For example: user enables TLS for communication between haproxy and glance + backends. In order to do that, haproxy role needs to be executed. + It will configure glance service to communicate with its backends over TLS, + but at this point backends are not ready to handle TLS connections. + In order to fix it, glance role needs to be executed, but it takes time and + increases downtime. Removing dependencies like this between roles would make + configuration process more reliable. + + Please note that downtime will still occur. It will start after haproxy service + config and finish after first backend host will be configured. + In order to provide zero-downtime transition to TLS, further work related to + "internal TLS" project is required. + + +Proposed change +=============== + +Add an extra step at the beginning of each service role to configure haproxy +service(s) for it. +In this case haproxy services will be configured separately, so nova playbook +will configure nova haproxy services, glance playbook will configure its own +haproxy services etc. +Haproxy playbook will be only responsible for configuring services not related +to any role(letsencrypt, ceph-rgw, custom user-defined services etc.) + + +Alternatives +------------ + +No alternatives. + + +Playbook/Role impact +-------------------- + +Each playbook will contain an extra step responsible for configuring haproxy +service role(s) for it. + + +Upgrade impact +-------------- + +Some variables may become depracated or their behavior may change. + + +Security impact +--------------- + +No impact. + + +Performance impact +------------------ + +No impact. + + +End user impact +--------------- + +No impact. + + +Deployer impact +--------------- + +From now on, haproxy services will be configured separately when running +service playbooks(like os-nova-install.yml) + +Developer impact +---------------- + +No impact. + +Dependencies +------------ + +No dependencies. + + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Damian Dabrowski + + +Work items +---------- + +- configure haproxy_server role to support separated service config +- configure service playbooks to include an extra step to configure haproxy + service +- solve all corner cases(like dependency between letsencrypt and horizon) + + +Testing +======= + +Special attention is required for gating. Merging this change for all +roles may be complicated. + + +Documentation impact +==================== + +Documentation needs to be double checked. For sure we will need to update +it in few places. + + +References +========== + +[1] https://review.opendev.org/c/openstack/openstack-ansible/+/821090