Description of problem:
Allows the installation and configuration of Manila.
Supports the generic driver and the NetApp driver.
The NetApp team is handling the QA for the above patch (see Gerrit link).
#link Manila generic driver: https://review.openstack.org/#/c/188137/
#link Manila NetApp driver: https://review.openstack.org/#/c/188138/
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Enable Manila and configure parameters
2. Start the deployment
Manila does not configure
Manila is successfully configured and enabled
Hi Ryan, I see that both of those are still in review so I assume you've patched your env for the deploy with those reviews? How are you deploying (I mean are you using tuskar) and do the defaults in the templates give a working vanilla setup (or should at least?) or do I need to be aware of something specific.
Hi marios, sorry I didn't see your message before. I'm using instack-deploy-overcloud --tuskar and tweaking the outputted Tuskar templates as necessary for quick testing. As far as a valid deployment, you'll need to specify a valid netapp_login, netapp_password and netapp_server_hostname.
You don't need to actually deploy to and use a NetApp storage system - as long as there is a valid cinder.conf stanza, that should be good enough to get it going.
I tested this patch:
and get a valid deployment with Manila present. Going to drop the NetApp patch in shortly and see if I can get that rolling.
RFEs are in no case ever blockers. I have removed the blocker flag.
https://review.openstack.org/#/c/188137/ has been merged upstream
https://review.openstack.org/#/c/313527/ also merged upstream
https://review.openstack.org/#/c/315658/ was I think incorporated into https://review.openstack.org/#/c/188137/ but it hasn't yet been abandoned
Ben Swartzlander (bswarz) from NetApp is going to propose a new version of the NetApp plugin patch - we'll add it to the external trackers when he posts it.
Tested with the 2016-11-11.1 puddle and the Manila Share service is successfully started on another controller node when it is disabled on the Active node and the Scheduler and API services still function when they're disabled on one node.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.