Make it easy to spin up a cluster for development/integration tests/CI about dashboard HOT 15 CLOSED

@gmarek @wojtek-t Do you have any hints for setting up a dev cluster easily & quickly?

from dashboard.

@zreigz Can you take this?

from dashboard.

There is a script to start a light version locally:

./hack/local-up-cluster.sh

Is that what you want?

from dashboard.

I was just going to write the same thing:). If you want 'real' one, you can just use your GCE project and and use cluster/kube-up.sh

from dashboard.

I'm thinking about a Kubernetes cluster that can be used on, e.g., CI for test. ./hack/local-up-cluster.sh looks like exactly what we need. Thank you!

I'll let @zreigz figure out how to integrate it with this project.

from dashboard.

Also, if you need something for integration tests - you can take a look how we are running integration tests. We already have some framework for it (maybe you can easily extend it for you purpose).
Take a look at:

• test/integration/framework (for framework implementation)
• test/integration/*_test.go (to see how it is used)

from dashboard.

To give you some more details - in integration tests we're locally running master components together with mocked "SimpleKubelets". As long as you need just information from etcd (i.e. no information from nodes) it should be enough.

from dashboard.

To give you some more details - in integration tests we're locally running master components together with mocked "SimpleKubelets". As long as you need just information from etcd (i.e. no information from nodes) it should be enough.

That's not entirely true IIUC - we are really starting pods on those SimpleKubelets there, so you have some data on nodes too.

from dashboard.

Nope. AFAICK It uses FakeDockerClient, even simpler than one that Kubemarks one.

from dashboard.

I can take this. My concept is use something similar what is done in
installation script: https://get.k8s.io but use gulp a specially gulp-exec
to execute some commands for downloading, retrieving latest version and
creating cluster (./hack/local-up-cluster.sh). When cluster will be created
we can access to master node also using gulp-ssh. When this part will be
done then we can thing for other stuff like CI.

On Mon, Nov 2, 2015 at 4:29 PM, Marek Grabowski [email protected]
wrote:

Nope. AFAICK It uses FakeDockerClient, even simpler than one that
Kubemarks one.

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

from dashboard.

@zreigz Nice! I think all we need is access to the apiserver, e.g., its port and host like http://localhost:8080. With that the UI can connect to it and perform actions. No SSHing into nodes is needed.

from dashboard.

Ok, so first I will focus to set up cluster. When it will be ready then we
think about rest of it.

On Tue, Nov 3, 2015 at 8:18 AM, Piotr Bryk [email protected] wrote:

@zreigz https://github.com/zreigz Nice! I think all we need is access
to the apiserver, e.g., its port and host like http://localhost:8080.
With that the UI can connect to it and perform actions. No SSHing into
nodes is needed.

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

from dashboard.

Is the CI supposed to run against a local cluster or a real cluster?

from dashboard.

Yes, the CI is supposed to start a local cluster, then start the UI and finally perform integration tests on this environment. This yields in a reproducable build and test setup which can be used on CI and on developer's local machine. We want to get as productive as possible.

Connecting to an external ("real") cluster is, of course, doable. This may be, e.g., a staging cluster. We do not have resources to maintain such setup ATM, however.

from dashboard.

We've got pretty good setup for tests/dev now. I think we can close.

from dashboard.