openEMC

Manila brings shared filesystems storage into the cloud, alongside the existing block storage and object storage services.

@Bswartzlander What do u see as the use cases 4 manila?

Cinder provides persistent storage in OpenStack environments. As opposed to ephemeral storage with Nova where the storage disappears after destroying the vm. You can boot off a volume and or later attach it to a new virtual machine.

Traditionally, shared storage has represented 65% of the stored bytes in the world, and although cloud computing is changing the way people store and access data, shared file systems fill an important gap.

I would propose the same use case question 2 the other PTLs as well.

Amazon recently announced EFS (Elastic File System), which appears to be largely a copy of what we've been doing for years with Manila. I see their announcement as validation that there is real user demand for the features Manila provides.

@Bswartzlander I see a strong use-case for Magnum using Manila given the issues of mounting block devices. Have you put much thought into this? Any specific plans to help that integration?

With Magnum you can run your own application as a service by using Magnum's kubernetes bay type to easily get a Kubernetes cluster up and running on your OpenStack cloud.

@hui_kenneth Manila essentially provides "NFS as a service" (also CIFS and other filesystems).

@Bswartzlander What benefits are there in using manila vs. mounting a cinder volume & presenting NFS mount that way?

Once you have that, you can define your application in terms of services, and rely on the system to help you scale the number of containers you run, and to restart containers if they crash.

@adrian_otto I'm really excited to hear more about Magnum, since there is so much buzz about Containers in the industry today.

@ewindisch I haven't looked at Magnum specifically, but it's not at all surprising that it might work better with something like NFS than block storage. I believe strongly that block, objects, and file systems are complementary storage technologies.

@ewindisch Great question. This is did not come up at our midcycle meetup in March, but I expect we will be discussing this in Vancouver. I agree this is a potential area for us to integrate.

@hui_kenneth Use case for Cinder include having the data stored in a remote storage solution as opposed to locally on the virtual machine. You can write an ubuntu image for example to a volume, then have the vm boot from that.

You can start here: https://wiki.opensta...

@hui_kenneth If something happens to Nova host, you can have the volume attached elsewhere. This is where features like live migration come in, in attempt to avoid service disruption

@Thingee How does Cinder support other services such as Trove, Sahara, etc?

@hui_kenneth The benefit is that with Manila it's just part of the cloud. The old method (that you describe) involved extra work, and it's not automated/integrated with the of Openstack.

@ewindisch what is the issue of mounting block devices?

The idea is that we bring containers into OpenStack as a first class resource, and provide abstractions to make them easy to manage using your chosen bay type. The first we offered is Kubernetes with Docker.

Many of the container scheduling tech uses a distributed FS such as HDFS 2 deal with date persistence across nodes. Can manila do distributed FS? That may be a good match with magnum.

@adrian_otto Is Magnum effectively for delivering containers as a service or are there any use cases where it be used by the OpenStack platform itself?

@hui_kenneth Manila lets deployers offer a variety of services too, similar to Cinder. A deployer can offer gold/silver/bronze type service levels with different characteristics.

@adrian_otto I truly believe that is a great start

@Thingee Are there specific application that u think is well suited 4 cinder?

@paulhuckaby Block devices can be mounted. The issue is mounting filesystems created on those block devices. This is problematic because of security constraints. By default, containers don't have access to do that.

@ShamailXD Cinder has a driver that is a generic block device driver that Sahara uses today https://github.com/o... ... for Trove, just like any client using Cinder you use volume types to have storage picked that would work best for databases.

@hui_kenneth Yes distributed filesystems are absolutely possible. Depending on what you mean, it might be working already, but if not we consider it within our scope and we'd like to work on it.

@paulhuckaby containers should not be privileged to do mount. Orchestration can mount from host for the container *if* you presume the host belongs to the tenant (versus container belonging to tenant). Depends on where you define security boundary.

@BSwartzlander @hui_kenneth Were you referring to file-systems such as Gluster, etc.? There are numerous backend drivers for Manila already and many more in progress.

@ShamailXD Yes, we support gluster. Also, I consider NFS to be a "distributed filesystem" now that NFS 4.1 supports pNFS.

@BSwartzlander Great point.

@hui_kenneth any applications that require the vms to keep state in some way. Cinder works great for solutions that require persistent storage for both say on a webserver and database. Consistency groups is also great in this case.

@ShamailXD the containerization of OpenStack services is happening in a project named Kolla. Magnum is Containers-as-a-Service for OpenStack so users can run container based services.

@adrian_otto Thanks for the clarification Adrian.

@adrian_otto It would be nice to see Kolla-on-Magnum eventually.

@adrian_otto Does Magnum support containers on a VM, bare-metal, or both?

@ewindisch @adrian_otto Triple-O Round 2? :)

@ShamailXD is there a what's new in #OpenStack Kilo release? a product manager ask

@ragram Release notes are published for each new release which will contain this information. Kilo is slated to come out later this month (hopefully) and release notes can be found at https://wiki.opensta...

@adrian_otto I have to agree with @ewindisch combining Kolla and Magnum seems the logical path

@Thingee Vote for Consistency Groups ! Top of the mind for lot of Customers.

@paulhuckaby The PTL for Kolla is one of Magnum's core team members. We do work closely, but each project has a slightly different Mission.

@adrian_otto Can you expand on any Project dependencies for Magnum? Does it require Heat, etc?

@ShamailXD Magnum relies on Heat, Keystone, and Glance today.

@ewindisch @paulhuckaby @adrian_otto I like the relationship (they work closely together) but I think autonomy is good. It will let each project optimize for either use-case (shared technology but with different applications).

@paulhuckaby to clarify, I wouldn't recommend merging the projects. I was suggesting there is no reason Kolla's containers couldn't run on a Magnum base to decouple from Kubernetes (long term)

@adrian_otto It would probably make sense to test these four in an integrated manner then (at the very least). Restructure + Gating is going to be interesting.

@ewindisch Yes, in the future Kolla could leverage Magnum as a place to run those services.

@ShamailXD It is possible to have integrated gate testing regardless of what we tag for Integrated release. I would welcome the addition of CI tests that pair multiple OpenStack services with Magnum.

@adrian_otto agreed, I misunderstood your comment. +1 on the CI tests comment. Any third party takers? :)

@ShamailXD If someone wants to work on that, send them to our weekly team meeting: https://wiki.opensta...

@adrian_otto Does Kolla enable deployment of OpenStack on Baremetal? I am not sure if this question by @hui_kenneth is answered yet.