Summer 2019 Internship Projects Announced!

As I wrote previously, we are kicking off our Summer 2019 Engineering Internship this week. Here are the potential projects that our intrepid summer interns will be working on. As a team, they will evaluate each proposal, choose one, and then carry it through from start to finish.

These projects are fully self-contained (though they most assuredly exist within the confines of a larger project like SHIELD or Cloud Foundry), and are designed to be executed within 3 months by a team of 3-4 part-time, 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 implementation of 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 architectures 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

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 yet 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

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 packaging 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 releases pages
  • Custom YAML files in Stark & Wayne git repositories

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.

Spread the word

twitter icon facebook icon linkedin icon