Openstack checkpointing is simplified

At ICCLab, we have recently updated the Openstack OVA onboarding tool to include an exporting functionality that can help operators migrate and checkpoint individual VMs. Furthermore, researchers can now export VMs to their local environments, even use them offline, and at any time bring them back to the cloud using the same tool.

The OpenStack OVA onboarding tool automatically transforms selected virtual machines into downloadable VMDK images. Virtual machines and their metadata are fetched from OpenStack’s Nova service, and made packed as OVA file. The tool offers a GUI integration with OpenStack’s Horizon Dashboard, but can be also deployed separately.

Continue reading

Integration of Openstack OVA importing tool to Horizon

ICCLab is announcing an integration of the Openstack OVA onboarding tool into OpenStack’s Horizon dashboard. To deploy the OVA file to Openstack all  images are extracted from the file and  uploaded to  the Openstack cluster, all necessary file format transformations are automatically performed, glance images get created and the tool creates a heat stack out of them. As we mentioned a couple of weeks ago, uploading your local VMs into OpenStack was never easier.

screenshot-from-2016-10-14-14-31-10

Continue reading

A new tool to import OVA Applications to Openstack

If you ever thought of uploading your local VMs to OpenStack, perhaps you have come across OpenStack’s support for importing single virtual disk images. However, this cannot be used to deploy complicated VM setups, including network configurations and multiple VMs connected to each other.
We at ICCLab have therefore decided to develop a tool that will allow anyone to upload their VM setups from their local environments directly to OpenStack. We call it OpenStack VM onboarding tool and it’s available as open source.

VM onboarding tool features:

  • Easy to run – the tool comprises of simple frontend, backend and Openstack client libraries to access Openstack APIs. All these components can be easily run with one command.
  • Easy to Import – to import an OVA file the user needs to provide only the basic Openstack credentials (username, password, tenant, region, keystone URL) and an OVA file.
  • Full infrastructure import – the tool imports virtual machines, external networks, internal network connections and security groups.

You can check out a quick demo of VM onboarding functionality, workflow and interface. Continue reading

Predicting cloud usage costs with Cyclops

As part of our weekly Cyclops release, RCB team releases a significant feature this week – we announce the Prediction Microservice integration in Cyclops. With this integration, Cyclops will provide simple forecasting of usage and will predict future values. The service could be used as for customers to predict their own cost and as to cloud provider to predict revenues.  Continue reading

Full-stack Monitoring for OpenStack

Introduction

The Ceilometer project is a core OpenStack service that provide collection of metering data on managed virtual resources (e.g. compute, storage, networking). Before it was only possible to collect data from OpenStack virtual resources which are running upon an OpenStack deployment. The work presented hereafter addresses this issue outlines a means to monitor both virtual and physical resources in an integrated common approach. This work has been appearsd in the upcoming OpenStack release named “Icehouse”.

Continue reading

Run monitoring physical devices on devstack

From “Icehouse” release on Openstack has been added monitoring physical devices. At this moment available only one inspector – SNMP Inspector. IPMI Inspector will be add soon.

Continue reading

OpenStack Development Process

Preface

OpenStack is a cloud computing project to provide an infrastructure as a service (IaaS). It is free open source software released under the terms of the Apache License. The project is managed by the OpenStack Foundation, a non-profit corporate entity established in September 2012 to promote OpenStack software and its community. More than 200 companies joined the project.
How you can understand that is large project with hundreds of developers, hundreds of thousands lines of code. This topic will make clear development process in OpenStack and how to push the code into OpenStack.

Start OpenStack development

1. Signing up for accounts:

The first thing you should do is signing up for LaunchPad account. LaunchPad is a web application and website that allows users to develop and maintain software, particularly open-source software. Launchpad is developed and maintained by Canonical Ltd. The OpenStack project uses LaunchPad for mailing list, blueprints, groups, bug tracking. Each OpenStack project will have a LaunchPad project.  You can create account here.

The next you should signing up in Gerrit. Gerrit is a free, web-based team software code review tool. Software developers in a team can review each other’s modifications on their source code using a Web browser and approve or reject those changes. It integrates closely with Git, a distributed version control system. To interact with Gerrit you need to set SSH key. Because all Gerrit commands are using SSH protocol and the host port is 29418. A user can access Gerrit’s Git repositories with SSH or HTTP protocols. The user must have registered in Gerrit and a public SSH key before any command line commands can be used.

2. Communication tools: 

You should be on OpenStack’s mailing list and also on your OpenStack project’s mailing list. It’s necessary to take part in discussions about code development, project design etc. You can subscribe to mailing list according this instruction.

Also for quick answers you can use the IRC channels. It can be questions about how to work with particular methods or about why tests fail. Every week you should take part on IRC meeting of your project where you can discuss some release detail or your own bugs etc. Information about IRC channels you can find here.

3. Setting up development environment:

You can develop on any system you want but the most used and the most comfortable for this aim is Ubuntu. The first thing you need it is Git. In software development, Git is a distributed revision control and source code management (SCM) system with an emphasis on speed. You need Git to pull and push code into Gerrit.

The next step is DevStack. DevStack’s mission is to provide and maintain tools used for the installation of the central OpenStack services from source (git repository master, or specific branches) suitable for development and operational testing. It also demonstrates and documents examples of configuring and running services as well as command line client usage.

git clone git://github.com/openstack-dev/devstack.git
cd devstack; ./stack.sh

Now you can get an Openstack project:

git clone https://git.openstack.org/openstack/ceilometer

This topic not about development of ceilometer so let skip it. Let image that you already have a complete code.
You need install a pip. Pip is a tool for installing and managing Python packages.

sudo apt-get install python pip

Mostly you need pip for install a tox.

sudo pip install tox

OpenStack has a lot of projects. For each project, the OpenStack Jenkins needs to be able to perform a lot of tasks. If each project has a slightly different way to accomplish those tasks, it makes the management of a consistent testing infrastructure very difficult to deal with. Additionally, because of the high volume of development changes and testing, the testing infrastructure has to be able to pre-cache artifacts that are normally fetched over the internet. To that end, each project should support a consistent interface for driving tests and other necessary tasks.

  • tox -epy26 – Unit tests for python2.6
  • tox -epy27 – Unit tests for python2.7
  • tox -epep8 –  pep8 checks

If all tests are running you can already pull the code into Gerrit.

4.Publication code:

Simply running git review should be sufficient to push your changes to Gerrit, assuming your repository is set up as described above, you don’t need to read the rest of this section unless you want to use an alternate workflow.

If you want to push your changes without using git-review, you can push changes to gerrit like you would any other git repository, using the following syntax (assuming “gerrit” is configured as a remote repository):

git push gerrit HEAD:refs/for/$BRANCH[/$TOPIC]

Where $BRANCH is the name of the Gerrit branch to push to (usually “master”), and you may optionally specify a Gerrit topic by appending it after a slash character.

If you want to commit changes: Git commit messages should start with a short 50 character or less summary in a single paragraph. The following paragraph(s) should explain the change in more detail.

If your changes addresses a blueprint or a bug, be sure to mention them in the commit message using the following syntax:

blueprint BLUEPRINT
Closes-Bug: ####### (Partial-Bug or Related-Bug are options)

For example:
Adds keystone support

...Long multiline description of the change...

Implements: blueprint authentication
Closes-Bug: #123456
Change-Id: I4946a16d27f712ae2adf8441ce78e6c0bb0bb657

5.Code review: 

Automatic testing occurs and the results are displayed. Reviewers comment in the comment box or in the code itself.

If someone leaves an in-line comment, you can see it from expanded “Patch Set.” “Comments” column shows how many comments are in each file. If you click a file name that has comments, the new page shows a diff page with the reviewer’s name and comments. Click “Reply” and write your response. It is saved as a draft if you click “Save.” Now, go back to the page that shows a list of patch sets and click “Review,” and then, click “Publish comments.”

If your code is not ready for review, click “Work in Progress” to indicate that a reviewer does not need to review it for now. Note that the button is invisible until you login the site.

 

Oleksii Serhiienko

Oleksii Serhiienko Oleksii Serhiienko is a part-time master student and researcher at the ICCLab working on the on the Rating-Charging-Billing initiative and its OpenSource solution –Cyclops.

Oleksii has been graduated at the Kiev Polytechnic University majoring computer engineering. Before he had already been as a part of the ICCLab community. In 2014, he resided in the laboratory like exchange student by IAESTE program. During that year, he was working on OpenStack in particular at the  Ceilometer projects. His code has been added to the “Icehouse” OpenStack release. When he came back after internship to Ukraine he continued working with OpenStack technologies and python programming.

Currently, Oleksii is working on the SafeSwiss cloud project in particular on the Prediction engine development.