GSoC 2017: Introduction and Draft Proposal [beadm replacement]

Sun Apr 2 20:12:14 UTC 2017

Hello All,

First, I'd like to introduce myself. I'm Kyle Kneitinger, a senior at
Portland
State University, in Portland, OR, US. I've been user of FreeBSD for a
couple
of years now, so since I finally had a summer in which my work/life/school
schedule is compatible with GSoC, I was extremely pleased to browse
through the
FreeBSD ideas.

I strongly gravitated towards the beadm replacement project. I really enjoy
writing libraries and system utilities, and the opportunity to do this for
something as important to me as ZFS was very appealing. I corresponded with
Allan Jude a few times for clarification about the intended idea and
requirements, but I would like to give anyone else the opportunity to
weigh in
on features, clarifications, or just general feedback on my draft proposal.

Thank you in advance,
Kyle Kneitinger

Google Summer of Code 2017 Proposal:
  A New ZFS Boot Environment Management Library & Tool For FreeBSD
Student: Kyle J. Kneitinger
Mentor: Allan Jude

[[ contact info redacted on draft proposal ]]

Synopsis
The purpose of this project is to build a convenient framework for
managing ZFS boot environments in

====Synopsis====
The purpose of this project is to build a convenient framework for
managing ZFS
boot environments in FreeBSD. Currently, boot environments are managed
manually, or with scripts such as `beadm`.  The approach that this project
will take is to first create a boot environment library to offer simplified
boot environment interaction to userspace applications (for example, TrueOS'
SysAdm perhaps), and then write an application that provides users with a
command (tentatively referred to as `bootenvmgr` for the remainder of this
proposal) that retains all of the features of `beadm`, with some added
functionality. Among the new features are: the ability to recursively create
boot environments containing child datasets, the ability to activate an
environment for the next boot only, and the ability to attach/detach a boot
environment to a jail.

====Timeline and Deliverables====

----Final Deliverable----
The final deliverable is the `bootenvmgr`: a command with a superset of
`beadm`
features (illustrated below in the usage and clarifying examples), and
the library,
tentatively referred to as libzfs_bootenv that provides the features to
the command, and
the userspace ecosystem.

  $ bootenvmgr -h
  usage: bootenvmgr command args ...
  where 'command' is one of the following:

          activate [-t] <bootenv>
          create [-r] [-e nonActiveBe | -e bootenv at snapshot] <bootenv>
                    create  ⟨beName at snapshot⟩
          destroy [-F] <bootenv|bootenv at snapshot>
[bootenv|bootenv at snapshot]*
          list [-a] [-D] [-H] [-s]
          rename <bootenv> <bootenv>
          mount <bootenv> [mountpoint]
          unmount|umount [-f] <bootenv>
          jail <jailid|jailname> <bootenv>
          unjail <jailid|jailname> <bootenv>

  Each bootenv is a name of a dataset in (or to be created in
$POOLNAME/bootenv/

Examples illustrating optional arguments and flags that extend from `beadm`:
  -- `bootenvmgr create -r foo` recursively creates a boot environment of /
  -- `bootenvmgr activate -t foo` uses the zpool_nextboot
     function (originally implemented for `zfsbootcfg`) to boot
     into the foo environment on the next boot only.
  -- `bootenvmgr jail bars foo` attaches the foo boot
     environment to the jail named bars.

See `man beadm` for extended descriptions of remaining options

----Milestones----

*May 4 - May 30, 2017: Community Bonding Period*
Tasks:
  -- In addition to all usual community bonding tasks, solicit feedback from
     users of boot environments and `beadm` on features and user experience
     of the command.
  -- Replicate various boot environment use cases.

Deliverables:
  -- All items on FreeBSD GSoC Student Checklist Community Bonding section
     completed (accounts, pages, repos, etc. created).
  -- Final requirements solidified in the form of a preliminary man page.

*May 30 - June 30, 2017: By 1st Evaluation*
  Note: My University is on a term-based system as opposed to semesters,
  and therefore I am still in classes for the first 2 weeks of June
Focus: Design and research.

Tasks:
  -- Prototype recursive boot environment mechanics.
  -- Craft detailed design.
  -- Begin Coding library component.

Deliverables:
  -- Makefile and headers for library complete. Skeleton, documented,
     implementation files created (and if time permits, coding has begun).

*June 30 - July 28, 2017: By 2nd Evaluation*
Focus: Completion of library, design of user command.

Tasks:
  -- Complete library implementation.
  -- Complete all non-functional requirements for library (developer
     documentation, testing).
  -- Create detailed design of user command.

Deliverables:
  -- Completed library implementation and documentation.
  -- User command headers, Makefile, and Skeleton implementation file.

*June 28 - August 29, 2017: By Code Submission and Final Evaluation*
Focus: Completion of user command

Deliverables:

  -- User command, updated manpage, and thus all project requirements

====About Me & Experience====

I am currently a Senior at Portland State University in Portland, OR, US,
focusing my studies on operating systems, language design and implementation
(especially grammars and parsers), and when the opportunity arises, digital
music creation. I believe to some extent, my dedication to school is a large
factor in why I use FreeBSD on my personal computers, as I wouldn't trust my
in-progress assignments to anything else.

With my free time I enjoy playing music, gardening, creating software
synthesizers and hardware to control them, hiking, and going to the
various OSS
events and meetups that I am fortunate enough to live near.

Throughout my studies over the past three years, I had the opportunity
to grow
as a developer in ways both conceptually and practically. In the context of
this project, I would say my most relevant experiences have been my time as
team lead on one of the CS program's final projects, my time
participating in
an 18-month cooperative learning program with 3 different companies, and of
course, some of my open source work.

---Senior Project Team Lead---
I led a team of 6 other students through our task of reimplementing the
Cairo
vector graphics library in rust, with Cairo's creator, Carl Worth, as the
project sponsor. This was an invaluable experience that allowed my team
and I to
grow as developers, communicators, and collaborators.  We focused heavily on
design, with the main goal of creating an interface that is familiar and
comfortable to those with experience using Cairo, balanced with crafting an
idiomatic, 'rustic', feel to those who write a lot of rust.  In the 14 weeks
we had, we surpassed all goals and stretch goals defined by Mr. Worth.  The
academic project wrapped up just a week and half before the writing of this
proposal, and now myself and a subset of the team are working on
outreach and
infrastructure to turn this into an educational open source project for new
developers, or just those new to rust programming.

---Cooperative Education Program---
I am a month away from completing my 18 months of my participation in
Portland
State University's PCEP (PSU/Portland Cooperative Education Program).
Through
this program I worked 20-hours a week at 3 different Portland-based tech
companies in three different roles: Quality Engineer, Developer, and DevOps
Engineer.

[[ JOB DETAILS REDACTED FOR DRAFT PROPOSAL ]]

---Open Source---

  -- i3wm window manager: Numerous bug fixes in the configuration file
     parser's handling of variables, documentation corrections, a new
feature to
     allow the passing of a new config file path on soft reloads. 
Technologies
     and themes: c, perl, yacc, flex, domain-specific languages, user
     documentation.
  -- liblo lightweight OSC (Open Sound Control) library: participated in
     discussion and drafted proof of concept code to implement a feature
for control
     path discovery.  Technologies and themes: c, networking, UDP, API
design.
  -- stk Synthesis Toolkit library: Updates to Makefile after update broke
     compatibility with certain distributions.
     Technologies and themes: Makefiles, build tools.

---Personal Open Source Projects---

  -- RPiShift: A python module for interfacing a Raspberry Pi with an HC595
     shift register. Provides simplified API, as well as advanced
interaction.
     Technologies and themes: Python, hardware, documentation, packaging.
  -- markoff/slackov/gramov: A library for simple novelty text
generation from
     an updatable corpus and Markov chains, and 2 example applications
for popular
     messaging services.  Technologies and themes: Python, API design,
API use,
     packaging.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 508 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20170402/fb6b34b9/attachment.sig>