Bug 1433728 - Octavia post-deployment steps documentation
Summary: Octavia post-deployment steps documentation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 13.0 (Queens)
Assignee: Brent Eagles
QA Contact: Alexander Stafeyev
URL:
Whiteboard:
: 1433729 1434901 1434904 1434919 (view as bug list)
Depends On:
Blocks: 1305800 1378993 1433523 1441759
TreeView+ depends on / blocked
 
Reported: 2017-03-19 14:46 UTC by Alexander Stafeyev
Modified: 2019-09-10 14:10 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1441759 (view as bug list)
Environment:
Last Closed: 2018-02-26 18:12:05 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack gerrit 447496 None None None 2017-04-06 16:29:01 UTC

Description Alexander Stafeyev 2017-03-19 14:46:00 UTC
Description of problem:
We expect octavia.conf to be configured with proper values after deployment

Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-6.0.0-0.20170307170102.3134785.0rc2.el7ost.noarch

How reproducible:

100% 
Steps to Reproduce:
1.deploy setup ( 1 controller 2 compute) with octavia yaml files (-e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml)
2. see octavia.conf on controller /etc/octavia/octavia.conf
3.

Actual results:

 health_manager - no configuration existing but default. should be matched to the setup. ( we should not have link local addresses ) 
 haproxy_amphora - user group is not configured to haproxy ( nogroup at this moment) 
 
 # amp_image_tag =:
   in upstream this is confiured to "amphora" - we should do that too. 
 

 amp_flavor_id =65 - unknown why it is 65 - no such image name/id.

Comment 1 Alexander Stafeyev 2017-03-23 14:20:54 UTC
additional field needs to be fixed : 

service auth - user, pass, auth_url - 
should be configured with octavia user and pass and non localhost address

Comment 3 Nir Magnezi 2017-03-28 08:29:42 UTC
I've found additional options that were misconfigured on /etc/octavia/octavia/conf 

Section: service_auth --> Option auth_url should be http://<keystone_ip>/identity_admin


Section: keystone_authtoken --> Option auth_url should be http://<keystone_ip>/identity_admin

Comment 5 Nir Magnezi 2017-03-28 08:58:55 UTC
another option missing value on octavia.conf

Section: health_manager --> Option: controller_ip_port_list should be a comma delimited list of health_manager IP addresses with ports, for example:


controller_ip_port_list = 192.168.0.1:5555, 192.168.0.2:5555, 192.168.0.3:5555

Comment 6 Nir Magnezi 2017-03-28 13:03:41 UTC
(In reply to Nir Magnezi from comment #3)
> I've found additional options that were misconfigured on
> /etc/octavia/octavia/conf 
> 
> Section: service_auth --> Option auth_url should be
> http://<keystone_ip>/identity_admin
> 
> 
> Section: keystone_authtoken --> Option auth_url should be
> http://<keystone_ip>/identity_admin

Please disregard the change I suggested to auth_url under the keystone_authtoken section. 
auth_uri = http://<keystone_ip>:5000 , worked

Comment 7 Nir Magnezi 2017-03-28 13:06:35 UTC
few additional comments:

/etc/octavia/octavia.conf:
note that section service_auth should have creds for admin tenant, not service tenant.

/etc/neutron/services_lbaas.conf
under section octavia the following should be set:
base_url = http://<octavia_api_ip>:9876

/etc/neutron/neutron_lbaas.conf
missing:
section: service_auth
auth_url = http://<keystone ip>:5000/v2.0
admin_user = admin
admin_tenant_name = admin
admin_password = <admin_password>

Comment 8 Brent Eagles 2017-04-06 16:29:02 UTC
For OSP 11, the configuration steps are handled by a documented post deployment script (see https://review.openstack.org/#/c/447496/)

Comment 9 Brent Eagles 2017-04-06 16:33:35 UTC
*** Bug 1434901 has been marked as a duplicate of this bug. ***

Comment 10 Brent Eagles 2017-04-06 16:39:08 UTC
*** Bug 1434904 has been marked as a duplicate of this bug. ***

Comment 11 Brent Eagles 2017-04-13 18:17:42 UTC
*** Bug 1433729 has been marked as a duplicate of this bug. ***

Comment 12 Brent Eagles 2017-04-13 18:20:35 UTC
*** Bug 1434919 has been marked as a duplicate of this bug. ***

Comment 13 Lucy Bopf 2017-04-24 02:20:16 UTC
Hi Brent,

I'm not quite sure what this bug is for. Is this bug assigned to you because it's waiting on something from your side? Should it instead be assigned to a writer from the documentation team?

We're currently working on Octavia feature documentation in bug 1429309, which is waiting on your review. If the updates for Octavia are covered in bug 1429309, we can probably close this one.

Let me know what you think.

Comment 14 Lucy Bopf 2017-05-15 04:36:09 UTC
Alexander, can you help with the questions in commment 13?

Comment 15 Alexander Stafeyev 2017-05-15 06:14:00 UTC
Actually I do not think it is a Documentation bug. 
it is on Brent bcs he is working on post deployment patch that fixes those gaps. 

I think it will have to be documented after it will be merged upstream.

Comment 16 Lucy Bopf 2017-05-26 05:19:12 UTC
Thanks, Alexander! Which component should we move this to then?

Comment 17 Alexander Stafeyev 2017-05-28 08:20:26 UTC
(In reply to Lucy Bopf from comment #16)
> Thanks, Alexander! Which component should we move this to then?

Neutron

Comment 18 Lucy Bopf 2017-05-29 05:10:09 UTC
Thanks, Alexander. Changing the component now.

Comment 25 Assaf Muller 2018-02-26 18:13:01 UTC
Manual post deployment documentation will not be relevant for OSP 13 as it'll all be automated. Octavia deployment documentation is tracked in another RHBZ.


Note You need to log in before you can comment on or make changes to this bug.