The Ubuntu Rally occurred last week in New York City where the entirety of the Canonical Engineering teams as well as various members of the community spent time working through final plans for Artful and continued discussions for next year’s LTS release.
Below are notes on a few items last week’s event:
We saw the release of the final beta of Artful! If you are able, please give the Artful server images a test as we approach the release. Give your favorite software stack a test, install to baremetal or in a VM, or if you have not already try out the latest version of LXD. Any and all bugs and input are appreciated as they help us make another quality release.
There were, of course, numerous topics related to packaging merges. Here are a few of the topic areas:
The server team has spent considerable effort over the past few release cycles getting the package delta under control and is able to stay very current with packages in Debian. The status of which is tracked using the merge-o-matic report.
The primary reasons for this success are two-fold: 1) expecting the last person to touch a source package to do the next upload does not work and is not a policy we use as a team 2) the git workflow the server team uses via the git ubuntu tool
git ubuntu enables merge reviews allowing another developer on the server team to check and validate the upcoming changes. As a result of having this peer review done and the need to justify changes with that peer confirmed deltas with Debian are minimized and the number of uploads are kept to a minimum.
As a part of the above discussion, there was also a side topic about updating the merge-o-matic report to allow for better filtering and reporting. This would allow teams to get a more clear idea of the status of packages.
There was a discussed turning on automatic imports using the git ubuntu with the Launchpad team. This requires some development so Robbie Basak is learning how to set up a development environment to make these additional changes. This will enable the usage of git ubuntu to even more packages.
While the change log follows a specific format, the text for each change log item is free form. The server team is working on developing a set of best practices and formats it expects to use for various scenarios and will enforce these during the git workflow process.
The cloud-init team sat down to go over the state of testing in the project and plan out the next focus areas for QA. Here is a brief list of areas the integration tests are set to receive over the coming months:
- AWS Backend Support
- Azure Backend Support
- GCE Backend Support
- Consolidate test cases into one directory
user-dataand allow for any valid user-data
vendor-datakey to allow passing in of vendor-data in backends like LXD
diskskey to specify additional storage disks for a particular test
platformskey to specify backends test case supports
- Refactor the data collection YAML as well to grab files, folders
The team also spent time going through new features and bugs around netplan, revamping cloud-config snap support, and timesyncd.
As the QA developer for the Server team I took advantage of having all the engineering teams on hand and met to work through methods of improving testing:
A current pain point is when doing a stable release update (SRU) and discovering that suddenly the source fails to build (FTBFS). In order to prevent these surprises, I would like to rebuild the server team’s owned packages, if not all of main, on supported releases periodically to report FTBFS issues.
The foundations team, not only agreed with the importance of doing this, but further encouraged this testing. They walked me through the process of doing a rebuild of the archive on Launchpad as well as the special requirements and pain points.
By discovering and resolving these types of failures the archive is kept in a healthier state allowing others to build the source when necessary problem-free and gives yet another opportunity to contribute to Ubuntu.
I recently added KVM backed testing to the cloud-init integration tests. My next step is to begin added support for the cloud providers. I talked to both the Foundations and Kernel teams to see how they currently deploy to their tests to AWS, Azure, and GCE and was given access to their code repositories to begin working through the details.
The Solutions QA team and I discussed how to test proposed versions of cloud-init and curtin. The solutions QA team has a massive integration test effort across many products, including Ubuntu Server, Juju, MAAS, LXD, and more. This effort will lead to even great coverage in testing proposed versions of cloud-init and curtin.
A quick sync with the MAAS team occurred to verify we can get the logs required for our curtin SRU execption and planned cloud-init SRU exception. This testing occurs when cloud-init and curtin our in the proposed bucket. We are working to get a substantial increase in test coverage during this time.
For the first time ever I was able to discussion QA with the Desktop Team face-to-face. It was great to learn what areas and issues the team is working through and provided a good opportunity for us to work through common areas of testing, tools, and metrics.
We also decided to work to get our daily LTS and development release ISO results publicly available. These tests gate the release of new daily ISOs, run a smoke install, and then execute dozens of various pressed installs.
Also for the first time, I met with the hardware enablement (HWE) and certification (cert) teams. I now have a better understanding of the testing that occurs on hardware before a release and how hardware vendors obtain certification. The team’s testing provides great coverage of the kernel and drivers.
The server team is considering revamping the current server team IRC meeting. The current format does not appear to engage the community effectively and we would like that to change.
The current proposal involves changing the format away from a meeting format to more of an office hours time. During which members of the server team will be around to answer questions, give any updates that need to be highlighted, and discuss any major issues with the community as a whole.
We also would like to use this time as an opportunity to tackle bugs, as we have done with our bug triage days in the past. These days have been hugely helpful and well received by many and is something the server team would like to continue to do.
Finally, the server team spent time getting training on managing an s390x, getting access and using the system console, how to boot and add hardware, as well as learning how to debug common issues. It was great knowledge to have given Ubuntu server’s continued support of s390x.