diff --git a/ansible/roles/octavia/defaults/main.yml b/ansible/roles/octavia/defaults/main.yml
index e0b04d5477..cffef20e3e 100644
--- a/ansible/roles/octavia/defaults/main.yml
+++ b/ansible/roles/octavia/defaults/main.yml
@@ -123,6 +123,10 @@ octavia_logging_debug: "{{ openstack_logging_debug }}"
 
 octavia_keystone_user: "octavia"
 
+# Project that Octavia will use to interact with other services.  Note that in
+# Ussuri and later releases this will change to "service".
+octavia_service_auth_project: "admin"
+
 openstack_octavia_auth: "{{ openstack_auth }}"
 
 ####################
diff --git a/ansible/roles/octavia/tasks/register.yml b/ansible/roles/octavia/tasks/register.yml
index 39a0bc577b..a2e75d4698 100644
--- a/ansible/roles/octavia/tasks/register.yml
+++ b/ansible/roles/octavia/tasks/register.yml
@@ -7,6 +7,20 @@
     service_ks_register_users: "{{ octavia_ks_users }}"
   tags: always
 
+- name: "Adding admin role to octavia user in {{ octavia_service_auth_project }} project"
+  become: true
+  kolla_toolbox:
+    module_name: "os_user_role"
+    module_args:
+      user: "{{ octavia_keystone_user }}"
+      role: admin
+      project: "{{ octavia_service_auth_project }}"
+      auth: "{{ openstack_octavia_auth }}"
+      endpoint_type: "{{ openstack_interface }}"
+      cacert: "{{ openstack_cacert }}"
+  run_once: True
+  when: octavia_service_auth_project != 'service'
+
 - name: Adding octavia related roles
   become: true
   kolla_toolbox:
diff --git a/ansible/roles/octavia/templates/octavia.conf.j2 b/ansible/roles/octavia/templates/octavia.conf.j2
index c5828c95ad..613b63bdde 100644
--- a/ansible/roles/octavia/templates/octavia.conf.j2
+++ b/ansible/roles/octavia/templates/octavia.conf.j2
@@ -32,7 +32,7 @@ auth_type = password
 username = {{ octavia_keystone_user }}
 password = {{ octavia_keystone_password }}
 user_domain_name = {{ default_user_domain_name }}
-project_name = {{ openstack_auth.project_name }}
+project_name = {{ octavia_service_auth_project }}
 project_domain_name = {{ default_project_domain_name }}
 
 memcache_security_strategy = ENCRYPT
diff --git a/releasenotes/notes/fix-octavia-service-auth-project-849a4e5bd852e9c7.yaml b/releasenotes/notes/fix-octavia-service-auth-project-849a4e5bd852e9c7.yaml
new file mode 100644
index 0000000000..fe51567a65
--- /dev/null
+++ b/releasenotes/notes/fix-octavia-service-auth-project-849a4e5bd852e9c7.yaml
@@ -0,0 +1,40 @@
+---
+fixes:
+  - |
+    In the previous stable release, the octavia user was no longer given the
+    admin role in the admin project, and a task was added to remove the role
+    during upgrades. However, the octavia configuration was not updated to use
+    the service project, causing load balancer creation to fail. See upgrade
+    notes for details.  `LP#1873176
+    <https://bugs.launchpad.net/kolla-ansible/+bug/1873176>`__
+upgrade:
+  - |
+    In the previous stable release, the octavia user was no longer given the
+    admin role in the admin project, and a task was added to remove the role
+    during upgrades. However, the octavia configuration was not updated to use
+    the service project, causing load balancer creation to fail.
+
+    There is also an issue for existing deployments in simply switching to the
+    service project. While existing load balancers appear to continue to work,
+    creating new load balancers fails due to the security group belonging to
+    the admin project. For this reason, Train and Stein have been reverted to
+    use the admin project by default, while from the Ussuri release the service
+    project will be used by default.
+
+    To provide flexibility, an ``octavia_service_auth_project`` variable has
+    been added. In the Train and Stein releases this is set to ``admin`` by
+    default, and from Ussuri it will be set to ``service`` by default.
+    For users of Train and Stein, ``octavia_service_auth_project`` may be set
+    to ``service`` in order to avoid a breaking change during the Ussuri
+    upgrade.
+
+    To switch an existing deployment from using the ``admin`` project to the
+    ``service`` project, it will at least be necessary to create the required
+    security group in the ``service`` project, and update
+    ``octavia_amp_secgroup_list`` to this group's ID. Ideally the Amphora
+    flavor and network would also be recreated in the ``service`` project,
+    although this does not appear to be necessary for operation, and will
+    impact existing Amphorae.
+
+    See `bug 1873176 <https://bugs.launchpad.net/kolla-ansible/+bug/1873176>`__
+    for details.