Yet again and for the second time this year, it is time to vote for summit presentations :). Self promotion ahead :).
As always, Josh and I will present the newest addition of Liberty for Ceph in OpenStack. I don’t want to spoil to much but what I can tell you is this cycle is doing well and most of the wanted features would likely land in Liberty. So if you want to see all the amazing things that happened during this cycle:
This presentation will be a follow up on Dude where’s my volume? talk from Vancouver.
Thanks in advance for your votes and support :).
The title is probably weird and misleading but I could not find better than this :). The idea here is to dive a little bit into what the kernel client sees for each client that has a RBD device mapped. In this article, we are focusing on the Kernel RBD feature.
The Hammer release brought the support of a new feature for RBD images called object map. The object map tracks which blocks of the image are actually allocated and where. This is especially useful for operations on clones like resize, import, export, flattening and size calculation since the client does not need to calculate where each object is located. The client will just look up on that table.
It is crucial to know how to build Kubernetes from source if you want to implement new features.
Use RBD device to provide persistent storage to your containers. This work was initiated by a colleague of mine Huamin Chen. I would like to take the opportunity to thank him for the troubleshooting session we had. Having the ability to use persistent volume for your containers is critical, containers can be ephemeral since they are immutable. If they did on a machine they can be bootstrapped on another host without any problem. The only problem here is we need to ensure that somehow the data that come with this container will follow it no matter where it goes. This is exactly what we want to achieve with this implementation.
People have been having trouble to map a RBD device in a container. Quick tip on how to map a Rados Block Device into a container:
Almost two years have passed since my first attempt to run Ceph inside Docker. Time has elapsed and I haven’t really got the time to resume this work until recently. For the last couple of months, I have been devoting a third part of my time to contributing on deploying Ceph in Docker. Before we start, I would like to highlight that nothing of this work would have been possible without the help of Seán C. McCord. Indeed the current ceph-docker repository is based on Seán’s initial work. Let’s see how you can get this running!
As part of my work on ceph-docker, I have been playing a bit with Kubernetes. As a first exercise, I thought it would be interesting to run my Ceph monitors with Kubernetes. Let’s see how we can achieve that.