codaisseur / alea Goto Github PK

would be nice as well to have elasticseach support

We are looking to use it at Clearbit, so I'm going to create Helm chart for the whole cluster.

Trying a fresh install on a kubernetes cluster and getting a helm chart error:
Error: error validating "": error validating data: found invalid field claimName for v1.Volume

$ helm version
Client: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2", GitCommit:"477efc3cbe6a7effca06bd1452fa356e2201e1ee", GitTreeState:"clean", BuildDate:"2017-04-19T20:33:11Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.4", GitCommit:"d6f433224538d4f9ca2f7ae19b252e6fcb66a3ae", GitTreeState:"clean", BuildDate:"2017-05-30T22:00:09Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"}

When removing claimName field from all charts and redeploying with those local changes, it works without those errors.

This is a really serious non-technical issue but where did you get those deis socks? 😆

After #2 is fixed and #4 is ready.

It would be nice to have a CLI to make managing services of your apps easier than using curl.

Some Useful Commands:

• alea config --controller=<your controller url>
  • default to services.[deis-remote.host]
• alea services add postgres|redis|memcached|mongodb

I have a branch in the works in #12

How do you get the list of redis instances and where they map to on the cluster?

We would love to see support for AWS local Dynamodb version :)
https://hub.docker.com/r/tray/dynamodb-local/

Thanks for releasing alea! I'm excited to try it out in our cluster.

We run a multi-AZ Kubernetes/Deis cluster on AWS. How do you maintain storage/AZ affinity across k8s nodes?

Replace the current Postgres+Pgpool-II setup with Stolon.

Some Background, Rationale

The current setup with pgpool does not work. When we create new postgres users for apps in the Services API, pgpool-II does not know about them and connection attempts with these new users fail with:

ERROR:  "MD5" authentication with pgpool failed for user XXX

We've used Stolon previously, and with success. However, with Stolon we are limited to just 100 client connections, hence the decision to use pgpool-II for connection pooling. With the headaches above as a result.

So, back to Stolon seems the most viable option right now. If we run out of connection slots, we could set up additional Stolon clusters in the future and link the Services API to that new one so it will start giving out databases and users on that new cluster. - Let's make that nice-to-have for now though.