Borys Borysenko bborysenko

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had some trouble figuring out the proper method for doing so and made quite a few mistakes along the way. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your

iPXE customer script (BETA)

Booting your server with your own iPXE script allows cool things like:

running diskless bare-metal system like CoreOS, SmartOS, ...
recovering with your own Rescue system or bare-metal restore tools (like Acronis and Idera)
launching Standard installer like ESXi, Linux, Solaris, ...

How ? Using directly the RESTful API EU|CA or the API console EU|CA.

A quick note on how I'm currently handling Blue/Green or A/B deployments with Terraform and AWS EC2 Auto Scaling.

In my particular use case, I want to be able to inspect an AMI deployment manually before disabling the previous deployment.

Hopefully someone finds this useful, and if you have and feedback please leave a comment or email me.

Overview

I build my AMI's using Packer and Ansible.

	* Installing ARCH linux
	Preparation:
	- Get an empty USB disk
	- Create 2 partitions:
	- ARCH - filesystem FAT
	- FAT - filesystem FAT
	- Downlaod Arch linux from: www.archlinux.org/download and put on your USB ARCH partition
	- Make sure you have an Ubuntu install somewhere (VMware would work)

	Fix the iso to be usable for UEFI:

	#!/bin/bash

	BASE_PATH=/var/opt/gitlab/gitlab-rails/shared/registry/docker/registry/v2/repositories

	DRY_RUN=0
	KEEP_LAST_IMAGES=10
	RUN_GARBAGE_COLLECTOR=0
	GITLAB_CTL_COMMAND=`which gitlab-ctl`

	# Cache 10GB for 1 Month
	proxy_cache_path /var/cache/nginx keys_zone=GS:10m inactive=720h max_size=10240m;

	upstream gs {
	server 'storage.googleapis.com:80';
	keepalive 100;
	}

	server {
	set $my_domain "yourdomain.com";

	#!/bin/bash
	# Returns the IP address of a running KVM guest VM
	# Assumes a working KVM/libvirt environment
	#
	# Install:
	# Add this bash function to your ~/.bashrc and `source ~/.bashrc`.
	# Usage:
	# $ virt-addr vm-name
	# 192.0.2.16
	#

	def nth_percentile(dataset, percentile = 90):
	sorted_dataset = sorted(dataset)
	new_length = len(sorted_dataset) * percentile / 100
	return sorted_dataset[0:new_length]

	def mean(dataset):
	return sum(dataset)/float(len(dataset))

	dataset = [5, 9, 7, 101, 4, 8, 109, 104, 6, 1, 110, 106, 3, 107, 105, 2, 102, 10, 103, 108]
	percentile_90 = nth_percentile(dataset)

	import sys
	import locust
	import gevent
	from gevent.socket import socket
	from gevent.queue import Queue
	import time

	from utils.bootstrap import test_conf as TEST_CONFIG
	import insight

	#!/bin/bash

	# Have to redirect stderr to stdout here because slave.py uses stderr for output.
	~/bin/slave.py list 2>&1 >/dev/null \| grep beaker-slave- \| while read slave; do
	echo
	echo "Checking status of $slave..."

	# First, check if we can SSH into the host. If we can, then check the process and maybe shut down.
	# This makes sure that we don't consider an SSH failure to be reason to shut down the node.
	if ssh $slave echo < /dev/null; then