Commit Rights to cloud-init for Brett Holman

Server cloud-init
1

Who I am

My name is Brett Holman. I am a software engineer at Canonical. Prior to working on cloud-init I evaluated, managed, and developed software for distributed linux systems and networks in the field of High Performance Computing. I have made meaningful contributions to various open source projects.

How I came to work on cloud-init

I came to work on cloud-init through my employment at Canonical. I have been working on cloud-init for 4 months.

My involvement

Examples of my work / Things I’m proud of

To date (January 21, 2022), I have contributed 19 commits and 26 reviews to cloud-init. My code contributions have included a mix of features, bugfixes, and general project maintenance. These changes have touched different parts of the project including distro, datasource, and config modules.

A few notable PRs include:

  • Remove (deprecated) apt-key
    This removed dependency on a deprecated utility and enabled a more fine-grained trust model to GPG keys for individual repos.
  • Add Strict Metaschema Validation
    After noticing that an invalid metaschema definition could cause silent failures that are challenging to debug, I proposed stricter metaschema validation to help prevent future invalid metaschemas.
  • Add ec2 IPv6 IMDS Support
    This hasn’t been merged yet, but it is my first “real” PR affecting datasources. Assuming this gets merged, hopefully this work can be extended to support other datasource IMDS.
  • Add 21.4 tests
    I added integration test coverage for growpart.
  • Reorganize unit test locations under tests/unittests
    This PR clarified unit test location. This cleanup PR is notable only for touching many files in the codebase (and therefore will show up in many future git blames).

Things I could do better

There are many things I could do better; I am only human. Several areas of improvement include:

  • my experience with the various supported clouds is limited
  • there are many parts of the codebase that I haven’t yet explored
  • general inexperience with the cloud-init leads to longer times responding to community questions and bug reports
  • estimating expected time for software development-related tasks
  • technical communication

Plans for the future

I plan on continuing to improve cloud-init.

Some potential areas of improvement include:

  • multi-nic & virtual networking could use improved features and integration testing
  • more extensive use of type annotation to facilitate static code analysis
  • RHEL-based networking needs attention
  • an Ansible module might be a nice addition

And of course there are the ever-present needs of a long backlog of triaged bugs and general interest in improved boot times.

What I like least in cloud-init

Bugs get shipped in releases that might otherwise be caught in a statically typed language. Type annotations help this situation, but there is much work to be done in this area.

1 Like
2

A big +1 from me! Brett has come up to speed quickly on the project and brings solid engineering skills to the table.

1 Like
3

@holmanb’s contrubitions to cloud-init show both experience in defensive programming, depth in understanding networking stacks, distributed systems and solid python architecture and OOD.

He is active in public IRC channels and fielding bugs to resolution to ensure upstream is addressing community questions or concerns. His PR reviews are detailed and he spends time understanding the context or potential pitfalls to ensure that fixes we commit upstream are the desired resolution instead of a band-aid that only resolves a symptom.

What I would like to see before giving commit bit to upstream cloud-init would be for Brett to drive a full cloud-init upstream release as well as the Ubuntu downstream SRU release effort to gain more understanding of the mechanics, verification and release costs of downstreams. Given that we have such an upstream release goal in the coming weeks, I think this effort will be achieved within a month.