Bug 1433728

Summary:	Octavia post-deployment steps documentation
Product:	Red Hat OpenStack	Reporter:	Alexander Stafeyev <astafeye>
Component:	openstack-neutron	Assignee:	Brent Eagles <beagles>
Status:	CLOSED NOTABUG	QA Contact:	Alexander Stafeyev <astafeye>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	11.0 (Ocata)	CC:	amuller, aschultz, astafeye, beagles, chrisw, jlibosva, jschluet, lbopf, mburns, nyechiel, rhel-osp-director-maint, srevivo
Target Milestone:	---	Keywords:	Triaged
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1441759 (view as bug list)		Environment:
Last Closed:	2018-02-26 18:12:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1305800, 1378993, 1433523, 1441759

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.