What is CSIT?
Continuous System Integration Tests. Basically, Suites of integration tests for testing OpenDaylight components (alone or with other projects as OpenStack for example).
If you are familiar with OpenStack testing, then you can say it’s very similar to Tempest scenario tests.
The tests are executed automatically by OpenDaylight’s Jenkins on the lab provided by the Linux Foundation and can also be executed manually be any user, using Robot framework the integration/test repository.
This post should help you to execute the tests in your environment and publish the results with Jenkins Robot plugin.
You can also find small section of common failures in the bottom of this post.
To obtain the tests, run:
git clone https://git.opendaylight.org/gerrit/integration/test
A few days ago, while adding a new job to OpenStack Infra, I realized how difficult it must be for newcomers ( to OpenStack) to understand how OpenStack CI works and make new changes. The OpenStack Infra documentation coverage of each project is great and very detailed , but connecting the dots, which assembles the complete work-flow can be a complex task for anyone.
Hopefully this post can help for those who unfamiliar with OpenStack Infra. This is written in a form of ‘Q & A’. If you read this and find yourself still wondering about additional subjects, please let me know and I’ll make sure to add it here.
Important note: this post is based on the great sessions ‘I Can’t Ping My VM! Learn How to Debug Neutron and Solve Common Problems‘ of Rossella Sblendido & OpenStack Neutron Troubleshooting by Assaf Muller . So the credit goes to them. I simply gathered it here in a written form and added little bit of description and examples. Enjoy =)
Common problems classification
The problems you may experience can be divided into several categories:
- Misconfiguration – you may experience issues due to inadequate configuration you put in the config files used by neutron. Wrong usage of the configuration tools may also be relevant and cause some issues. In addition, misconfigured underlying network will affect neutron functionality as every packet goes eventually through the physical. For example, it can be external network that isn’t reachable or firewall rule that is blocking traffic from your VMs or to them. So if the underlying network isn’t working, neutron will also fail to work properly.
- Bug in the code – you may found a bug in the code. Good chances you are not the first to bump into this bug so it’s worth checking here if someone already reported it. If you can’t find the bug there, they you are probably the first one to catch it and you should report it so that the developers can start fixing it.
Note: this introduction based on the great presentations:
Neutron Core Concepts
Neutron three core concepts ( aka core resources) are:
Important note: This post is a written form of this great presention of Carl Baldwin and Rossella Sblendido. Usually when I watching vids, I write down some notes. In this case I decided to gather most of the presention content here in one post and share it with you as you may find it also useful. Enjoy 🙂
Its main responsibility is to wire new devices (TAP interfaces created by Nova) and to configure the software bridges on the compute nodes. There are usually two bridges: br-int and br-tun.
br-int is the integration bridge. It’s the bridge that takes care of tagging & untagging the traffic which coming in or out of the VMs. To tag the traffic, it uses local vlan id and assign it to the network.