- Download OS: http://www.orangepi.org/downloadresources/orangepizero/2017-05-05/orangepizero_e7c74a532b47c34968b5098.html
- Extract once:
unrar x Raspbian_server_For_zero_H2+_V0_1.rar
- Extract again:
unxz < Raspbian_server_For_zero_H2+_V0_1.img.xz > Raspbian_server_For_zero_H2+_V0_1.img
- Copy OS onto SD card:
sudo dd^Cs=4M if=Raspbian_server_For_zero_H2+_V0_1.img of=/dev/sda conv=fsync
- Ensure disk is unmounted
- Pinout: https://forum.armbian.com/uploads/monthly_2017_03/orangepizeromcp3008.jpg.7cffc0474b56f40ef1d64f39a57ea5c2.jpg
- Connect USB-to-TTL cable
- Note: TX should connect to RX on board, RX to TX on board, ground connected but 5v and 3.3V are unconnected
- Connect over TTL:
sudo screen /dev/ttyUSB0 115200
- Power on board
|Exit Code 1|
|Stdout Running smoke tests...|
|Running binaries smoke/isolation_segments/isolation_segments.test|
| CF-Isolation-Segment-Smoke-Tests - 4 specs - 4 nodes|
|[2018-12-12 21:55:52.75 (UTC)]> cf api https://api.sys.pale-talon.gcp.releng.cf-app.com|
Install Arch Linux
Create a bootable Arch Linux USB
- Download arch ISO from https://www.archlinux.org/download/
- Copy the ISO to the USB drive:
- From a Linux machine:
# replace sdX with usb drive listed by `fdisk -l`, # e.g. `/dev/sdb`, do NOT append a partition number
What is this?
Some ad-hoc performance testing on
cf push. Variables are number of concurrent pushes, number of diego cells, CPU count of API VMs, while the number of API VMs is fixed at one. Disabled resource matching as the test script pushes the same app each time.
- A single
cf pushtakes ~30-32 seconds regardless of number of cores, cells, or workers
- The number of diego cells is the main limiter as concurrency increases
- 32 concurrent pushes took ~59 seconds on average with 1 CC, 4 cores on API, 2 local workers, 4 diego cells
- Dropped to ~42 seconds on average by scaling cells from 4 to 8 VMs
Chapter 10 - 15 of Site Reliability Engineering
Possible discussion topics:
Thoughts on this recommendation: Being on-call should strike a balance between quantity (percent of time spent doing on-call activities) and the quality (number of incidents that occurred while on-call).
- Quantity: Spend at least 50% of time doing engineering, no more that 25% of remainder should be on-call
- Quality: If too many incidents occur on a given on-call shift, the SRE will not have time to properly perform the incident response responsibilities such as: root-cause analysis, remediation, and follow-up activities like writing a postmortem and fixing bugs. Google found these activities take ~6 hours on average, so there is a max of 2 incidents per 12 hour shift of on-call.
One Emergency Response recommendation was to intentionally break your systems to see if they fail in the way you expect.
- Anyone want to share experiences of doing this at Pivotal?
I hereby claim:
- I am ljfranklin on github.
- I am ljfranklin (https://keybase.io/ljfranklin) on keybase.
- I have a public key whose fingerprint is C15F 116B DAA9 AC25 0E20 2752 9486 66B3 EEC6 A0F0
To claim this, I am signing this object: