Example values must be provided for all Quantum configuration keys in both interactive and non-interactive installation sections.
(In reply to Stephen Gordon from comment #0) > Example values must be provided for all Quantum configuration keys in both > interactive and non-interactive installation sections. There were some queries as to what I meant by this, so to be clear what I mean is that for most of the prompts under step 13 "Configuring OpenStack Networking" of "4.2. Running PackStack Interactively" we say "enter the thing!" without explaining what the thing is. Some specific examples: * OpenStack Networking uses namespaces. Enter y to select the use of namespaces. What are network namespaces or at least why do I want them? Do I know that electing to use Quantum but selecting no to this means I'm technically unsupported (or at least many common networking configurations wont work)? Do I know that this means I'm getting a new kernel? * OpenStack Networking sets up Quantum L3 agent. Enter the IP addresses on which Quantum L3 Agent should be set up. What's the L3 agent, or more importantly where does it need to run? (On the example arch diagram we have been using it would run on the network node, if no network node is in use then the controller node, if all in one...well ;)). * Enter the name of the bridge that the Quantum L3 agent will use for external traffic. Leave this option blank if you intend to use a provider network to handle external traffic. Wait what bridge? Did it already exist or will it be created? Is there an expected naming format? OpenStack Networking sets up Quantum DHCP agent. Enter the list of IP address on which you want Quantum DHCP set up. Pretty much same comment as L3. Enter the name of the L2 plugin to be used with OpenStack Networking. My options are linuxbridge and openvswitch, but what's the difference from an "I'm a new user and have no idea what all these shiny things" point of view. OpenStack Networking installs the metadata agent. Enter the IP addresses on which metadata agent should be set up. Somewhat similar comment to L3. I recognize that some of these are non-obvious and might require follow up with the networking team and/or be too big to bite off in z-stream but please see what you can do. Part of the reason it's important to expand on these is precisely because it's non-obvious, particularly to users who are either new to OpenStack or have previously only used Nova Networking.
1) Added info on implications of namespaces. 2) Added info on L3 agent. 3) Bridge info still pending. 4) Added DHCP info. 5) L2 plugin info still pending. 6) Metadata agent info still pending.
(In reply to Bruce Reeler from comment #2) > 1) Added info on implications of namespaces. > > 2) Added info on L3 agent. > > 3) Bridge info still pending. > > 4) Added DHCP info. > > 5) L2 plugin info still pending. > > 6) Metadata agent info still pending. Hey Bruce, is the above committed at this point or still a work in progress? Looking to close the 3.0.z items off so we can concentrate on Havana.
@SteveG: 1,2 and 4 were done and are already committed. (so already on access.redhat.com...) The others I have not started on.
13.d. "Leave this option blank if you intend to use a provider network to handle external traffic." This is incorrect. Leaving the option blank will select the default, which is 'br-ex'. To use a provider network, one must enter the special value 'provider'. 13.f. I'm not sure about the hub vs switch analogy with linuxbridge and openvswitch. If linux bridges really acted like hubs, then two VMs with interfaces on the same bridge could see each use tcpdump to see traffic from the other that was destined elsewhere--this is not the case. 13.h. GRE tunnels should be supported now, I think. 13.(i/j). It could be made clearer that *PHYSICAL* is just a user-provided label for a network name--not necessarily something like a physical device name or something. Other than the above, looks good to me.
(In reply to Terry Wilson from comment #6) Thanks for the reply. Re linuxbridge vs. ovs: > > 13.f. I'm not sure about the hub vs switch analogy with linuxbridge and > openvswitch. If linux bridges really acted like hubs, then two VMs with > interfaces on the same bridge could see each use tcpdump to see traffic from > the other that was destined elsewhere--this is not the case. I got that analogy from: http://docs.openstack.org/trunk/openstack-network/admin/content/under_the_hood_openvswitch.html , the paras just below the note under the diagram in section:"Scenario 1: Compute host config". So, is just the use of "hub" here wrong, or is the entire analogy wrong? Basically, all I am trying to do is give the PackStack user some reason to choose either linuxbridge or ovs. Could you succinctly state a defining reason to choose one or the other?
NEEDINFO for Steve G: (In reply to comment #6) > > 13.(i/j). It could be made clearer that *PHYSICAL* is just a user-provided > label for a network name--not necessarily something like a physical device > name or something. Steve, I think you originally wrote steps 13 i & j, would it be better to replace PHYSICAL with something else entirely, e.g. NETWORKNAME?
(In reply to Bruce Reeler from comment #8) > NEEDINFO for Steve G: > (In reply to comment #6) > > > > > 13.(i/j). It could be made clearer that *PHYSICAL* is just a user-provided > > label for a network name--not necessarily something like a physical device > > name or something. > > Steve, I think you originally wrote steps 13 i & j, would it be better to > replace PHYSICAL with something else entirely, e.g. NETWORKNAME? Hi Bruce, What is required is explanation of the the way this value is used. I would not change the actual placeholder name as this will only further confuse (both the example provided by PackStack and the configuration key in the file use the "physical" terminology).
Bruce: re: hub analogy: I tested with two VMs on the same network and the linuxbridge bridge definitely did not behave like a hub (could not see non-broadcast traffic that was not destined for each VM), so I guess those upstream docs are just wrong. Those pages don't look like wikis, so I'm not sure how to suggest a change there. As to why one would choose openvswitch over linuxbridge, linuxbridge lacks support for VLANs, GRE, etc. If all you need is a simple switch, linuxbridge will work fine. A better analogy might be that you can use linuxbridge anywhere you use a simple unmanaged switch, whereas you can use openvswitch where you would need a managed switch that can provide those extra features (not that an analogy is required, here). re: renaming PHYSICAL It's just a label. So with the vlan ranges option you are saying that you want a network that you'll call "physnet1" that has vlan range from 1 to 1000 (physnet1:1:1000). Then, with the bridge mappings option you are saying that the interface that physnet1 uses is br-eth1 (so physnet1 is vlans 1 to 1000 on bridge br-eth1).
Expanded on information in "Procedure 4.2. Running PackStack Interactively", step 13: "Configuring OpenStack Networking", substeps 'a' through 'j'.