Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1364283 - [Docs] [Director] More clarification of overcloud deployment
Summary: [Docs] [Director] More clarification of overcloud deployment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ga
: 9.0 (Mitaka)
Assignee: Martin Lopes
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-05 00:23 UTC by Shinobu KINJO
Modified: 2016-10-21 04:43 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-21 04:43:45 UTC


Attachments (Terms of Use)

Description Shinobu KINJO 2016-08-05 00:23:34 UTC
Description of problem:

Customer tried to disable neutron l3 ha using:

 /usr/share/openstack-tripleo-heat-templates/overcloud.yaml

like:

 NeutronL3HA:
     default: 'False'
     description: Whether to enable l3-agent HA

But it ended up with:

 l3_ha = True

From system point of view, this is expected behaviour.

It's because, there is IF-ELSE statement in tripleo client:


 if number_controllers > 1:
  ...
      parameters.update({
       'NeutronL3HA': True,
        'NeutronAllowL3AgentFailover': False,
      })
 else:
   parameters.update({
    'NeutronL3HA': False,
    'NeutronAllowL3AgentFailover': False,

Since customers usually are NOT engineers most usually. They are end users.

I would recommend to describe some note in official document.

[NOTE
If you would like to disable NeutronL3HA, you should use:

parameter_defaults:
  NeutronL3HA: False

in environment file
end note]

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Andrew Dahms 2016-08-22 05:39:35 UTC
Assigning to Martin for review.

Comment 7 Shinobu KINJO 2016-09-13 05:32:12 UTC
There is a same behaviour reported by customer.

NeutronDVR is also set to True even if it's set to False in overcloud.yaml.

I've not seen any *magic* in tripleo-heat-template and python-tripleoclient.

Comment 8 Martin Lopes 2016-09-13 05:40:00 UTC
Hi Dan, could you review the feedback in comment 7?

Comment 9 Dan Macpherson 2016-09-13 06:00:09 UTC
Yep, this is a base parameter and has been included in a list in the appendix:

https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/paged/director-installation-and-usage/appendix-d-base-parameters

NeutronDVR

    Type: string

    Whether to configure OpenStack Networking Distributed Virtual Routers 

I think the problem is that the tripleoclient sets this to True even if though the default is set to False in the overcloud.yaml. In that case, I'd suggest opening an engineering bug so that the the defaults for both the tripleoclient and the overcloud.yaml file are aligned closer. I say this because there might be a ton of other params that tripleoclient overrides that we can't really accommodate.

Comment 10 Martin Lopes 2016-09-13 06:03:24 UTC
adding in needinfo for comment 9.

Comment 11 Shinobu KINJO 2016-09-15 06:03:00 UTC
(In reply to Dan Macpherson from comment #9)
> Yep, this is a base parameter and has been included in a list in the
> appendix:
> 
> https://access.redhat.com/documentation/en/red-hat-openstack-platform/9/
> paged/director-installation-and-usage/appendix-d-base-parameters
> 
> NeutronDVR
> 
>     Type: string
> 
>     Whether to configure OpenStack Networking Distributed Virtual Routers 
> 
> I think the problem is that the tripleoclient sets this to True even if
> though the default is set to False in the overcloud.yaml. In that case, I'd
> suggest opening an engineering bug so that the the defaults for both the

Got it.

> tripleoclient and the overcloud.yaml file are aligned closer. I say this
> because there might be a ton of other params that tripleoclient overrides
> that we can't really accommodate.

Kind of agree.

Because I work through code bases but do not see any statement which implies magic realizing unexpected defined behaviour...

I will open a bug.

Comment 12 Martin Lopes 2016-10-21 04:43:45 UTC
re-closing bug, per comment 11


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