Thanks a lot, Laura, for illustrating that, and for tracking the quay.io issue!
Regarding the "test-failure" usage, it's up to us how to do it (makes sense to include teuthology failures as well). In fact, "test failures" often uncover other issues (like infra/environment issues), so they end up assigned to a different component/team.
If we want to allow developers to quickly search for already reported issues for each source (CI job, teuthology suite, etc.), we could use another tag "make-check", "api", "teuthology". But that's just an implementation detail, the goal is to make easier for devels to distinguish PR-related issues from anything else. An example of that would be the current API Jenkins job, where in case of test failure/error, users are provided with a couple of links to search for reporter errors or report a new one:
What do you think?
Kind Regards,
ErnestoOn Wed, Aug 24, 2022 at 7:01 PM Laura Flores <lflores@xxxxxxxxxx> wrote:
Thanks Ernesto for your work in making the CI failures easier to track! I have been working to track many of them myself, so I will be sure to add the "test-failure" tag to them. FYI for anyone tagging issues, there are two "Tags" fields on Ceph Tracker issues: one near the middle where you can manually type in a tag, and another near the bottom where you can search for existing tags. The second option is what you'll want to use to tag "test-failure" issues. I have attached an image of an example, where the correct Tags field is circled in red.As for the container vulnerabilities, I created a Tracker issue for that here that we can use to track progress/updates, if needed: https://tracker.ceph.com/issues/57181On Wed, Aug 24, 2022 at 10:47 AM Ernesto Puerta <epuertat@xxxxxxxxxx> wrote:Hi Cephers,_______________________________________________These are the topics covered in today's meeting:For a detailed description of the topics above, please visit:
- Container vulnerabilities: in the last Ceph Users-Devels Monthly meeting Gaurav Sitlani raised a question about the vulnerabilities reported by quay.io and what the process was to tackle them.
- Currently Ceph relies on Github's dependabot to scan and fix vulnerable dependencies (mostly NPM packages). However that's not enough for distro package vulnerabilities.
- Quay.io is very effective at that, but currently the project is not closely inspecting those.
- Good news is that Quay offers a REST API that could be used to fetch (pull) or notify (push/webhook) the vulnerabilities in the containers.
- David & myself will have a look at this.
- Tracking CI failures: there's been a recent surge in the number of CI failures (partly related to the recent upgrade from Ubuntu 20 to 22). Developers sometimes struggle to see whether those come from their PRs or preexisting issues. Some ideas that could help here:
- Reporting test/CI failures to https://tracker.ceph.com and adding the 'test-failure' tag.
- Using the Jenkins Failure Cause Analyzer (already done for some CI jobs, like the API).
- Coverity scans: Ceph project relied on coverity scans until 2018, when due to the adoption of newer C++ features (C++17) it stopped working. However, it seems that it's now working again even with C++20 enabled.
- David Galloway's succession: unfortunately (for the Ceph project) David has decided to move on, so it has been started the conversation to identify all the things that David did (which are a lot) and find back-ups for those.
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
--Laura Flores
She/Her/Hers
Software Engineer, Ceph Storage
La Grange Park, IL
lflores@xxxxxxxxxx
M: +17087388804
![]()
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
