Open Stack

On 12/10/15 16:32, Sean M. Collins wrote:
> On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
>> ..
>>>> In the section 
>>>> http://docs.openstack.org/developer/devstack/guides/
>>> neutron.html#using-neutron-with-a-single-interface
>>>> there is a helpful display of localrc contents.  It says, among other 
>>>> things,
>>>>
>>>>        OVS_PHYSICAL_BRIDGE=br-ex
>>>>        PUBLIC_BRIDGE=br-ex
>>>>
>>>> In the next top-level section, 
>>>> http://docs.openstack.org/developer/devstack/guides/
>>> neutron.html#using-neutron-with-multiple-interfaces
>>>> , there is no display of revised localrc contents and no mention of 
>>>> changing either bridge setting.  That is an oversight, right?
>>> No, this is deliberate. Each section is meant to be independent, since
>>> each networking configuration and corresponding DevStack configuration
>>> is different. Of course, this may need to be explicitly stated in the
>>> guide, so there is always room for improvement.
>> I am not quite sure I understand your answer.  Is the intent that I can 
>> read only one section, ignore all the others, and that will tell me how to 
>> use DevStack to produce that section's configuration?  If so then it would 
>> be good if each section had a display of all the necessary localrc 
>> contents.
> Agreed. This is a failure on my part, because I was pasting in only
> parts of my localrc (since it came out of a live lab environment). I've
> started pushing patches to correct this.
>
>
>> I have started over, from exactly the picture drawn at the start of the 
>> doc.  That has produced a configuration that mostly works.  However, I 
>> tried creating a VM connected to the public network, and that failed for 
>> lack of a Neutron DHCP server there.
> The public network is used for floating IPs. The L3 agent creates NAT
> rules to intercept traffic on the public network and NAT it back to a
> guest instance that has the floating IP allocated to it.
>
> The behavior for when a guest is directly attached to the public
> network, I sort of forget what happens exactly but I do know that it
> doesn't work from experience - most likely because the network is not
> configured as a flat network. It will not receive a DHCP lease from the
> external router.
>
>> I am going to work out how to change 
>> that, and am willing to contribute an update to this doc.  Would you want 
>> that in this section --- in which case this section needs to specify that 
>> the provider DOES NOT already have DHCP service on the hardware network 
>> --- or as a new section?
> No, I think we should maybe have a warning or something that the
> external network will be used for Floating IPs, and that guest instances
> should not be directly attached to that network.

Attaching directly to an external network seems to me to be a useful
feature, and to align with the simple, flat connectivity that some
OpenStack users want.  As I wrote in a comment at
https://review.openstack.org/#/c/225384/6 (following line 102 of the
proposed spec):

  "The way I see this now, the Neutron API gives operators and tenants a
rather awesome choice. Operators can pre-configure external networks,
and provide reachability between those, and to the outside world, using
their data center fabric or however, in a way that is not explicitly
described on the Neutron API. Then tenants can choose either to attach
directly to those external networks, or to create their own more private
networks, and specify explicitly whether and how those route to the
external networks."

My point wasn't accepted in every detail - please see the following
comments for details - but I currently still think that it's broadly
correct, and hence that attaching to external networks is a Neutron feature.

    Neil