Commit rights to cloud-init for James Falcon

Who I am

My name is James Falcon. I’m a software engineer at Canonical and have been working with Python for the past 10 years. Prior to working on cloud-init, I have written software professionally for avionics, telecommunications, and distributed databases. I have also made meaningful contributions to a number of open source projects.

How I came to work on cloud-init

I came to work on cloud-init through employment at Canonical. I have been working on cloud-init for the past 6 months.

My involvement

Examples of my work / Things I’m proud of

My list of commits can be seen here:

Since starting on the project, I have contributed 16 commits and performed 64 reviews (as of Nov 10).

Some PRs that stand out include:

I also presented the integration testing framework at the 2020 cloud-init summit.

Areas of work

My two main areas of focus thus far have been Oracle IMDSv2 and integration testing. I have worked primarily alongside the cloud-init core committers on these efforts.

Things I could do better

There is still much of the cloud-init codebase that I haven’t yet had the opportunity to work with. I will learn more as I go, but in the mean time I know to ask for help when I need it. Additionally, I would like to be more involved in the #cloud-init freenode channel, though I often feel the other participants there are still better able to answer questions.

Plans for the future

I plan on continuing to learn and contribute to cloud-init. I would like to make additional progress in adding integration tests in addition to contributing to anything else on the broader project roadmap.


What I like least in cloud-init

It takes a lot of time to SRU and manually verify a release. Hopefully the integration testing goes a long way towards solving that. I also dislike the number of bash scripts and bash calls that the project relies on. That’s something that could change over the long term, though I also generally prefer not to port working code.

Endorsements (1-3 endorsements required)

As a sponsor, just copy the template below, fill it out and post it as a reply to the applicants application thread.

Endorsers TEMPLATE

Endorsers Feedback

Please fill us in on your shared experience. Notable pull requests, improvements to the project, documentation, or special expertise brought to bear

Specific Experiences of working together

Please add good examples of your work together, but also cases that could have handled better.

Areas of Improvement

Please note specific areas that the application can continue to improve and watch out for going forward

What reviewers are looking for

  • a continued history of work (6 months?)
  • breadth of codebase
  • breadth of types of work
    • tests and their quality in both functional and unit test types
    • documentation
    • PRs
    • QA, release assistance
    • reviews of PRs, not their own and not only in their special focus of the codebase
  • Endorsements from the Ubuntu process
    • 1-3 endorsements in your application from existing committers
  • demonstrates an understanding of limits of knowledge and shows a reach out to others when appropriate.

Endorsers Feedback

James joined Canonical in May, and has been working primarily on cloud-init since then. He was able to start contributing quickly, and his submissions have consistently been of high quality. His code reviews are consistently good: he identifies issues, he’s not afraid to raise them, he is clear in his feedback, and is flexible in finding a middle ground when necessary. He has demonstrated an understanding of how cloud-init is integrated into distros, and how users use it. He has also, importantly, demonstrated an awareness of the limits of his understanding: he is willing to ask for assistance when needed. His community interactions are friendly, respectful and positive.

Given all of the above, I have no hesitation endorsing James’ application for cloud-init committer status.

Specific Experiences of working together

He got up to speed very quickly, and contributed feature flag support ( within a month of joining. This was a substantial piece of work, as it required understanding cloud-init’s codebase, the complex support matrix cloud-init has, the relationship cloud-init has to its downstreams, and the way in which cloud-init is managed in Ubuntu specifically. James did an excellent job of all of this, working with the community to reach a satisfactory outcome.

I worked with James specifically on support for Oracle’s v2 IMDS ( I performed some initial refactoring, and handed over the work item for James to take to completion. We discussed the intended design, and came to an improved plan as a result of it. James submitted a well-tested, complete pull request, and we had a productive conversation around the review.

James architected and implemented the new integration testing framework ( He iterated multiple times to find the right abstractions, accepted (substantial) feedback willingly, and as a result we have an excellent basis for building integration testing into cloud-init’s development process going forward.

Areas of Improvement

I would like to, and expect to, see James continue to take on larger pieces of cloud-init work. In particular, I would like to see James expand on his contributions to the “core” of cloud-init (i.e. not datasource or config modules), building on his work with feature flags.

I would also like to see James take a more active role in conversations in the cloud-init IRC channel over time. I expect that this will happen naturally: as James’ familiarity with the codebase grows, so will his ability to engage in these conversations.

Endorsers Feedback

James has been working exclusively on cloud-init and supporting projects since his start date with Canonical May, 2020.

He has shown himself to have a solid python expertise and a keen eye toward defining simple and extensible architecture and interfaces.

He has quickly come up to speed as an active contributor, reviewer and author on cloud-init. One thing that is not captured in his application is the volume of work he has been contributing both in pycloudlib (used by cloud-init’s new integration_tests) and Ubuntu StableReleaseUpdate (SRU) release validation.

His code is of high-quality and consistently well documented and tested. In his PR reviews, he establishes credibility through background, context and justification in review comments, making it both easy and efficient to work with him.

What impresses me is his willingness to question the effectiveness of some of cloud-init’s policies and process, such as how cloud-init defines feature flags and how best to reduce the burden of integration test development and SRU validation costs. That said he spends ample time to understand a proposed course of action and does not make snap judgements or jump quickly to a short-sighted solution.

He is a very capable and humble addition to the team and I would consider him an asset to have landing code. I also believe that in owning and driving the previous Ubuntu StableReleaseUpdate validation efforts, he has a deep understanding of the costs of publishing code and ensuring the quality of that code before release on most major clouds.

Specific Experiences of working together

I’ve worked primarily with James on the last two SRUs release validation efforts to publish cloud-init into Ubuntu. The most recent SRU he drove and I provided only a supporting role. He quickly understands how to analyze and verify features or bug fixes and is very independent. He also asked any questions of anything he was uncertain of. I’m really pleased with his work on the integration test architecture and most-specifically his ability to generalize API surfaces between pycloudlib and cloud-init’s new integration framework.

I think his ideas and design will save us plenty of time in maintenance and testing of cloud-init. Regarding his review comments on my own or other community PRs, I have found him attentive to details, diligent and flexible.

Areas of Improvement

I’m echoing Dan here, but I would like to see James driving conversations and fielding questions in IRC a bit more. While he gives attention and responsiveness to reviews of active PRs, I think engaging more frequently to questions and discussions in #cloud-init will further drive him to breadth of exposure and understanding of cloud-init.

Thank you for submitting this James. I appreciate you going through and being the first to flesh out the process.

From here, it’d be good to get feedback and votes from the current committers on the project.

I’ll reach out to each of them individually and we’ll set a soft time window of two weeks from today (December 15) to try to close up with votes and feedback from the committing team.

That’s a definite +1 from me!

Endorsers Feedback

I’m in favor of having James as a cloud-init contributor. I believe from
my experience working with James on curtin (see below) that James will bring
the same high-quality work to the cloud-init project.

Specific Experiences of working together

While not directly on cloud-init PRs, I have worked with James on another
python project, curtin, where we worked on bug fixes as well as larger fixes
or features to implement. James was a quick learner; easy to work with;
accepted feedback readily and asked questions whenever further details were
needed. James was attentive to his PRs and responded quickly to feedback.

A big +1 from me too @rick_h on the vote for commit rights. Welcome to the party James.

Thank you Chad, Ryan, and Dan. With 3 out of 4 committers votes in, I’d like to congratulate James and welcome him to the committers team!

I’ve updated permissions on Github and I look forward to bugging James to help me get something landed in the future. :+1:

1 Like