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:

+1 to Rob's initiative on the demo. Rob and Digital Rebar are doing a valuable job at Kubernetes community - it should be useful to share it across the whole CNCF community.

Alexis, Thanks! We joined the Storage WG and will work with Ben on CSI and future projects. The use case was running Rook Block storage on-top of ephemeral/instance storage on EC2 instances vs. using

Alexis, For InfrasKit specifically, I'm interested in where this fits or replaces Docker Machine. There seem to be elements of Docker Machine in the design. Rob Rob ____________________________ Rob

Bassam It would be good for Rook team to join Storage WG, if you haven't done so yet. QQ: you said that k8s use cases that run on EBS have high failover times & that you can improve this. I missed

Rob That would be interesting & could also be good material for the CNCF website / blog. a

+1 to Alexis and Rob. I'd really like to see a good breakdown comparison between Infrakit and digital rebar, bosh, cloudformation, fog,and others Alex Baretto

All, I'd be happy to present / demo Digital Rebar to provide another cloud native perspective on how to address hybrid infrastructure automation. I believe that would help provide a helpful

From today's CNCF TOC call, there was some discussion on how InfraKit compares to Terraform, BOSH and Digital Rebar. Thanks again to David for taking the time to present. Let's use this thread to have