Skip to content

Instantly share code, notes, and snippets.

@jhunt
Created May 3, 2019 18:40
Show Gist options
  • Save jhunt/f5c5fb5da882628a3c777784eb3f1eb3 to your computer and use it in GitHub Desktop.
Save jhunt/f5c5fb5da882628a3c777784eb3f1eb3 to your computer and use it in GitHub Desktop.
# Internship Projects
#sw
These are write-ups for potential internship projects. These projects are fully self-contained (though they most assuredly exist within the confines of a larger project like SHIELD or Cloud Foundry), and can be executed within 3 months by a team of 3-4 moderately talented junior-year computer science students.
## SHIELD etcd Data Protection Plugin
The Kubernetes container orchestration system relies on a single persistent data store for its metadata and configuration needs: etcd. This distributed key-value store is vital to the proper operation of Kubernetes and, assuming identical replacement hardware / component configuration, the data in etcd is all that an operator needs to resurrect a dead cluster.
Design and build a SHIELD Data Protection Plugin for backing up the data in etcd, and restoring data to etcd from those archives. This plugin must work within the existing contract SHIELD has for "target" plugins. To enable this effort, you will need to be able to deploy and validate both Kubernetes and SHIELD. We will provide you hardware for both.
This project is split fairly evenly between development and operations work. SHIELD plugins are virtually all written in Go.
### Deliverables
1. a pull request to the open source SHIELD project on Github, containing the implementationof the new etcd plugin, pertinent release notes, and all necessary updates to the documentation.
2. a blog post, to be published on the Stark & Wayne blog and the SHIELD project website, announcing the availability of the new etcd plugin, and explaining (in more informal terms) how to use it to protect Kubernetes installations.
3. a blog post, to be published on the Stark & Wayne blog, discussing the internship program itself, your experiences going through it, etc.
## Blacksmith Dockerized PostgreSQL Forge
Blacksmith is Stark & Wayne's open source service provisioning framework and service broker, for Cloud Foundry and Kubernetes. It currently leverages BOSH to deploy bespoke service software instances through a mechanism called a "Forge". We are looking to adapt this paradigm to target Kubernetes as a deployment target, to enable shared on-demand services.
To that end, this project will involve building a standalone forge for PostgreSQL, that supports all the same topologies as the existing PostgreSQL Forge, but is packaged as a Docker image inside of the BOSH release. Implementation-wise, this involves learning how to configure upstream (official) PostgreSQL images, and then plumbing them into a BOSH release, along with all requisite hooks and tie-ins to Blacksmith.
This project is biased heavily towards the operations side of the business, with little development work outside of shell scripting.
### Deliverables
1. a new git repository on GitHub, containing the BOSH release for the dockerized PostgreSQL Blacksmith Forge, hosted in the blacksmith-community GitHub organization.
2. a blog post, to be published on the Stark & Wayne blog and (possibly) the Blacksmith project website, announcing the availability of the new forge, how it works, and how one might configure it.
3. a blog post, to be published on the Stark & Wayne blog, discussing the internship program itself, your experiences going through it, etc.
## GitHub Engagement Tracker (formerly Optigit)
At Stark & Wayne, we do a lot of open source stuff, from maintenance and origination (i.e. Genesis, safe, BUCC) to 3rd-party ecosystem work (i.e. https://github.com/cloudfoundry-community). We have yet to find a way to adequately stay on top of the massive number of issues and pull requests that come in across all of our orgs and repos.
Design and build a cloud-native application (to be hosted on a Cloud Foundry instance, provided by us) that leverages the GitHub API to collect, aggregate, and collate information about some subset of repositories, their open issues, and unmerged pull requests. The main user interface for this application should allow Stark & Wayne engineers to:
1. triage new issues and pull requests
2. follow up on issues and pull requests that have outstanding responses from non-contributors
3. determine which repositories have commits on master that have not been released
A proof-of-concept of a previous iteration of this can be found here: https://optigit.starkandwayne.com
This project is heavily biased towards the development side of the business, although it will involve CI/CD (via Concourse) and cloud application delivery (via Cloud Foundry).
### Deliverables
1. a new git repository on GitHub, containing the source code for the cloud-native application, and the accompanying CI/CD pipeline.
2. a working, configured deployment of the software to a Cloud Foundry instance (to be provided by S&W), for use by Stark & Wayne engineers in the course of their duties supporting our open source software.
3. a blog post, to be published on the Stark & Wayne blog, announcing the launch of the software project, what it does, how it works, and how one might configure it.
4. a blog post, to be published on the Stark & Wayne blog, discussing the internship program itself, your experiences going through it, etc.
## Upstream Dependency Version Tracker (formerly depchecker)
The Stark & Wayne Genesis project aims to package up distributed cloud software, like Concourse, BOSH, and Cloud Foundry, into easily deployed bits of logic called "kits". To support that, we often find ourselves packaing upstream software into BOSH releases (i..e. BIND9, Vault, PostgreSQL, MariaDB, etc.). Keeping up with upstream release announcements has proven more problematic than anyone would have guessed at first. What we need is a way to track the versions of software projects we have embedded in our BOSH releases and Genesis kits, and compare that against the latest released versions from upstream projects.
Design and build a cloud-native application (to be hosted on a Cloud Foundry instance, provided by us) that collects version information from a wide variety of sources, including (but not limited to):
* GitHub release pages
* The BOSH homepage
* FTP/HTTP directory listings
* Arbitrary HTML release pages
* Custom YAML files in Stark & Wayne git repos
This system should allow Stark & Wayne engineers to correlate the embedded versions of the software in packages with the available versions upstream, and detect new releases upstream that need to be refreshed in our packaging. This ought to involve at least a web interface, but may also provide notifications via the SHOUT! notification service.
This project is heavily biased towards the development side of the business, although it will involve CI/CD (via Concourse) and cloud application delivery (via Cloud Foundry).
### Deliverables
1. a new git repository on GitHub, containing the source code for the cloud-native application, and the accompanying CI/CD pipeline.
2. a working, configured deployment of the software to a Cloud Foundry instance (to be provided by S&W), for use by Stark & Wayne engineers in the course of their duties supporting our open source software.
3. a blog post, to be published on the Stark & Wayne blog, announcing the launch of the software project, what it does, how it works, and how one might configure it.
4. a blog post, to be published on the Stark & Wayne blog, discussing the internship program itself, your experiences going through it, etc.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment