From a3a25fd0036f4c61690fbeda68ad38e5bff546e3 Mon Sep 17 00:00:00 2001 From: Irena Berezovsky Date: Tue, 29 Aug 2017 09:16:12 +0300 Subject: [PATCH] Dragonflow support: Installation & Configuration Change-Id: Ife23d014fb81f33c68cfc826873f3e4dfa314e90 Related-Bug: #1713627 --- .../local.conf.pod-in-vm.undercloud.df.sample | 49 +++++ .../devstack/dragonflow_support.rst | 185 ++++++++++++++++++ doc/source/installation/devstack/index.rst | 1 + 3 files changed, 235 insertions(+) create mode 100644 devstack/local.conf.pod-in-vm.undercloud.df.sample create mode 100644 doc/source/installation/devstack/dragonflow_support.rst diff --git a/devstack/local.conf.pod-in-vm.undercloud.df.sample b/devstack/local.conf.pod-in-vm.undercloud.df.sample new file mode 100644 index 000000000..ecdfa396b --- /dev/null +++ b/devstack/local.conf.pod-in-vm.undercloud.df.sample @@ -0,0 +1,49 @@ +[[local|localrc]] + +Q_ENABLE_DRAGONFLOW_LOCAL_CONTROLLER=True + +DATABASE_PASSWORD=pass +RABBIT_PASSWORD=pass +SERVICE_PASSWORD=pass +SERVICE_TOKEN=pass +ADMIN_PASSWORD=pass + +MULTI_HOST=1 + +# Dragonflow plugin and services +enable_plugin dragonflow https://git.openstack.org/openstack/dragonflow +enable_service df-controller +enable_service df-redis +enable_service df-redis-server +enable_service df-metadata +enable_service q-trunk + + +# Neutron services +disable_service n-net +enable_service q-svc +enable_service q-qos +disable_service q-l3 +disable_service df-l3-agent +# We have to disable the neutron L2 agent. DF does not use the L2 agent. +disable_service q-agt +# We have to disable the neutron dhcp agent. DF does not use the dhcp agent. +disable_service q-dhcp + +# LBaaSv2 service and Haproxy agent +enable_plugin neutron-lbaas git://git.openstack.org/openstack/neutron-lbaas +enable_service q-lbaasv2 +NEUTRON_LBAAS_SERVICE_PROVIDERV2="LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default" + +# Enable heat services if you want to deploy overcloud using Heat stack +enable_plugin heat https://git.openstack.org/openstack/heat +enable_service h-eng h-api h-api-cfn h-api-cw + +disable_service tempest + +DF_REDIS_PUBSUB=True +Q_USE_PROVIDERNET_FOR_PUBLIC=True +Q_FLOATING_ALLOCATION_POOL=start=172.24.4.10,end=172.24.4.200 +PUBLIC_NETWORK_NAME=public +PUBLIC_NETWORK_GATEWAY=172.24.4.1 + diff --git a/doc/source/installation/devstack/dragonflow_support.rst b/doc/source/installation/devstack/dragonflow_support.rst new file mode 100644 index 000000000..11912674f --- /dev/null +++ b/doc/source/installation/devstack/dragonflow_support.rst @@ -0,0 +1,185 @@ +========================================= +Kuryr Kubernetes Dragonflow Integration +========================================= + +Dragonflow is a distributed, modular and extendable SDN controller that +enables to connect cloud network instances (VMs, Containers and Bare Metal +servers) at scale. + +Dragonflow adopts a distributed approach to mitigate the scaling issues for +large scale deployments. With Dragonflow the load is distributed to the compute +nodes running local controller. Dragonflow manages the network services for +the OpenStack compute nodes by distributing network topology and policies to +the compute nodes, where they are translated into Openflow rules and programmed +into Open Vswitch pipeline. Network services are implemented as Applications in +the local controller. OpenStack can use Dragonflow as its network provider +through the Modular Layer-2 (ML2) Plugin. + +Integrating with Dragonflow allows Kuryr to be used to bridge containers and +VM networking in an OpenStack deployment. Kuryr acts as the container +networking interface for Dragonflow. + + +Testing with DevStack +===================== + +The next points describe how to test OpenStack with Dragonflow using DevStack. +We will start by describing how to test the baremetal case on a single host, +and then cover a nested environemnt where containers are created inside VMs. + +Single Node Test Environment +---------------------------- + +1. Create a test system. + +It's best to use a throwaway dev system for running DevStack. Your best bet is +to use either Fedora 25 or the latest Ubuntu LTS (16.04, Xenial). + +2. Create the ``stack`` user. + +:: + + $ git clone https://git.openstack.org/openstack-dev/devstack.git + $ sudo ./devstack/tools/create-stack-user.sh + +3. Switch to the ``stack`` user and clone DevStack and kuryr-kubernetes. + +:: + + $ sudo su - stack + $ git clone https://git.openstack.org/openstack-dev/devstack.git + $ git clone https://git.openstack.org/openstack/kuryr-kubernetes.git + +4. Configure DevStack to use Dragonflow. + +kuryr-kubernetes comes with a sample DevStack configuration file for Dragonflow +you can start with. You may change some values for the various variables in +that file, like password settings or what LBaaS service provider to use. +Feel free to edit it if you'd like, but it should work as-is. + +:: + + $ cd devstack + $ cp ../kuryr-kubernetes/devstack/local.conf.df.sample local.conf + +5. Run DevStack. + +Expect it to take a while. It installs required packages, clones a bunch +of git repos, and installs everything from these git repos. + +:: + + $ ./stack.sh + +Once DevStack completes successfully, you should see output that looks +something like this:: + + This is your host IP address: 192.168.5.10 + This is your host IPv6 address: ::1 + Keystone is serving at http://192.168.5.10/identity/ + The default users are: admin and demo + The password: pass + + +6. Extra configurations. + +Create NAT rule that will cause "external" traffic from your instances to get +rewritten to your network controller's ip address and sent out on the network: + +:: + + $ sudo iptables -t nat -I POSTROUTING 1 -s 172.24.4.1/24 -j MASQUERADE + + +Inspect default Configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to check the default configuration, in term of networks, subnets, +security groups and loadbalancers created upon a successful devstack stacking, +you can check the `Inspect default Configuration`_. + +.. _Inspect default Configuration: https://docs.openstack.org/kuryr-kubernetes/latest/installation/default_configuration.html + + +Testing Network Connectivity +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once the environment is ready, we can test that network connectivity works +among pods. To do that check out `Testing Network Connectivity`_. + +.. _Testing Network Connectivity: https://docs.openstack.org/kuryr-kubernetes/latest/installation/testing_connectivity.html + + +Nested Containers Test Environment (VLAN) +----------------------------------------- + +Another deployment option is the nested-vlan where containers are created +inside OpenStack VMs by using the Trunk ports support. Thus, first we need to +deploy an undercloud devstack environment with the needed components to +create VMs (e.g., Glance, Nova, Neutron, Keystone, ...), as well as the needed +Dragonflow configurations such as enabling the trunk support that will be +needed for the VM. And then install the overcloud deployment inside the VM with +the kuryr components. + + +Undercloud deployment +~~~~~~~~~~~~~~~~~~~~~ + +The steps to deploy the undercloud environment are the same as described above +for the `Single Node Test Environment` with the different sample local.conf to +use (step 4), in this case:: + + $ cd devstack + $ cp ../kuryr-kubernetes/devstack/local.conf.pod-in-vm.undercloud.df.sample local.conf + + +The main differences with the default dragonflow local.conf sample are that: + + - There is no need to enable the kuryr-kubernetes plugin as this will be + installed inside the VM (overcloud). + + - There is no need to enable the kuryr related services as they will also + be installed inside the VM: kuryr-kubernetes, kubelet, + kubernetes-api, kubernetes-controller-manager, kubernetes-scheduler and + kubelet. + + - Nova and Glance components need to be enabled to be able to create the VM + where we will install the overcloud. + + - Dragonflow Trunk service plugin need to be enable to ensure Trunk ports + support. + + +Once the undercloud deployment has finished, the next steps are related to +creating the overcloud VM by using a parent port of a Trunk so that containers +can be created inside with their own networks. To do that we follow the next +steps detailed at `Boot VM with a Trunk Port`_. + +.. _Boot VM with a Trunk Port: https://docs.openstack.org/kuryr-kubernetes/latest/installation/trunk_ports.html + + +Overcloud deployment +~~~~~~~~~~~~~~~~~~~~ + +Once the VM is up and running, we can start with the overcloud configuration. +The steps to perform are the same as without Dragonflow integration, i.e., the +same steps as for ML2/OVS: + +1. Log in into the VM:: + + $ ssh -i id_rsa_demo centos@FLOATING_IP + +2. Deploy devstack following steps 3 and 4 detailed at + `How to try out nested-pods locally (VLAN + trunk)`_. + +.. _How to try out nested-pods locally (VLAN + trunk): https://docs.openstack.org/kuryr-kubernetes/latest/installation/devstack/nested-vlan.html + + +Testing Nested Network Connectivity +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Similarly to the baremetal testing, we can create a demo deployment at the +overcloud VM, scale it to any number of pods and expose the service to check if +the deployment was successful. To do that check out +`Testing Nested Network Connectivity`_. + +.. _Testing Nested Network Connectivity: https://docs.openstack.org/kuryr-kubernetes/latest/installation/testing_nested_connectivity.html diff --git a/doc/source/installation/devstack/index.rst b/doc/source/installation/devstack/index.rst index 794703f50..b5b69b12f 100644 --- a/doc/source/installation/devstack/index.rst +++ b/doc/source/installation/devstack/index.rst @@ -33,3 +33,4 @@ ML2 drivers. nested-vlan nested-macvlan odl_support + dragonflow_support