byllc

Keybase proof

I hereby claim:

• I am byllc on github.
• I am byllc (https://keybase.io/byllc) on keybase.
• I have a public key ASDWZHIdqgIdrEA7xoC4YoWvhru29VQeWIWbP1xhZ3gxZwo

To claim this, I am signing this object:

byllc

asdf

byllc

## Capacity Planning Notes


#### Is your target Public cloud or private cloud?
- Private Cloud
  - easier
  - you know your workload and purpose
  - Fewer variables
  - Cost / Revenue is an important consideration
  - often single tenant

byllc

Keybase proof

I hereby claim:

• I am byllc on github.
• I am byllc (https://keybase.io/byllc) on keybase.
• I have a public key whose fingerprint is 1B97 2723 7C8B 527E 0851 9A56 5C56 66B3 6F30 F2F9

To claim this, I am signing this object:

byllc

# Cloudfoundry inception and startup

This document describes the cf inception environment within our management network and also
describes a first shot to boot a cloudfoundry environment with microbosh, bosh and cloudfoundry.

## Prerequisits


1. Order a new tenant and user from your openstack admin
1.a User & Tenant must have the same name (for now)

byllc

#!/usr/bin/python
# TODO make range command line arguments

import sys, codecs
sys.stdout = codecs.getwriter('utf-8')(sys.stdout) # if your terminal can't do utf-8, well...

import time
import urllib2

import BeautifulSoup

byllc

#first make sure go, git and mercurial are installed.
if [[ -z $(which git) ]]; then
  echo "Git must be installed"
  exit 1
fi

if [[ -z $(which hg) ]]; then
  echo "mercurial must be installed"
  exit 1
fi

byllc

Keybase proof

I hereby claim:

• I am byllc on github.
• I am byllc (https://keybase.io/byllc) on keybase.
• I have a public key whose fingerprint is 6E58 2DED ED6D 3369 CBDB B813 B45C A432 5850 0723

To claim this, I am signing this object:

byllc

@version: 3.2

@include 'modules.conf'

options {
    use_dns(no);

    # Disable stats.
    stats_freq(0);

byllc

###Apache Mesos A cluster manager for high availabilty distributed applications. The main components of the Mesos arechitecture are master daemon that manages slave daemons running on each cluster node, and mesos applications (frameworks) that run on the slaves. The authors define Mesos as "A thin layer for resource sharing"

The master distributes resources (cpu, ram etc.) across applications by making them resource offers. The master uses an organizational policy to decide how many resources to allow a framework.

A framework running on top of Mesos consists a scheduler that registers with the master to be offered resources, and an executor process that is launched on slave nodes to run the framework’s tasks. When a frameworks accepts resources offered by the master it tells mesos what it would like to run with those resoureses and mesos launces the tasks on the slaves.

More about Executors