remove kubernetes manifests

[bacongobbler]

No point in maintaining two manifests.

refs deis/charts#1

[sgoings]

I got so excited for this issue! Haha!

[bacongobbler]

:+1:

[krancour]

If you do this, what is the plan for supporting some kind of hacking workflow where locally built changes can be deployed to a dev cluster?

[bacongobbler]

the idea is that this will eventually be resolved upstream with helm. For now we've been doing the following for testing dev changes:

$ helm install deis-dev
# make some changes to postgres
$ vim ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml
$ kubectl --namespace=deis delete -f ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml
$ kubectl --namespace=deis create -f ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml

That way tests are made against minio.

[arschles]

@bacongobbler mind naming this PR according to the naming standards?

[bacongobbler]

it's an issue not a PR. No standards apply here ;)

[arschles]

ugh, my bad. ignore me

[krancour]

@bacongobbler

the idea is that this will eventually be resolved upstream with helm.

I get that, but shouldn't the hacking workflow not depend on that? / Doesn't that make things way more complicated than they need to be for someone just wanting to hack on a single component?

For now we've been doing the following for testing dev changes:

$ helm install deis-dev
# make some changes to postgres
$ vim ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml
$ kubectl --namespace=deis delete -f ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml
$ kubectl --namespace=deis create -f ~/.helm/workspace/charts/deis-dev/manifests/deis-database-rc.yaml

It looks like you already have make targets for doing most of that. With a few tweaks, the hacking workflow can be reduced to:

$ helm install deis-dev # optional
# make some changes to postgres
$ make deploy

[bacongobbler]

Hacking/testing complexity is still fairly high for postgres. If someone wants to hack on postgres without kubernetes, they're going to need an S3 account. I'm looking for ways to minimize the burden on developers to test this component without the need for kubernetes so the hacking workflow remains local, but at this time I don't think it's that hard to ask devs to use the deis charts to install their custom database image. Having out-of-sync manifest files is frustrating to debug, and I'd rather not maintain duplicate code when we have the helm charts for installing postgres on kubernetes. Personally I'd rather direct users on using helm edit deis-dev && helm uninstall deis-dev && helm install deis-dev for testing changes on kubernetes for now, and in the future contributors should be able to run their own local "mini postgres" cluster on Docker for hacking/development with make test.