Skip to content

Instantly share code, notes, and snippets.

SHORT_NAME ?= weebly
# dockerized development environment variables
REPO_PATH := github.com/smothiki/${SHORT_NAME}
DEV_ENV_IMAGE := golang:1.7#blang/golang-alpine
DEV_ENV_WORK_DIR := /go/src/${REPO_PATH}
DEV_ENV_PREFIX := docker run --rm -v ${CURDIR}:${DEV_ENV_WORK_DIR} -w ${DEV_ENV_WORK_DIR} #-e GOVENDOREXPERIMENT=1
DEV_ENV_CMD := ${DEV_ENV_PREFIX} ${DEV_ENV_IMAGE}
DEV_GLIDE_CMD := ${DEV_ENV_PREFIX} quay.io/deis/go-dev:0.17.0
func ParseConstraints(data []byte) ([]types.Constraint, error) {
var constraints []types.Constraint
var dat map[string][]map[string]string
if err := json.Unmarshal(data, &dat); err != nil {
return nil, err
}
val, ok := dat["constraint"]
if !ok {
return nil, nil
}
@smothiki
smothiki / Emerging fields.md
Last active October 12, 2016 23:48
Idealog from my experience with containers and emerging technology
  • Learn hyperledger and ethereum and blockhain bitcoin works understand the business

Simple state machine example

  • This example contains a simple.go which is the main program and example.go will have the execution steps of a state machine. Util.go describes state machine.
  • The state machine has an init event which starts from Idle state and reach state1.
  • close event ends with closed state.
  • every transition event is between init and close. A transition from state1 to state2 is named as state1_2.
  • Every intermediate state except from idle and closed are reentrants only if there is an error and this reentrant states are handled in error transition.

A small ASCII Diagram for how it works

This sprint there are two issues in product backlog about dashboards and metrics.

The current dashboard about deis-router has response time, status code, requests per second, CPU and Memory. We are getting CPU and memory from kubernetes Prometheus end point. The reason why router has additional metrics other than CPU and memory

[2016-08-11T19:50:32+00:00] - deis/deis-monitor-grafana - 10.240.0.23 - - - 200 - "GET /api/datasources/proxy/1/query?db=kubernetes&q=SELECT%20last(%22gauge%22)%20FROM%20%22container_memory_usage_bytes%22%20WHERE%20%22kubernetes_container_name%22%20%3D%20%27deis-logger-redis%27%20AND%20time%20%3E%20now()%20-%205m%20GROUP%20BY%20time(2s)%20fill(null)&epoch=ms HTTP/1.1" - 772 - "http://grafana.104.154.18.233.nip.io/dashboard/db/redis" - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0" - "~^grafana\x5C.(?<domain>.+)$" - 10.135.243.27:80 - grafana.104.154.18.233.nip.io - 0.088 - 0.088

If you observe the above log it has time stamp and status c

buildpacks :

when we do a git push deis master for a buildpack type app. The code goes to builder and builder compresses the code to tar file and uploads to configured object storage. Once this is done schedules a slugbuilder pod to provides the bucket and credentials to access the code slugbuilder pod once starts fetches the tar file from object storage and extracts the file compiles the code according to buildpack specified if not defaults to language specific buildpacks. Once the code is compiled it generates a slugfile which again it uploads to the same bucket. Once the upload is done and slugbuilder pod finishes builder checks for the file existence and creates build hook to the controller. which launches slugrunner pod encapsulating it in a RC or deployment. slugrunner pod gets the slug file from the bucket and extracts the file and runs the code according to the slug file.

t=2016-08-09T22:41:26+0000 lvl=info msg="Executing migration" logger=migrator id="create index IDX_api_key_org_id - v2"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="create index UQE_api_key_key - v2"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="create index UQE_api_key_org_id_name - v2"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="copy api_key v1 to v2"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="Drop old table api_key_v1"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="create dashboard_snapshot table v4"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="drop table dashboard_snapshot_v4 #1"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="create dashboard_snapshot table v5 #2"
t=2016-08-09T22:41:27+0000 lvl=info msg="Executing migration" logger=migrator id="crea
@smothiki
smothiki / proposal.md
Created August 9, 2016 22:35
Test E2E

After working on the test suite for a good amount of time and getting help from fellow folks. These are some issues I'm thinking of proposing to make the suite better. During our last retro, we have already talked about running smoke tests.

Some Proposals about proceeding further with current CI/CD infrastructure.

view of the current Deis architecture

The control Plane:

  • Controller, Builder, Registry, Database, Minio Any changes made to these components or Deis Cli or controller-sdk-go repository will affect workflow functionality and should run the full test suite.
@smothiki
smothiki / change.md
Last active July 22, 2016 16:24
changelog release v2.2.0

v2.1.0 -> v2.2.0

Features

  • 4ea46e7 (builder) - registry: use registry proxy to talk to the internal registry
  • b59bbbc (fluentd) - fluentd: Adding sumologic plugin support
  • b23f272 (dockerbuilder) - registry: use registry proxy to talk to the internal registry
  • 424523c (logger) - storage: Add redis storage adapter
  • 2da72a5 (logger) - redis: Optimize with more aggresive pipelining
type cluster struct {
[] nodes
any metadata
}
get cluster() returns cluster
type node struct {
platform stirng
metrics cpu , memory etc..,
events for n time