Description of problem: The following is a description of how to go from packstack with traditional nova networking to Quantum: So the steps are below (I used OpenvSwitch): 1. Terminate nova networking service openstack-nova-network stop chkconfig openstack-nova-network off 2. Install quantum service yum install openstack-quantum 3. Install OpenvSwicth plugin yum install openstack-quantum-openvswitch 4. source keystonerc_admin [the quantum installation scripts make use of these environment variables] 5. Configure quantum service quantum-server-setup 6.1. The scrip above will ask if the nova parameters need to be updated. Restart the nova compute service. The script will configure Quantum as the networking module for Nova. service openstack-nova-compute restart 6.2 Start the openvswitch service service openvswitch start chkconfig openvswitch on Run "ovs-vsctl show" to see that it is up and running correctly 6.3 Create the integration bridge (for the private network) ovs-vsctl add-br br-int 6.4 Create the externak bridge (for the layer 3 agent) ovs-vsctl add-br br-ex 7. Start quantum service service quantum-server start chkconfig quantum-server on 7.1 Start quantum agent service quantum-openvswitch-agent start chkconfig quantum-openvswitch-agent on 8. Create a Quantum endpoint with keystone keystone service-create --name=quantum --type=network --description="Quantum Service" keystone endpoint-create --region RegionOne --service-id<ID> --publicurl "http://127.0.0.1:9696" --adminurl "http://127.0.0.1:9696" --internalurl "http://127.0.0.1:9696" 8.1 Create a keystone tenant and user. 9. Now one is able to start to use the Quantum CLI 9.1 Create a private network quantum net-create private 9.2 Create a subnet quantum subnet-create 10.0.0.0/24 10. In order for the IPAM to take place one needs to invoke the DHCP agent. Use DHCP setup tool: quantum-dhcp-setup 11. Start DHCP agent service quantum-dhcp-agent start chkconfg quantum-dhcp-agent on 12. Validate that a port has been created by the DHCP agent (quantum port-list). This port will have IP address 10.0.0.2. The gateway will 10.0.0.1. 13. At this stage VM's can be deployed and they will receive IP addresses from the DHCP service. 14. Layer 3 agent quantum-l3-setup Start service service quantum-l3-agent start chkconfig quantum-l3-agent on 15. Ensure that the openvswitch cleanup utility is enabled (this is used after reboot to ensure that device management of the quantum agents is not affected by the fact that the openvswitch creates the interfaces at boot) chkconfig quantum-ovs-cleanup on Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please see - https://fedoraproject.org/wiki/Packstack_to_Quantum
Which steps need to be run on every compute node versus only the networking node (I assume this concept only applies in the "destination state")? We also seem to assume that the desired plugin is openvswitch, I thought we supported at least one of the others too?
There are number of issues: 1. Steps on compute node: i. if nova networking is running then stop the service (step 1) ii. install and start ovs agent (step 3) iii. run quantum-node-setup (step 4 needs to be done before running this script - this sets the correct environment variables) iv. restart nova compute v. ensure that nova compute can communicate with quantum service (ensure that traffic to port 9696 passes) 2. All of the plugins that are part of the packaging are supported. We have tested linuxbridge and openvswitch
Sorry Gary, few more questions. For the most part this is basically the same as setting up Quantum for the first time except that we stop/disable nova-network right? I notice it includes both of these steps: ovs-vsctl add-br br-int ovs-vsctl add-br br-ex As we don't have namespaces working right am I correct in believing this would be on differing machines (we do have both in the instructions in the guide but in separate sections, one for L3 and one for DHCP)? Is 6.5 actually necessary? On my system when I rebooted the bridges still appeared to be there (though I'm not sure if they should have had an IP or not?) as well as a tap device? Thanks in advance, as you can probably tell I'm considering whether this should be a separate section or intertwined with the normal setup for Quantum (probably as a prerequisite).
Packstack adds iptables rules to accept connections to the services' APIs. We need to do this for quantum-server as well: iptables -t filter -I INPUT -p tcp -m tcp --dport 9696 -j ACCEPT iptables-save > /etc/sysconfig/iptables
> As we don't have namespaces working right am I correct in believing this would > be on differing machines (we do have both in the instructions in the guide but > in separate sections, one for L3 and one for DHCP)? The Host that is running the L3 agent requires: ovs-vsctl add-br br-int ovs-vsctl add-br br-ex The Host that has the DHCP agent running requires: ovs-vsctl add-br br-int The "br-int" is used to maintain all of the Quantum ports that are created. > Is 6.5 actually necessary? No. This is also relevant for 6.3 and 6.4. > On my system when I rebooted the bridges still appeared to be there (though I'm > not sure if they should have had an IP or not?) as well as a tap device? The ovs-vsctl add-br <name> only needs to be done once. The OVS has an internal database that maintains all of the devices that have been attached and created on the OVS. (If you recall we added in the OVS cleanup utility to purge these devices at reboot)
commit 9bc517b3b7799870f712c1b67e4195b4ce578fba Author: Stephen Gordon <sgordon> Date: Wed Mar 13 10:49:30 2013 -0400 BZ#911101 - Added inline steps for switching to Quantum. Added steps for disabling Nova Networking (in preparation for switch to OpenStack Networking) inline with instructions for deploying OpenStack Networking. Also expanded on description of how/why to use ovs-vsctl to create the br-int and br-ex bridges. Change-Id: I9ff7c231ee4943514ce74e70a61a4717a9e6e2af