Mesos or K8

[thbeh]

Hi, if I am to run snappydata on containers, any advice whether to run on mesos (dcos) or k8?

[jramnara]

K8s. Here is the early documentation and deploy info.

Eager to get some feedback ....

[thbeh]

Thanks for the fast respond....Any reason for K8s?

[jramnara]

We think k8s is more extensible and has a big eco-system and works well for apps (microservices) not just data driven apps. And, today, you can launch a k8s cluster on any of the major cloud providers (Google, Amazon, and on-prem VMWare). Essentially, build out a complete data pipeline including apps and make sure it will run on any cloud.

[thbeh]

Excellent points. Thanks.

[thbeh]

just a question of curiosity, with snappydata having gemfire as the db layer, does it mean I would not require HDFS as a distributed storage if I deploy Portworx as my persistence layer.

[jramnara]

Yes, you are correct. No need for hdfs. I am not familiar with Portworx but presumably it can be mounted as a persistent volume in k8s. If so, yes, Snappydata can use this as the storage layer.

[thbeh]

Thanks. Any pointers how to attach volume to snappydata server (I am assuming that's the gemfirexd part)?

[jramnara]

By default we dynamically provision a persistent volume(PV) and a claim and bind this to the Snappy pods. Essentially, snappydata uses /work sub-directory to store all its data/catalog files. And, the volume gets mounted to this directory. As simple as that. You can create your own PV and bind it if you like. The relevant portion of values.yaml - https://github.com/SnappyDataInc/spark-on-k8s/blob/master/charts/snappydata/values.yaml#L41.

@dshirish

[thbeh]

Thanks. I was looking at snappy-cloud-tools and did not see an PV/StorageClass context.

[thbeh]

Hi Jags, could you help to respond on this linked post as there are some potential customers on fast data. Thanks

https://www.linkedin.com/feed/update/urn:li:activity:6424798065709977600/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A6424798065709977600%2C6424813563084447744)

On Wed, Jul 18, 2018 at 4:14 AM, Jags Ramnarayan notifications@github.com wrote:

By default we dynamically provision a persistent volume(PV) and a claim and bind this to the Snappy pods. Essentially, snappydata uses

/work sub-directory to store all its data/catalog files. And, the volume gets mounted to this directory. As simple as that. You can create your own PV and bind it if you like. The relevant portion of values.yaml - https://github.com/SnappyDataInc/spark-on-k8s/ blob/master/charts/snappydata/values.yaml#L41. @dshirish — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub , or mute the thread .