Decision Point: Storage Class, OpenEBS, Rook, other as a BB AddOn

"Red-Carpet Customer's contract says they have the ability to request P1 staff/multiple value streams support addition of up to 10 apps getting prioritized adoption into the baseline, and OpenEBS seems to be 2nd of 10. (Gitlab DAS is their 1st of 10).

• That being said from a practicality standpoint we don't want to do openebs for one Red-Carpet Customer and Rook for another customer, we want 1 supported way forward, but what that is and when it will be delivered by needs to be figured out" -Chris McGrath

added to epic &28 (closed)

changed due date to March 31, 2021

changed the description

Are these asking for particular requiremenets that they've identified can be provided by one of the solutions, or are they just looking for "Kubernetes Storage"?

/cc @cmcgrath

+1, need to know what the rqmts are before randomly picking a storage solution

Yeap 100%, started this as as a means of better communicating customer needs to the product team. Please forgive the bluntness that will follow, I'm trying to make sure the request, priority, and timeline is crystal clear.

Big Bang Supplied Cloud Agnostic Container Attached Storage, Storage Class is a high value multiple customer ask that needs to be prioritized:
3 / 3 Red Carpet Customers + 3 normal customers have requested a BigBang supplied cloud agnostic storage solution.

March 5th Major Dallemand shared: RCC Customer "I"'s contract says because they paid more than the minimum they are entitled to / it's in their contract that they can get Platform One support to force adoption of up to 10 apps/docker images (I forget if it's apps or docker images, DavidD should be able to supply the specifics if needed), just by asking for it. (I'm including this info because Tom made a very valid point that sometimes it's not known if someone's asking for something as a nice to have vs if we are contractually obligated to deliver/officially promised and on the hook to deliver. I'm adding this detail to distinguish that it is the latter case.) Contractually obligated, high priority, functionality asked for by multiple customers, needs a solid decision and timeline.

A BigBang Supplied storage class should meet the following requirements:

• Non Air gap use case: will use storage class to get around the AWS EBS limitation of EBS volume pinned to a single AZ
• As Prep for Bare Metal Air Gap / to create distributed storage such that stateful workload and move across bare metal nodes. (which also needs to be heavily prioritized but I'll cover that on another ticket)
• Hard requirement that 100% of the images used go through IronBank (Note: this hard requirement is more for the end result, but an early access demo could use upstream images, that being said we probably want to do a left shifted quick vuln scan / ask IB team how hard/easy it will be to get an image through IB.)
• Having worked with OpenEBS in the past I recall it has a mode where it can use a simple folder path for persistence and a mode where it can take ownership of a single block device/disk. They want whatever the most compatible thing is so I suspect that's file on disk in folder path based storage. OpenEBS Jiva-Hostpath for example.
• "I"'s lead looked into OpenEBS and Rook and said they prefer OpenEBS. I recall "G" @kenna81 prefers/has been asking for Rook. I think either is fine as long as it's supported.

Note: a non red carpet customer also asked for a storage class, they specifically asked for Rook because they want the ability to (in the future when more than 1 region exists in high IL envs have the ability to do regional failover from 1 kubernetes cluster with Rook to another kubernetes cluster with Rook storage, so they wanted Rook.) (I'm just including it here because you asked for requirements) @evan.rush @egnoriega @kenna81 Can you add to requirements

Timelines/When is this needed by and why that date:

• "I" has to get their OS accredited by May, and the choice of OpenEBS or Rook will require config updates to the OS. They are in a highly dot your i's and cross your t's type env, and they need to be able to record in their OS baseline as part of their accreditation any updates required by OpenEBS/Rook/Rancher Longhorn / Whatever we choose to support.
• They need OpenEBS or Rook or Rancher Longhorn IaC supplied by BB by May (regardless of if it's IB or not, so they can see what OS changes to make, and IB when available)
• By end of March I need a decision about what direction BB team will take to support the 6 paying customers who are asking for this feature + a timeline of expected delivery. OpenEBS Jiva is easy enough to pull off in 2 weeks, Rook/long horn I've never used, but the real thing is that a cloud agnostic air gap capable container attached storage, storage class functionality needs to be prioritized I don't care what we use. I just care that we get a decision on this high value feature request and a timeline.

@evan.rush @egnoriega @kenna81 Can you add timelines customers need this by

changed title from Decision Point: OpenEBS or Rook as a BB AddOn to Decision Point: Storage Class, OpenEBS, Rook, other as a BB AddOn

added BB Customer Issues + 1 deleted label

added 1 deleted label

added Big Bang Add-Ons label

I have not been able to get a definitive timeline on when this is needed by. I advocated a more agnostic "capability based" approach but it seems there is an external mandate that they are trying to comply with and it was already decided. I have asked for another meeting to go over and get something definitive and will feed that info back to product. But it is increasingly likely it will be rook @cmcgrath

@cmcgrath I think you meant storageOs ? But I'll talk to them today to see if we have flexibility on the application choice so we can better align with our always intended capability based approach

OpenEBS, Rook, Storage OS, Longhorn all options in terms of capability. OpenEBS I've heard "I" ask for by name Rook I've heard "G" ask for by name

+1 for longhorn due to how easy it is to setup and install, 100% open source, it's all k8s level, and dont need to touch the nodes. Includes a simple and easy understand GUI how the customers storage is configured and backed up. Can backup to S3 and other endpoints.

Longhorn is basically OpenEBS Jiva, +1 to everything Evan said as to my knowledge although Longhorn started out as a Rancher product (and either still is or has been open source), there's nothing stopping other Distros from using it as far as I know.

Added benefit is that Rancher is already familiar with going through the IronBank process + we have a good relationship with Rancher so it might be easier to get Longhorn through IB compared to OpenEBS.

@cmcgrath no worries, sounds good. As long as we keep it agnostic and capability based , the Product team can decide the path with the least overhead to satisfy the asks

changed iteration to Big Bang Iterations Mar 16, 2021 - Mar 27, 2021

I recall there was mention of investigating this, might be worth seeing if someone's willing to reach out to portworx (paid storage class offering) and see if they're willing to go through IronBank. PartyBus is interested in leveraging them/reaching out to PB to ask what they're looking for

I have assigned Spike #260 (closed) to myself to begin research and testing as this impacts airgap, on prem, and edge.

mentioned in issue #260 (closed)

added priority4 label

changed epic to &68 (closed)

changed epic to &28 (closed)

added Decision Point label and removed 1 deleted label

removed priority4 label

added teamXForce label

added stale label

OBE, research spike completed to determine path forward.

closed

removed stale label