The OpenStack Summit in Paris ended a few days ago. I was fortunate enough to be there with several of my colleagues from Scality. There were many interesting sessions and I’ve captured the high points below.
Currently, writing a backend driver for Manila is quite difficult because the driver has to deal with network isolation so that the provisioned NFS/CIFS share can only be accessed from the intended network. In practice this makes Manila coupled with OpenStack Neutron because Manila drivers have to deal with the network plumbing.
In this session, Ben Swartzlander (the Project Technical Leader for Manila) enumerated different use cases: several of them don’t require a strong networking isolation. He proposed a clear classification of the different drivers that could exist in Manila :
- Simple drivers: These drivers assume, a priori, that all virtual networks can access the Storage Virtual Machine (SVM, the shares server). There is no specific networks for shares. These drivers are a good fit with a single flat network topology that can be used in private cloud.
- Intermediate drivers: these drivers spawn a dedicated SVM (a Nova instance) for each tenant but all of the SVMs have to be on the same flat network. Again, the network itself is assumed to be reachable by all tenants. The Manila driver has to take care of the IP allocation for the different SVMs.
- Full blown drivers: these drivers spawn per tenant SVM, and each SVM is on a dedicated network. These drivers have to provide the SVM with a subnet definition (IP address, gateway etc.) and a segmentation type (VLAN, VXLAN, GRE) and ID.
Here is an illustration of the three driver modes:
Hopefully this classification will give good guidance for driver authors and cover all the Manila use cases.
In the second part of the design session, the PTL presented the road to decouple Manila from Neutron. It basically boils down to providing a configurable “network helper” (a Python class) that would do the network plumbing for the driver. The network helper makes sure the SVM is accessible from the tenants and the SVM has access to the share servers. A clear API must first be designed and then all network helpers will have to implement this API. As a start there could be a network helper targeting Neutron and another one for nova-network.
The good thing is, none of these changes introduce an API change, they will be transparent to the users.
At the end of the session, the question of making the SVM highly available was raised. But I am not sure a definitive answer was provided.
Tempest in the brave new world
Tempest is the project in charge of functional testing of OpenStack. Before the Kilo OpenStack release, functional tests of every openstask project lived in the Tempest source code repository. Thus the Tempest developers were expected to write and maintain the functional tests for entire OpenStack. As the number of projects grew, this didn’t scale. During the Juno development cycle it was agreed that for now on, projects should have the functional tests in there own repository. This should share the burden of functional testing. In the new world, Tempest provides a framework (a set of Python classes that act as OpenStack REST clients) used in every other projects. Additionally Tempest should focus on integration testing that exercises several, interrelated components.
This design session focused on the practical details of who should move tests from Tempest directory to the project’s directory, and when. The goal is, of course, not to lose any test and not let regressions creep in during this change.
Status of Python Swift client
The official Python Swift client (both the CLI and SDK) is the first thing a developer will see when they first play with Swift. Unfortunately, it is perceived as lower quality than the server-side Swift code. Moreover, there has been a regression (support for HTTP header ‘100 – continue’ has been lost) and there’s no caching of Keystone authentication token.
This session raised the question of the future of the Swift client. The audience wondered whether it makes sense to invest on the Swift client now that the unified OpenStack client and the SDK are in good shape. The core devs answered that ultimately the Openstack SDK will be used but in the mean time issues need to be fixed in the Swift client.
As usual the summit was impressive (so many developers and companies !). However, for the first time, I can say that the food was really good and the WiFi worked well everywhere. On a more serious note, in the summit we felt the Openstack Swift community more disposed to accept storage vendors. And Openstack Manila is promising both for users and storage companies.