Who I am
My name is Alberto Contreras. I’m a software engineer at Canonical with a background in mathematics. I have been working as a software/scientific engineer for the past 5 years in the fields of Monte-Carlo simulations, smart cities, reconciliation in banking and digital marketing using technologies as Python, C/C++ and Matlab.
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 4 months.
My involvement
Examples of my work / Things I’m proud of
To date (2022-09-02), I have contributed 57 commits and 43 reviews to cloud-init.
-
Oracle Datasource network config from env and IMDS when not iSCSI
22.10 roadmap feature to change network set-up in Oracle’s datasource. First non-trivial contribution. -
Schema deprecation handling
Decorate jsonschema to detect and emit deprecation warnings in cloud-init’s config schema. -
Skip inapplicable modules
22.10 roadmap feature to skip modules when no applicable config is given. -
Implement custom UA auto-attach behaviors
22.10 roadmap feature to add custom UA auto-attach configurability. This PR is not yet merged, but close to. It involved coordination between UA and cloud-init teams. -
Handle sshd_config.d folder
This issue unblocked the fix of another CPC issue related to livecd-rootfs/+bug/1968873. - High importance bug fixes:
Areas of work
I have been working on jsonschema’s functionality, config modules and general bug fixes. I worked mainly with the cloud-init team plus some interactions with UA and CPC teams.
Things I could do better
- Do more code reviews, triaging and community interaction.
- Familiarize with cloud-init parts as networking, init stages, packaging and release machinery.
- Technical communication.
Plans for the future
- Explore the code-base more deeply.
- Do more code reviews, triaging and community responses.
- Explore ideas about speeding up modules’ execution (parallelization, concurrency).
- Increase code quality.
General
What I like least in cloud-init
- Sometimes, there are multiple ways to do the same thing and I feel that the amount of accidental complexity could be reduced via abstracting / refactoring things. I realize this is normal in a long-lived open-source project that minimizes the amount of breaking changes. But I also recognize that my exposure to the code-base is small, so I could be wrong.
- A lot of times the only way to know what a config module is really going to perform is go and read the code. I think that improving the config modules’ documentation would have a huge impact for cloud-init’s consumer perspective.
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.