From Icehouse version, OpenStack allows user to explicitely specify if he wants or not a group of virtual machines (VMs) to share the same hosts. These policies are called “Affinity” and “Anti-Affinity”.
Fine-grain control of permissions in OpenStack Swift can be done natively using Access Control Lists. Unfortunately, this was not enough to cover some use cases we have here at Cloudwatt. We needed a way to manage permission for multiple profiles, based on roles assigned to each user. In order to solve this problem, we wrote a middleware that adds proper permission control via a policy.json file, the same way other OpenStack components deal with this issue. The middleware is called Swiftpolicy and is available on Stackforge.
This article talks about establishing a Site to Site VPN connection with one end being any office/private network and the other end being a private network in the cloud. This article targets the OpenStack/OpenContrail environment.
Before reading further please have a look into this article OpenVPN in VM in OpenContrail.
Lets assume the subnet of the office/private network is 10.0.0.0/24 and the subnet of the cloud private network is 192.168.0.0/24. The goal is to establish a Site to Site VPN connection between these two networks.
OpenContrail does not allow (for security reasons) traffic from IPs and MAC address which aren’t configured ports in the network, so a VPN in “bridging” mode will not work until the Allowed address pairs plugin is released (it has however just been merged on the “master” trunk recently), and neither would a VPN in routing mode (see OpenVPN bridging vs. routing) work until the Extra routes plugin supports OpenContrail.
So how can we set a VPN to access our VMs without waiting for the mentioned features and plugins to be available (sure they will be soon however) for OpenContrail? There is a solution by using OpenVPN in routing mode and by masquerading the VPN clients. This is what we intend to do in this tutorial.
The next OpenStack Summit will be held in Paris in November. As a committed OpenStack user and contributor, Cloudwatt will to be there. Our talented experts have therefore submitted the following talks, sometimes in collaboration with partners.
We hope they represent a valuable return of experience, so if you’re interested, please go ahead and vote for us! The vote will be open from July 30th to August 8th.
Here at Clouwatt, we are big fans of Team Fortress 2. When we were looking for a way to show the uses of CloudInit, the idea of automating the installation of Team Fortress 2 came to light. In fact, CloudInit has several uses such as pre-instancing a VPN, a specific server configuration, a bit torrent client etc.
CloudInit is an Ubuntu packet that allows the initialisation of a script during the instancing of a virtual server. It enables you to make certain functions automatic and to preinstall components during the creation of an instance.
OpenStack Orchestration project Heat implements an orchestration engine to launch multiple composite cloud applications based on templates (1). A Heat template describes infrastructure resources (servers, networks, floating ips, etc) and the relationships between these resources, allowing Heat to deploy the resources in a correct order and to manage whole infrastructure lifecycle.
Today Heat provides compatibility with the AWS CloudFormation template format and has its own, native format called Heat Orchestration Template (HOT)(2).
In this blog-post I will talk about Flame, a tool that generates HOT Heat template from already existing infrastructure. Currently this project is developed by Thomas Herve (Heat core developer) and myself and provides support for Nova (key pairs and servers), Cinder (volumes) and Neutron (router, networks, subnets, security groups and floating IPs) resources.
Flame works as follows: using provided credentials (user name, project name, password, authentication url), the tool will list supported resources deployed in the project and will generate corresponding, highly customized HOT template.
The OpenStack Summit in Atlanta ended a few days ago. I was fortunate enough to be there with several of my colleagues at Cloudwatt. Now is time to make a quick summary of some of the session I attented.
One mode of authentication for an instance is the use of a password. For example, to log in to a Windows instance, users must begin a session via RDP and provide an administrator login and a password. If this password was not supplied on the command line, it can be generated by the instance itself (for example, if it uses cloudbase-init).