The document provides an update on the OpenStack Manila project from the November 2018 OpenStack Summit in Berlin. It summarizes that Manila is the control plane for provisioning and managing shared filesystems across storage systems. The Rocky release added several new features including improved API changes and driver support. Priorities for the upcoming Stein release include running all gate jobs under Python 3 by default, adding pre-upgrade checks, and continuing work on access rule prioritization and JSON query validation from Rocky. The presentation encourages community feedback and contribution to the Manila project.

1. Project Update
OpenStack Summit Berlin - November 2018
Tom Barron - tbarron - tbarron@redhat.com
Victoria Martinez de la Cruz - vkmc - vkmc@redhat.com
OpenStack Manila

2. Agenda
What’s Manila
Problem Space, Problem Background
Rocky Release Update
API changes, Features, Driver improvements
Stein and Beyond
Priorities, Themes

3. Manila is the control plane to provision and
manage shared filesystems across storage
systems.
One popular oversimplification: Manila is Cinder
for file shares.
Fork of OpenStack Cinder, built by a shared pool
of developers, shares much of Cinder’s
architecture.
But it solves a new class of problems that Cinder
does not naturally address.
Think: manila file folders
What is Manila

4. ● Consistent, simple REST API
● Open Source drivers & drivers for proprietary vendor back ends (over 30 now)
● Multiple NAS protocols
● Rocky release had over 58 unique reviewers and 50 unique contributors representing
27 companies
● 8th
production quality release
● Growing adoption (latest user survey: 184 deployments responded)
● Increasing development activity and use outside manila proper in TripleO, Kolla,
Charms, gophercloud, CSI, etc. to integrate and deploy manila both inside and
outside of OpenStack proper
What is Manila

5. Rocky
18th release of OpenStack and 8th
official
release of Manila
R release

6. X-Openstack-Manila-API-Version
2.42
2.45
access-rule
metadata APIs
‘is_default’ field
added to share-type
view
2.43
2.462.44
‘with count’ in
share-list APIs
‘ou’ field added to
security-service
filter by extra-spec
listing share-types
Rocky API changes

7. ● show is_default field for share types (and share-group types)
‐ When creating a share in manila you always use a share type
‐ If you don’t mention a share type explicitly in the manila create command the default share
type is used
‐ The default share type is set in /etc/manila/manila.conf
‐ The manila type-list command lists share types, but it didn’t show which is the default!
‐ We added a new field to do this
● When listing share types one can filter them via their extra_specs
‐ DHSS value
‐ create_from_snapshot
‐ etc.
New in Rocky – share type enhancements

8. ● Experience with Huawei public cloud indicated it would be useful to be
able to add descriptive metadata to access rules
● Goal: improve user experience when managing access rules
● Users can add key-value pairs to describe access rules
● Users can filter access rules with specific metadata when listing access
rules
New in Rocky – metadata for access rules

9. Added Inspur AS13000 driver
● Supports all required manila features plus snapshot
operations
New drivers in Rocky

10. ● NetApp snapshot directory visibility control
● NetApp uses security service ou field to set organizational unit of vserver active
directory configuration with CIFS vserver
● Multiple CephFS back ends supported via configurable volume path
● Infinidat supports multiple export locations per share
● QNAP driver supports QES 2.1.0
Rocky driver enhancements

11. Mutable configuration via oslo
‐ We thought we’d done this is Queens but fixes were needed
Remove all use of mox/mox3 in tests
Manila met OpenStack community goals for Rocky

12. Stein
19th release of OpenStack and 9th
official
release of Manila
S release

13. Run all gate jobs under python3 by default
● Convert all first-party CI jobs
● Encourage 3rd-party CI jobs too
OpenStack community goals for Stein
Python 3 readiness

14. Support pre-upgrade checks
● manila-status <category> <command> [<args>]
● <category> for now is upgrade
● framework is committed, need to add checks
OpenStack community goals for Stein
Upgrades check

15. ● Manila currently has no consistent request validation layer
‐ Some resources validate input at resource controller
‐ Some just fail in the back end
● So add a jsonschema for each resource and use a jsonschema validator object to
check each resource against its schema
● If the validation passes, allow the request to follow the existing flow of control
through the resource manager to the back end.
● If the validation fails, return HTTPBadRequest
Great spec, great initial work, apparently abandoned → need volunteers!
Carryover Rocky → Stein
JSON Query validation

16. Manila access rules currently support two access levels, read-write and read-only
Access rules can overlap
− Allow 192.168.1.0/24 r/o
− Allow 192.168.1.1 rw
− This is ambiguous: which rule wins for address 192.168.1.1?
− Manila just left it up to the back end to decide
● Instead, rules have priorities in a range 1-200
● Default is 200 and lower numbers are higher
● User can explicitly set a priority to disambiguate
Good progress in Rocky, expect to finish in Stein
Carryover Rocky → Stein
Access rules prioritization

17. ● manage/unmanage
‐ https://review.openstack.org/#/c/607342
● share replication
‐ https://review.openstack.org/#/c/391805/
‐ https://review.openstack.org/#/c/615947
Specs addressing DHSS=True feature gaps

18. ● Creating a share from snapshot in another backend/pool
‐ https://review.openstack.org/#/c/609537/
● Availability Zone improvements
‐ https://review.openstack.org/#/c/616123
● Share and Back End Capabilities Improvements
‐ https://review.openstack.org/#/c/616383
Specs addressing multi-backend, AZ & capabilities
enhancements

19. Enable manila to be consumed more easily, by
end-users and by programs and other cloud
platforms
● We expect to get OpenStack Client support for manila this cycle
● Also OpenStack SDK
● Openstack Ansible work is underway
● Kubernetes dynamic external storage provider is being used
● We’re working on paths from that to manila as Cloud Storage Interface driver

20. Via this wiki → https://wiki.openstack.org/wiki/Manila/SteinCycle
Planning and tracking our work for Stein

21. Manila Forum Session
Thursday at 9:50-10:30am - Level 3, M-Raum 4
Put your ideas in the etherpad
Also:
● Tag [manila] on the OpenStack developers and operators mail lists
● Find us in #openstack-manila on freenode
● Feel free to reach out to me personally as PTL
How to give feedback

22. Project Onboarding Session
Wednesday 11:00-11:40, Level 3 - M, Raum 1
How to contribute

23. Q&A
Thank you!