> Le 19 févr. 2016 à 14:20, Major Hayden <ma...@mhtx.net> a écrit :
> 
> On 02/17/2016 09:00 AM, Fabrice Grelaud wrote:
>> So, i would like to know if i'm going in the right direction.
>> We want to use both, existing vlan from our existing physical architecture 
>> inside openstack (vlan provider) and "private tenant network" with IP 
>> floating offer (from a flat network).
>> 
>> My question is about switch configuration:
>> 
>> On Bond0:
>> the switch port connected to bond0 need to be configured as trunks with:
>> - the host management network (vlan untagged but can be tagged ?)
>> - container(mngt) network (vlan-container)
>> - storage network (vlan-storage)
>> 
>> On Bond1:
>> the switch port connected to bond1 need to be configured as trunks with:
>> - vxlan network (vlan-vxlan)
>> - vlan X (existing vlan in our existing network infra)
>> - vlan Y (existing vlan in our existing network infra)
>> 
>> Is that right ?
> 
> You have a good plan here, Fabrice.  Although I don't have bonding configured 
> in my own production environment, I'm doing much the same as you are with 
> individual network interfaces.
> 
>> And do i have to define a new network (a new vlan, flat network) that offer 
>> floatting IP for private tenant (not using existing vlan X or Y)? Is that 
>> new vlan have to be connected to bond1 and/or bond0 ?
>> Is that host management network could play this role ?
> 
> You *could* use the host management network as your floating IP pool network, 
> but you'd need to create a flat network in OpenStack for that (unless your 
> host management network is tagged).  I prefer to use a specific VLAN for 
> those public-facing, floating IP addresses.  

Thanks a lot for your answer.
I prefer to use a specific vlan too. Could you confirm to me that this new vlan 
has to be part of the trunk between the switch port and the bond1 interface 
(where we have the br-vlan) ?

> You'll need routers between your internal networks and that floating IP VLAN 
> to make the floating IP addresses work (if I remember correctly).

Absolutely.

> 
>> ps: otherwise, about the documentation, for great understanding and perhaps 
>> consistency
>> In Github (https://github.com/openstack/openstack-ansible), in the file 
>> openstack_interface.cfg.example, you point out that for br-vxlan and 
>> br-storage, "only compute node have an IP on this bridge. When used by infra 
>> nodes, IPs exist in the containers and inet should be set to manual".
>> 
>> I think it will be good (but i may be wrong ;-) ) that in chapter 3 of the 
>> "install guide: configuring the network on target host", you propose the 
>> /etc/network/interfaces for both controller node (br-vxlan, br-storage: 
>> manual without IP) and compute node (br-vxlan, br-storage: static with IP).
> 
> That makes sense.  Would you be able to open a bug for us?  I'll be glad to 
> help you write some documentation if you're interested in learning that 
> process.
> 
> Our bug tracker is here in LaunchPad:
> 
>  https://bugs.launchpad.net/openstack-ansible

I open a bug (https://bugs.launchpad.net/openstack-ansible/+bug/1547598 
<https://bugs.launchpad.net/openstack-ansible/+bug/1547598>).

I’ll be delighted to contribute at the documentation, at my level. So, i’m 
interesting in learning that process.
We (my project team) plan to follow your guide then i’ll go back with pleasure 
that might be misunderstood to improve this guide.

Regards,

Fabrice Grelaud


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

Reply via email to