Thanks everyone for showing up for the first meeting, was great to have ~40 folks! Here are the minutes: https://goo.gl/wRqerO Here is the full recording: https://youtu.be/qAw3y6rdRbs The CSI slides

No worries! Sent from my Verizon, Samsung Galaxy smartphone

Thank you all for getting this off the ground.

Just wanted to give everyone an update on the serverless workgroup. We had our initial meeting, agreed on the objective of documenting what Serverless means to Cloud Native, outlined a white/position

Sorry I was thrown off by your “what does it do differently than Amazon” :-) I mean block storage (raw block devices underneath pods comparable to AWS EBS), filesystems (shared POSIX compliant

Bassam I understand that part ;) The part that I don't fully grok is what you mean by "storage". Forgive my naive questions. Alexis

Hi Chris, Thanks for starting the thread. In a nutshell, InfraKit focuses on being lightweight and embeddable while enabling self-management and capacity scaling features for the entire,

Camille, yes! :-) The premise of Rook is to provide a cloud-native alternative to Amazon S3, EBS and EFS. These storage services can run directly inside the cloud native environment vs. vendor

Presumably providing an abstraction layer that can front Amazon, Google, and internal cloud offerings. For those of us who need such a thing.

I don't understand what you are doing which is better than what Amazon can do alone.

Do you mean EBS? For S3 which has 11 9’s (over a year) of durability you’d need 10s of Rook storage nodes spread across three availability zones. For block storage, i.e. the use case in the

So you need a pair of rook nodes to be more reliable than S3?

Definitely. You would need to have a sizable cluster before you can reach high availability and durability numbers like S3. However, EBS volumes supposedly have an annual failure rate of 0.1-0.2%, and

Ok so in the single node case you are less reliable than S3?

No. There are no writes to S3 at all, and that would slow down write significantly. If you’re concerned about DR then you can take a crash-consistent snapshot of the volume(s) and send that off to

Does the first storage node write to S3 before or after pushing updates to the other nodes

Sure. Assuming a pod running in K8S has already mounted a Rook volume the main flow is: - writes to the volume (say /dev/rbd0) go through the kernel module and then out on the network - one of the

Please can you talk through the interaction flow for a local plus remote disk write on AWS, assuming the write is initiated by a process associated with a container cluster (eg k8s).

The most severe failure cases are ones that could lead to permanent data loss. There are a few, but first some background: - Volumes are backed by virtual storage pools. - Virtual pools are made up

What are the failure cases for this ? <Bassam.Tabbara@...> wrote: