Manila: How to get it running in DevStack with Juno
Manila: How to get it running in DevStack
In our previous blog (Overview of Manila at Atlanta OpenStack Summit), Bob Callaway spoke about the Atlanta summit and the new OpenStack File Share Service project called Manila. This is a follow up with some information that will assist you getting Manila installed within a DevStack environment. We will show you some of the steps and links that are available that will provide information about the installation, and get you started with Manila - think of this as a Manila 101 :)
Important Note: This blog is for the stable/Juno branch of Manila with Devstack.
The test infrastructure being used is a VM with the following details:
Ubuntu 14.04 LTS as the OS
Interface used for the Bridge Network
Interface for my Storage Network
Devstack (the master branch)
Manila (the master branch) from Stackforge
Important Point about the Host OS version:
Ubuntu 14.04 was required due to blueprints that provided upstream changes in Neutron that required a minimum version of dnsmasq to be 2.63. Ubuntu 12.04 (Precise) has version 2.59.
Now, let’s walk thru the steps to get devstack and Manila setup on your host (almost all of the steps will be via the command line, with one confirmation of viewing shares via Horizon):
1. Clone the master branch of devstack:
2. Clone the master branch of Manila from GitHub using the stable/juno branch:
3. Copy Manila-specific files into the devstack environment:
4. Create your local.conf file with the appropriate values. More importantly, there are specific things for Manila required prior to running of stack.sh. Below is a sample local.conf with the items required for Neutron and Manila denoted with the comment #MANILA-SPECIFIC-STUFF-BELOW.
Your network configuration may be different than our example. Configure Neutron according to your network and VLAN ranges
Ensure that you add vxlan to the Q_ML2_PLUGIN_TYPE_DRIVERS parameter. This was a change to upstream Icehouse.
Note the changes for version of Horizon for the integration with Manila and Shares
5. Let’s make sure we have the necessary dependencies
6. Run stack.sh as you normally would after you have configured the local.conf for the manila components as well as any items specific for your environment.
7. Once stack.sh has completed, you should have the Manila service(s) running with a default install. Use the manila service-list command to ensure you are running.
8. Check Horizon to validate the Manila plugins are available. We don’t have any shares defined yet; but we need to confirm that the Manila plugins for Horizon are available.
9. List your Neutron networks and subnets available for your devstack installation. Take a note of each listed prior to creating your Manila share:
10. Create a share network using the Neutron private network and subnet for your environment. We used the generic private network/subnet for this example.
11. Create an NFS share, using the share network that you just created. Here we are creating the share “devstack_share” using the share network we created in the previous step.
12. Now that this share that has been created, let's take a quick look at the shares. We have two shares, myshare and devstack_share. Each uses the NFS protocol and the export paths for each share are listed in the 'export location' column.
13. The export location is part of the Manila shared server configuration. There are two shared servers in this example because we created two different shares on two different share networks. Take a moment within your environment to follow the relationships between your share and share network.
14. Earlier we asked that you check out the lists of Neutron subnets. You should now have an additional entry that will route the subnet used for the NFS exports to your private subnet used to build the share network via Manila.
15. Let's quickly check on the share and find where the backing Cinder volume was created. In my environment, I’m using a NetApp Cinder back end in this example. The backing Cinder volume for my Manila shares can be seen via a df –hk on the single-node devstack host.
16. Now you've created a Manila NFS share! But what next? We need to allow access to this share for some hosts. In this example, I will provide access to the share devstack_share to two different hosts in my test environment. From here – we would mount the NFS shares on the NFS client specific by the IP address of the access-allow command.
Here's the recording of the demo presented in Atlanta which includes a scenario very similar to what we have described in this post:
That's all for now; we will follow up with more on Manila in later blog posts, including a discussion of the integration with the NetApp clustered Data ONTAP driver for Manila. To learn more about Manila, check out our wiki page at http://wiki.openstack.org/wiki/Manila. Or, come join us on IRC at #openstack-manila and #openstack-netapp on freenode.
With NetApp, organizations can lower risk and enable a broad spectrum of cloud SLAs by combining the power and ingenuity of OpenStack cloud management with proven data integrity and fully-developed storage provisioning, data protection, and efficiency.
By leveraging the power of NetApp Clustered Data ONTAP®, SolidFire, and the NetApp SANtricity® operating system, enterprise organizations and service providers can build a cloud storage platform with an agile data infrastructure that delivers high-performing, efficient, and scalable open-source cloud services. NetApp provides storage platforms that enable quick deployment, nimble reaction to change with the ability to scale.