Pulpcore team meeting

# Pulpcore team meeting ## Overview * [Core SME List](https://hackmd.io/@pulp/core_sme) * Release rotation (2 months) * RELEASING: https://github.com/pulp/pulpcore/blob/main/releasing.md * CURRENT: mdellweg - March, April * ggainey decko gerrod aklimau dkliban jitka dalley * Meeting lead (2 months) * CURRENT: ggainey - March, April * gerrod mdellweg decko aklimau dalley dkliban jitka * Security Alerts: - https://github.com/pulp/pulpcore/security/code-scanning ## Meeting Template ``` ## MMM DD, YYYY ### Pending-AI ### Agenda * (agenda items here) * Open PR review * [core non-draft open](https://github.com/pulp/pulpcore/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+) * Collect Action Items, copy to Pending-AI of next meeting ``` --- ## Mar 31, 2026 ### Pending-AI * dalley to open an RFE for adding signing-fingerprint to RPM MinimalPackageSerializer * https://github.com/pulp/pulp_rpm/issues/4393 ### Agenda * (agenda items here) * Open PR review * [core non-draft open](https://github.com/pulp/pulpcore/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+) * Collect Action Items, copy to Pending-AI of next meeting ## Mar 24, 2026 ### Pending-AI * ~~[tshakirava] to do some Jira work to get this (signing-refactoring?) on our roadmap * There are some upstream demand, but we don't know our downstream requirements on this. * No Jira to create yet ### Agenda * Can anyone think of a reason why it would be a BAD idea to copy labels by default, when creating a new content unit from an existing one (by signing it)? * Main concern: once you've signed, and copied the labels, is there an easy way to tell the difference between the signed and unsigned copies? * users search-by-label A LOT and need to know what they're getting * as long as they can discriminate by expected-key - should be ok * what about rotations of keys? - users' responsibility * Q: do we need signing-key in minimal RPM package serializer? A - almost certainly * AI: dalley to open an RFE for this * Open PR review * [core non-draft open](https://github.com/pulp/pulpcore/pulls?q=is%3Apr+is%3Aopen+draft%3Afalse+) * Collect Action Items, copy to Pending-AI of next meeting ## March 17, 2026 ### Pending AI * ~~[decko] to ping hyagi RE https://github.com/pulp/pulpcore/issues/7367 (done)~~ * [tshakirava] to do some Jira work to get this (signing-refactoring?) on our roadmap * ~~[mdellweg] add core/105 to supported branches at release today~~ * ~~[ggainey] open an issue in each plugin requesting supported-branch changes to support next katello release~~ * https://github.com/pulp/pulp_rpm/issues/4366 - 3.35 * https://github.com/pulp/pulp_container/issues/2257 - 2.27 * https://github.com/pulp/pulp_python/issues/1137 - waiting on a release for 3.27? * https://github.com/pulp/pulp_ansible/issues/2462 - 0.29 ### Agenda * datarepair API naming conventions * https://github.com/pulp/pulpcore/pull/7467 * /datarepair/2345/ vs. /datarepair/fill_content_ids/ * /rpm/datarepair/{id} (example with plugins) * bmbouter: wants any migration to have a "bail out" option to make sure it does not execute if it will be long-running * also, merge the operations or not? * do we want to continue "one API per issue-number", or combine? * what if we change issue-trackers? * human-readable-names * api-having-tracker makes discussion easy to find - BUT, the links to issues/prs/docs can all be in the API JSON description * already made a decision to not-centralize plugin-related data repairs into the pulpcore-API * lots of discussion ensues around "what do we do if/when we want to force a repair to Finally Happen in amigration" * thought: for *some* of these migrations, we may want to have a setting for "run the migration or not" * Metadata signing concerns update? * hyagi addressing operator-issues of 7367 "today" (release in-progress) * Content signing key tracking, schedule a meeting * preliminarily Thursday 11:00 EDT (march 19) * lots of stakeholder-discussion ensues * discussion around release-blockers * {%preview https://github.com/pulp/pulpcore/pull/7467 %} * also replication-atomicity PR * discussion around upcoming issued opened RE missing indices * pulp_labels * domain/artifact-size * migrations: check whether Django is locking the table or not * PRs will be incoming ## March 10, 2026 ### Pending AI * ggainey to archive 2025 minutes * https://hackmd.io/@pulp/core_2025 * decko to ping hyagi RE https://github.com/pulp/pulpcore/issues/7367 * tshakirava to do some Jira work to get this (signing-refactoring?) on our roadmap ### Agenda * katello is branching 4.21 and would like to settle on core/105 as a base * what plugin versions should they use/wait-for? * rpm (3.35) * container (2.27) * ansible (0.29) * python (3.26) * deb (3.8) * current-released-versions? * note: whatever we pick, becomes a a"supportred" branch in the plugin * AI: ggainey to open an issue in each plugin requesting that supported-branch change ## March 3, 2026 * "Metadata signing concerns" - Gitlab * https://github.com/pulp/pulpcore/issues/7367 * discussion ensues * documentation missing/incomplete on key management * can't set up signing service via API * for *keys*, RPM allows API access * want to generallize this for all plugins * COPR has similar issues - bypassed by doing their own signing * any redesign here needs to consider security first * the referenced issue calls out more than one Thing * docs * inconsistency * missing functionality * pulp-operator ease-of-use * one signing-service per-key - except RPM * RPM allows a key-fingerprint-per-repo * this should be generalized * when considering a redesign: * keep it secure * don't make more limits than we have now * make it consistent * consider the entire lifecycle of signing (CRUD for key-signatures) * don't break the signing-service-api if you don't have to * what "should" happen if you have a signing-service but no key-fingerprint defined? * is there anything we can do *now* to ease the reporter's problem * work w/ gitlab to understand their urgency * AI: ggainey to ping hyagi and ask him to take a look at the issue ## February 24, 2026 * Atomic replication * https://github.com/pulp/pulpcore/issues/7333 * Repositories within a replica are not coordinated in their distribution updates, they update "randomly" over the course of minutes/hours as tasks complete * SAML integration * Users have reported that it may be something that their internal infosec teams require or will require - without it it may cause Pulp to be red flagged * Maybe the only user we know of that needs this currently? * Andrew to file GH / Jira issues * A different approach to CLAUDE.md * https://github.com/pulp/pulpcore/pull/7345 * example output: https://github.com/pulp/pulpcore/pull/7347 * Status on precommit, UV, Ruff, CI makefile efforts? * How do point the agent to perform these consistently? * technically, pointing to the lint workflow file should be enought for the agent for now * https://discourse.pulpproject.org/t/proposal-using-pre-commit-for-static-checks/2170/6 * tldr: discarded pre-commit plan, will try a make-like runner (make lint) * Email from Eric re Pulp Vulnerability Scanning - forwarded to pulp-internal ## February 17, 2026 * Upstream contributions for: * https://github.com/pulp/pulpcore/issues/7314 * https://github.com/pulp/pulpcore/issues/7315 ## February 10, 2026 * Need to plan plugin coordination on error handling * COPR discussion * Releases? yes, but only patch ## February 3, 2026 * Question on https://github.com/pulp/pulpcore/issues/7272 * Data migration yes or no? * Brian: prefer no, long running tasks are an issue, want to parallelize across domains if possible * Maybe have a domain-specific admin-only `/fixups/issuenum/` API that would take an issue # as argument, would give services owners more flexibility about applying the fixes * Management command should also report domain * Release today? * yes ## January 27, 2026 * Post quantum crypto - certguard impact? encrypted fields? * certguard relies on OpenSSL * encrypted fields used python-crypto * doesn't digest, encrypts with a key * implications? * prob not quantum-crypto related, but "store key on disk" is less than great * do we need to add to allowed-artifact-signatures? * adding more signatures should wait until we redesign how we store signatures * How to deal with flakey tests? * currently: cancel task group * what if we have a "runs forever" task-fixture? * PyPI * we have access back to the "pulp" login - yay! * lots of "sole owner" projects still * We actually were **approved** for a PyPI org in April - double yay! * https://pypi.org/org/pulpproject/ * currently a Community project * ggainey contends it's worth the effort to convert to Company - thoughts? * FYI: probably a good idea to set up backup token 2FA parallel to the emergency codes on the main account * we've burnt several of the codes, need to refresh? * take domains officially out of tech-preview? * if we're making them mandatory in Pulp 4, then yeah, makes sense * Feedback on PR template? * Not a bother to anyone so far * Wait a few weeks, add to plugin template ## January 20, 2026 * Testing RedisWorker in GitHub actions * https://github.com/pulp/pulpcore/issues/7210 * discussion RE pulp-hugging-face and pypi and publishing * everyone had A Sad * Add checkboxes to “new PR” github template? * [x] Commits are cleanly separated and have useful messages * [x] A changelog entry or entries has been added * [x] Documentation is thorough * [x] Includes test coverage * [x] Follows the Pulp policy on AI Use * (I bring it up specifically for the AI use policy bullet point - users don't otherwise know about it) ## January 13, 2026 * whose email is associated with the "pulp" login on pypi? * access *at all* requires a link sent to that email be activated from the device attempting to log in * pulp_npm can't currently be published * whose emails are on the pulp-infra@ list/alias? * pypi Organization * When Last We Looked, this was kind of not-happening * there is now a paid position to process, and they're (mostly) caught up! * "we" are almost certainly going to be viewed as a "commercial organization" * that means $5/month per member (person with pypi access to projects) * feels like we should be able to justify, say, $25/mo to pypi - that would give us up to 5 "member" logins to manage our pypi presence * AI: ggainey to discuss details w/ Andrew * Django5 backporting * Pedro's [brilliant overview](https://hackmd.io/@pbrochad/pulp-django5-backports) * need to add the django-import-export-4 tweaks to this * pulp container backport: https://github.com/pulp/pulp_container/pull/2152 * backport to core 3.49, 3.63, 3.73, 3.85 ## January 6, 2026 * plugins need to update/release to pulpcore<3.115 * django 5 * we'll have to backport making it possible to run django 5 * that means a non-trivial amount of work for stakeholders' build team * known problems: * there is a backport in pulp_container * compatibility on import/export on existing installations * which branches will require backport? * core/3.63, 3.73, 3.85 * plan: let's stabilize 3.100 and then start backport work ___ # Archives * [2025 meeting notes](https://hackmd.io/@pulp/core_2025) * [2024 meeting notes](https://hackmd.io/@pulp/core_2024) * [2023 meeting notes](https://hackmd.io/@pulp/core_2023) * [2022 meeting notes](https://hackmd.io/@pulp/core_2022) * [2021 meeting notes](https://hackmd.io/@pulp/core_2021) * [2020 meeting notes](https://hackmd.io/@pulp/core_2020) ###### tags: `pulpcore`

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.