@erinboyd: Reiterating the mentions to trigger a notification:
@kubernetes/sig-storage-feature-requests, @kubernetes/sig-apps-feature-requests.

@idvoretskyi Could you assign me to this feature too?

Hi Erin, the feature you're working on is not specific to local storage right? There is work specific to the local storage plugin that I am coordinating. Just want to make sure that it doesn't conflict with the work you're doing.

@mtanino it seems to be not possible before you'll join Kubernetes organization - https://github.com/kubernetes/community/blob/master/community-membership.md. Sorry, It's a GitHub restriction.

@idvoretskyi Thank you for the explanation. I'll try to send membership request.

@erinboyd I have the same question as @msau42, is this specific to local block or this is about block support in general?

@erinboyd I just saw this. What is required from SIG-Apps?

for sig-apps is it mostly testing w/ databases + raw block storage to see if we see the intended benefits as well as testing security?

@danpaik @erictune
I agree on above.

@erinboyd
Anything else?

I'm sure SIG-Apps has the necessary experience to advise on how to adapt existing database examples/charts to use the new volume type. Looking at MySQL, it looks like it won't be trivial: you need a separate step to initialize the block device, vs serving from it.

I agree that raw block access might pose some security issues, but I'm not sure SIG-Apps has the necessary expertise to evaluate security.

@etune I don't think it will be a big win for most OSS storage applications, but it will offer a migration path for users with custom or legacy applications to move their workloads onto Kuberentes.

1. None of Postgres, Cassandra, MongoDB, Couchbase, CouchDB, Riak, ElasticSearch, Solr, Kafka, Redis,or HDFS, or HBase support the use raw block devices.
2. Of the RDBMS systems that do (MySQL or Maria with InnoDB, Oracle, and DB2), I've only seen interest in MySQL and Maria.
3. Of the DFSes that use it, they are all meant to run with local raw block devices. The IOPS caps for remote storage might not be practical for the most prevalent use cases.

@danpaik For InnoDB what is the optimization we hope to achieve?

1. Are we just trying to remove the filesystem overhead?
2. Are we trying to disable double buffering? If so, we need to map the configured page size to the disk sector size. Note that, for ext4 (data=journaled) you can probably disable double buffering if the InnoDB page size is 4k without using a raw block device.

I don't think having a helm chart that disables double buffering will necessarily be safe (or portable) as there is an underlying dependency on the page size representing an atomically writable disk sector. The sector size will be cloud provider specific, and it is currently not surfaced in any way. We should just use manifests for the purposes of testing InnoDB in this configuration, and I would propose using Sysbench for an evaluation of the measured performance.

This did not make it in to 1.8, design was complete. Implementation will be punted to 1.8

@saad-ali to 1.8 or 1.9? If 1.9, let's update the milestone.

Moved to 1.9

We are removing this feature from 1.17 and pushing it to 1.18

We want to align moving both this (in-tree) and CSI raw block (#565) to GA at the same time. If CSI raw block GA slips past 1.18, we can reconsider moving this to GA independently.

/milestone v1.18

@saad-ali Thank you for the update, we will remove from the tracking sheet!

Hello @saad-ali

Are you still planning on graduating this with #565? For your awareness, the enhancement freeze will be January 28th and the code freeze will be March 5th!

/assign @jsafrane
who is planning to work on this for 1.18

@jsafrane @msau42 I assume the comment above means we should we track this for 1.18? Thanks!

@jsafrane @msau42 we're about a week away from Enhancement Freeze now. Do you plan on including any of this in 1.18? We're currently not tracking this or #565, and we'll need to do that prior to the enhancement freeze if you'd like to graduate this in 1.18!

Thanks!

Yes this should be tracked along with #565

Hey @jsafrane @msau42 -

Seth here, Docs shadow on the 1.18 release team.

Does this enhancement work planned for 1.18 require any new docs or modifications to existing docs?

If not, can you please update the 1.18 Enhancement Tracker Sheet (or let me know and I'll do so)

If doc updates are required, reminder that the placeholder PRs against k/website (branch dev-1.18) are due by Friday, Feb 28th.

Let me know if you have any questions!

Hello @msau42 kube-proxy-9t6v6,

Just a friendly reminder that code freeze for 1.18 is March 05, 2020.

As we track toward code freeze, please list out/link to any PRs you are working on toward graduating this enhancement!

Hello @msau42 @jsafrane

We're getting close to code freeze next week, 05 March 2020

Can you please share any PRs that are in flight for this so that we can properly track the issue? This includes both k/k PRs and placeholder PRs against k/website (branch dev-1.18), which are due by Friday, Feb 28th.

Doc PR: kubernetes/website#19338

We track all issues/PR for GA in this board: https://github.com/orgs/kubernetes-csi/projects/4

Hey there @erinboyd, @screeley44 , @mtanino -- 1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

In order to have this part of the release:

1. The KEP PR must be merged in an implementable state
2. The KEP must have test plans
3. The KEP must have graduation criteria.

The current release schedule is:

• Monday, April 13: Week 1 - Release cycle begins
• Tuesday, May 19: Week 6 - Enhancements Freeze
• Thursday, June 25: Week 11 - Code Freeze
• Thursday, July 9: Week 14 - Docs must be completed and reviewed
• Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released
• Thursday, August 20: Week 19 - Release Retrospective

If you do, I'll add it to the 1.19 tracking sheet (http://bit.ly/k8s-1-19-enhancements). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

/close

(closing this since the KEP has been implemented)

@palnabarun: Closing this issue.

/milestone clear

/milestone v1.18

(since the enhancement graduated to Stable in 1.18 release cycle)