On Mac OS X, I simply can't get minio ever to build. I've tried newer versions of glide and set GOOS=linux GOARCH=amd64 and nothing seems to help.

$ make bootstrap test build docker-build docker-push
...
[INFO] Setting version for gopkg.in/v2/yaml to 53feefa2559fb8dfa8d81baad31be332c97d6c77.
[INFO] Setting version for k8s.io/heapster to 0e1b652781812dee2c51c75180fc590223e0b9c6.
[ERROR] Failed to set version to 444684342d4c12c7c05bed13bd249034370840a9: exit status 128
[WARN] Failed to set version on gopkg.in/olivere/elastic.v2 to 444684342d4c12c7c05bed13bd249034370840a9: exit status 128
[INFO] Setting version for k8s.io/kubernetes to 92635e23dfafb2ddc828c8ac6c03c7a7205a84d8.
[ERROR] Failed to set version to 0e1b652781812dee2c51c75180fc590223e0b9c6: exit status 128
[WARN] Failed to set version on k8s.io/heapster to 0e1b652781812dee2c51c75180fc590223e0b9c6: exit status 128
[ERROR] Failed to set version to 92635e23dfafb2ddc828c8ac6c03c7a7205a84d8: exit status 128
[WARN] Failed to set version on k8s.io/kubernetes to 92635e23dfafb2ddc828c8ac6c03c7a7205a84d8: exit status 128
[INFO] Setting version for speter.net/go/exp/math/dec/inf to 42ca6cd68aa922bc3f32f1e056e61b65945d9ad7.
docker run --rm -v /Users/matt/Projects/src/github.com/deis/minio:/go/src/github.com/deis/minio -w /go/src/github.com/deis/minio quay.io/deis/go-dev:0.7.0 go test ./genssl/... ./src/... .
vendor/github.com/deis/pkg/aboutme/aboutme.go:21:2: cannot find package "k8s.io/kubernetes/pkg/api" in any of:
    /go/src/github.com/deis/minio/vendor/k8s.io/kubernetes/pkg/api (vendor tree)
    /usr/local/go/src/k8s.io/kubernetes/pkg/api (from $GOROOT)
    /go/src/k8s.io/kubernetes/pkg/api (from $GOPATH)
vendor/github.com/deis/pkg/k8s/client.go:5:2: cannot find package "k8s.io/kubernetes/pkg/client/unversioned" in any of:
    /go/src/github.com/deis/minio/vendor/k8s.io/kubernetes/pkg/client/unversioned (vendor tree)
    /usr/local/go/src/k8s.io/kubernetes/pkg/client/unversioned (from $GOROOT)
    /go/src/k8s.io/kubernetes/pkg/client/unversioned (from $GOPATH)
vendor/github.com/deis/pkg/k8s/client.go:6:2: cannot find package "k8s.io/kubernetes/pkg/client/unversioned/clientcmd" in any of:
    /go/src/github.com/deis/minio/vendor/k8s.io/kubernetes/pkg/client/unversioned/clientcmd (vendor tree)
    /usr/local/go/src/k8s.io/kubernetes/pkg/client/unversioned/clientcmd (from $GOROOT)
    /go/src/k8s.io/kubernetes/pkg/client/unversioned/clientcmd (from $GOPATH)
vendor/github.com/deis/pkg/aboutme/aboutme.go:23:2: cannot find package "k8s.io/kubernetes/pkg/labels" in any of:
    /go/src/github.com/deis/minio/vendor/k8s.io/kubernetes/pkg/labels (vendor tree)
    /usr/local/go/src/k8s.io/kubernetes/pkg/labels (from $GOROOT)
    /go/src/k8s.io/kubernetes/pkg/labels (from $GOPATH)
make: *** [test] Error 1
$ 

From https://ci.deis.io/job/workflow-test-pr/2197/artifact/2197/logs/deis-minio-miiij.log/*view*/:

2016/06/06 17:34:48 starting Minio server
2016/06/06 17:34:48 starting health check server on 0.0.0.0:8082
minio server /home/minio/
error at command wait
2016/06/06 17:34:48 Minio server error (exit status 127)

perhaps this is fixed via #106?

Carried over from the already-merged #39:

So the error FromEnv is returning is a legit error. It's coming from the k8s API server. The API server is reporting that it doesn't have a record for that pod. We need to look into why that is the case, and whether this is a transient issue.

Prior to version 0.2.1 the pkg/aboutme was silently ignoring a number of errors that the API server was returning, and instead just returning a stripped-down set of fields (including IP, which it got from aboutme.MyIP()). We decided that this was the wrong approach, and so I started returning more errors.

If you are really only using pod.IP, you could skip the k8s API lookup and simply use aboutme.MyIP. Otherwise, we should figure out why the API server is getting a 404 on that record.

any way we could swap this chart with https://github.com/kubernetes/charts/tree/master/stable/minio?

It is s problem on bare-metal and Digital Ocean to get object storage set, using official minio chart it can be set with persistence and distributed mode.

As seen in the fix in #106, the Minio download links can change, and when they do, our builds fail. After #106, they will "go red" (as opposed to the former behavior, in which they failed silently), but it would be even better for us to mirror the binary builds on our own S3 or GCS bucket, so that we control the download URLs.

This issue is for copying binaries into the S3/GCS bucket that we own, and changing the Dockerfile to point to that bucket.

make build-mc docker-build-mc docker-push-mc builds the mc image, and make docker-build-mc-integration docker-push-mc-integration builds the mc-integration image

Since we download an mc binary, we don't need to build it anymore, so we can remove the build targets in the Makefiles (the one at the root directory and in the mc directory) and the install script in the mc directory as well

Ref minio/minio#1041

This comment indicates that official releases will be ready later this month. We currently have lots of Makefile targets to build both mc and the server, which could go away (as could a lot of shell scripts) when we can just download releases.

We'd also simplify the Makefile, which would mean we wouldn't have to do as much refactoring (#25).

Relates to deis/builder#46 and deis/slugbuilder#13.

Consider splitting them since they're not necessary to build or run the minio server. Note that these other 2 components rely on this repo for:

1. logic to build mc from HEAD
2. the minio auth secret

Need to add health and liveness checks!

quay.io/deis/go-dev:0.4.0

In the case I want to keep using Ceph or the Ceph-less option from V1

currently using ubuntu-debootstrap:14.04

just as other repos do, travis.ci needs to build this codebase. since the build needs to push to dockerhub and quay.io, this issue implicitly will require a makefile refactor. see https://github.com/deis/minio/pull/9/files#r46733280 for more

• Parameterize the port and use it elsewhere (for example, in constructing the Minio client after #57)
• Put the secrets slice inside a struct, under a well known name
• Write template execution tests

Similar to what builder does in its .travis.yml file, minio should run make ... docker-build to ensure that the Dockerfile is correct

Part of #1 prescribed the following requirements:

Requirement 1:

Create a Minio MC pod to be used for testing Minio from within a Kubernetes cluster (#19)

Requirement 2:

Write an entry point on the MC pod that will run integration tests against the Minio RC to verify that it is up, running, and correctly configured. (#19)

These two requirements led to the creation of a mc directory and an integration directory under it. The direct contents of the mc directory are intended to build the mc CLI, and then the mc/integration directory is meant to package that CLI and an integration test (implemented as a bash script) into an image. The idea behind the integration testing image was to allow anyone to run it in a pod so it can run some basic CRUD operations against a running minio server to see if it's properly set up and running (i.e. ensure it's configured with the credentials that are stored in the object storage creds secret, it's running, its filesystem is properly set up, etc...)

We've since created e2e tests which have exceeded the functionality of these tests, we haven't automated these integration tests, and we don't automatically create the integration test image.

This proposal issue is for removing the mc directory entirely, which would hence remove the build scripts for the mc CLI and the Dockerfile and image creation targets for integration tests.

Of course, if we do decide to pursue integration tests in the future (another larger discussion), we can revive the integration test script and image creation logic (and we'll need to automate test runs).

This issue would obviate #99

This comment indicates that the minio team will be doing an official release later this month (12/2015).

Instead of building mc and the server from HEAD in the Makefile, the applicable Docker builds should download the binaries from the appropriate location.

This issue relates to deis/builder#11.

ubuntu-debootstrap is deprecated and ubuntu should be used instead. Do this if #8 is not done first.

it's gotten very large, and is responsible for a few different tasks:

1. building the project, dockerizing, deploying to k8s
   • requires a second target to build the minio binary from master on https://github.com/minio/minio. that target may go away when the minio server becomes stable
2. building the mc binary from master on https://github.com/minio/mc, dockerizing a second image and deploying that to k8s. The build step may go away when the mc client becomes stable
3. build the mc integration tests, dockerizing a third image, and deploying that to k8s

It may make sense to split the integration tests in (3) into a separate repository. Regardless, the makefile is hard to follow.

Targets should be grouped together, and have a comment for each group, and each target should also be commented.

Also, an overview of the high level targets and workflows should be on the README.

Finally, dependencies don't make a ton of sense right now. Some ideas:

• docker-push could depend on docker-build but it isn't now
• does it make sense for docker-build to depend on build-server and build at once?

It'd be great to not have to build from HEAD on every release. The official release is at: https://github.com/minio/minio/releases/tag/OFFICIAL.2016-02-08T00-12-28Z

Original discussion: minio/minio#1041 (comment)

Minio RC: https://gist.github.com/slack/cc8959d79adfc40a7b0b

Latest travis build (3 hours ago): https://travis-ci.org/deis/minio/builds/100192456

Docker log:

{"log":"minio server /home/minio/\n","stream":"stdout","time":"2016-01-04T22:32:35.982394182Z"}
{"log":"time=\"2016-01-04T22:32:35Z\" level=fatal msg=\"Failed to read config for minio.\" error=\"mkdir /.minio: permission denied\" probe=\"{\\\"cause\\\":{\\\"Op\\\":\\\"mkdir\\\",\\\"Path\\\":\\\"/.minio\\\",\\\"Err\\\":13},\\\"trace\\\":[{\\\"line\\\":156,\\\"file\\\":\\\"server-config.go\\\",\\\"func\\\":\\\"main.createConfigPath\\\"},{\\\"line\\\":199,\\\"file\\\":\\\"server-main.go\\\",\\\"func\\\":\\\"main.getConfig\\\"},{\\\"line\\\":240,\\\"file\\\":\\\"server-main.go\\\",\\\"func\\\":\\\"main.initServer\\\"},{\\\"line\\\":283,\\\"file\\\":\\\"server-main.go\\\",\\\"func\\\":\\\"main.serverMain\\\"}],\\\"sysinfo\\\":{\\\"host.arch\\\":\\\"amd64\\\",\\\"host.cpus\\\":\\\"2\\\",\\\"host.lang\\\":\\\"go1.5.2\\\",\\\"host.name\\\":\\\"deis-minio-hgkwx\\\",\\\"host.os\\\":\\\"linux\\\",\\\"mem.heap.total\\\":\\\"786kB\\\",\\\"mem.heap.used\\\":\\\"297kB\\\",\\\"mem.total\\\":\\\"3.1MB\\\",\\\"mem.used\\\":\\\"297kB\\\"}}\" \n","stream":"stderr","time":"2016-01-04T22:32:35.989732424Z"}
{"log":"error at command wait\n","stream":"stdout","time":"2016-01-04T22:32:35.989995342Z"}
{"log":"2016/01/04 22:32:35 exit status 1\n","stream":"stderr","time":"2016-01-04T22:32:35.990378133Z"}

markdown is listed at the bottom of https://quay.io/repository/deisci/minio?tag=latest&tab=settings

The current version is on 0.4.0, which has glide 0.8.0. Version 0.5.0 should bump glide to 0.8.3, which introduces a breaking change (in 0.8.2) to the glide.lock file. Therefore, this issue may require a make glideup so that future make bootsrap command will work.

something to run glide up inside the dev container

There is a design doc for adding a disk space resource, but it's not implemented yet. When it is, add a note in the README for how to limit disk space.

The idea of this project is that we can provide a simple, single-pod S3 object storage system for developers and for light-weight clusters.

The following tasks need to be done to get this project ready for a 0.0.1 release:

• Create a repository that follows the standard Deis pattern for Kubernetes components
• Kubernetes service defined
• Kubernetes RC defined, scaling to 1 by default (Minio doesn't yet support multiple replicas)
• Build Minio from source from the master branch, and create a Docker image
• Create Minio admin account locally, and then upload the credential as a Kubernetes secret. There should be a Makefile target for this. (#13)
• Create a shared account (Token/Secret) that all other Deis services can use to work with minio, and upload that as a Kubernetes secret. This can use the same Makefile target as the above. (#13)
• Configure Minio to use those secrets in its RC
• Add support for generating an SSL certificate locally, and then storing that in a secret. There should be a Makefile target for this (make ssl-cert). Self-signed is fine for now. (#15)
• Configure Minio to read the SSL key and cert from the secret and use it in the RC (#17)
• Create a Minio MC pod to be used for testing Minio from within a Kubernetes cluster (#19)
• Write an entry point on the MC pod that will run integration tests against the Minio RC to verify that it is up, running, and correctly configured. (#19)
• Update the README file with information on how to install and configure this package (#14)
• Add an example in the _docs directory for accessing and using Minio object storage from another pod. (#14)
• Test this installation on the below installs. It must run on both with no modifications to the underlying environment.
  • Kubernetes + Vagrant (local)
  • GKE

A few guidelines:

• For now, we are not assuming persistent storage. (Later, we will add volumes to the RC to provide that)
• All installation and configuration should be done in the Makefile. No shell scripts unless absolutely necessary.
• All code in the container should be written in Go. If you need a bootstrapping program, it should be called boot.go, located in the root of this repository, and when compiled should be placed in rootfs/bin/boot.
• As far as is possible, we should be working off of Minio's master branch, not a snapshot of an older version.

it's currently built inside a docker build (https://github.com/deis/minio/blob/master/Dockerfile) and then docker cp-ed to the right place. it makes more sense to do the build inside a docker run

Where minio stores it's object files?
Using /home/minio as a docker volume minio did not start

doing so will more closely match the makefiles of other projects. the standard workflow will then be make build docker-build docker-push

Fatal error open /var/run/secrets/kubernetes.io/serviceaccount/token: no such file or directory

would be nice if we could plug in Go code coverage to our CI system, possibly using https://coveralls.io/ and https://github.com/mattn/goveralls or https://codecov.io/#languages

Ref deis/builder#218

We want to have the ability to have deis/charts reference a specific immutable image which will enable us better traceability on issues that come into various components.

What we've done with efforts in other repositories is publish a version:

• git-[short sha] that will never be overwritten
• canary that will move to reference the latest version available of a component

Examples of the easiest way to roll this change out can be seen in deis/workflow#487, deis/builder#246, and deis/workflow-manager#11