[openstack-dev] [tripleo] Overriding internal_api network name

Dmitry Tantsur dtantsur at redhat.com
Tue Sep 13 12:21:47 UTC 2016


On 09/12/2016 11:08 PM, Steven Hardy wrote:
> On Mon, Sep 12, 2016 at 04:21:43PM +0200, Dmitry Tantsur wrote:
>> Hi folks!
>>
>> I'm looking into support for multiple overclouds with shared control plane.
>> I'm porting a downstream guide: https://review.openstack.org/368840.
>>
>> However, this no longer works, probably because "internal_api" network name
>> is hardcoded in ServiceNetMapDefaults: https://github.com/openstack/tripleo-heat-templates/blob/dfe74b211267cde7a1da4e1fe9430127eda234c6/network/service_net_map.yaml#L14.
>> So deployment fails with
>>
>> CREATE_FAILED resources.RedisVirtualIP: Property error:
>> resources.VipPort.properties.network: Error validating value 'internal_api':
>> Unable to find network with name or id 'internal_api'
>>
>> Is it a bug? Or is there another way to change the network name? I need it
>> to avoid overlap between networks from two overclouds. I'd prefer to avoid
>> overriding everything from ServiceNetMapDefaults in my network environment
>> file.
>
> IMO this isn't a bug, but an RFE perhaps.

RFE filed: 
https://blueprints.launchpad.net/tripleo/+spec/override-network-name

>
> The reason is that until a couple of weeks ago, you always had to fully
> define all services in ServiceNetMap, so this is basically just a case
> where the optimization introduced here (which allows you to partially
> specify ServiceNetMap which is then merged with ServiceNetMapDefaults)
> doesn't work:
>
> https://review.openstack.org/#/c/353032/
>
> I'd say overriding everything is an OK workaround, but we can definitely
> discuss ways to do it more cleanly - I'll give it some thought (probably
> we'll need another mapping that defines the network names that can be
> easily overidden).

Overriding everything does allow me to move forward, thanks.

>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>




More information about the OpenStack-dev mailing list