owned this note
owned this note
Published
Linked with GitHub
# Pulpcore team meeting
## Overview
* [Core SME List](https://hackmd.io/@pulp/core_sme)
* Release rotation (2 months)
* CURRENT: ggainey - March, April
* [ggainey] decko gerrod dkliban dalley mdellweg ipanova
* cheat sheet https://hackmd.io/gbTfH231RK-u1J2qjCcMLw
* Meeting lead (2 months)
* CURRENT: mdellweg - March, April
* [mdellweg], decko, ipanova, dalley, dkliban, ggainey, gerrod
* Github issues in the last 7 days
* https://github.com/pulp/pulpcore/issues?q=is%3Aissue+is%3Aopen+created%3A%3E2023-01-17
* Security Alerts:
- https://github.com/pulp/pulpcore/security/code-scanning
- https://github.com/pulp/pulp_file/security/code-scanning
## Meeting Agenda
* Pending-AI review
* Upcoming items
* 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
## Pending AI
* ~~AI: [ggainey] investigate updating check_release to look for requirements.txt changes~~
* ~~version-bump tag changed so check_release is currently broken~~
* ~~https://github.com/pulp/plugin_template/pull/851~~
* ~~https://github.com/pulp/plugin_template/pull/854~~
~~* AI: dkliban opening issue to move plugin-template to bump-my-version~~
* https://github.com/pulp/plugin_template/issues/850
* AI: check-release: ggainey to investigate whether we can rely on tag instead of release-commit-strings
* AI: (ggainey) write/run a script to clean up ruby gems
* in-progress
* remaining: "pulp_deb_client", "pulp_certguard_client", "pulp_npm_client", "pulp_ostree_client"
* yanking maven releases
* rate-limit throttling result in roughly 1 yank/minute over time
* 5K(ish) .dev releases to go (counting all repos)
* should be done...this quarter? ish?
* not all 'dev' releases have 'dev' in the version (e.g. pulp_maven_client-0.1.**0b31579208999**) :(
* yanking still shows on pypi
* API is rate-limited
* https://guides.rubygems.org/rubygems-org-rate-limits/
* "10 request/10 minutes on gem yank - DELETE /api/v1/gems/yank"
* "300 requests/5 minutes and 600 requests/25 hours"
* script https://gist.github.com/dkliban/15cd74a1966451ba4987a12de05dc433
* AI: mdellweg create a milestone for 3.55 (breaking changes).
# April 2, 2024
* [pedro] Discuss OpenPG support draft PR (might interest COPR):
* https://github.com/pulp/pulpcore/pull/5133
# March 26, 2024
* Remote Authentication, Pulp behind API Gateways and OpenAPI schema
* OpenAPI advertises only Basic/Session auth
* info put into OAPI via drf-spectacular
* auth-backend being used in services is Different - looks for a third-party header
* need to augment OAPI in a way to "know about" this
* i.e., advertise the *gateway's* auth-url/workflow
* https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#implicit-oauth2-sample
* Fun With Pulp-CLI will then ensue :)
* as long as the pulp admin sets this up following the OAPI Standard schema for a security-workflow, pulp-cli should be able to consume it
* AI: [dkliban/decko] get an issue up for pulpcore-side work, docs
* rubygems.org MFA
* proposal:
* all current users of the 'pulp' login at rubygems.org get a 'personal' rg.org account
* ggainey, dkliban, bbouterse, dalley
* all such accounts turn on MFA
* THEN, all such accounts are marked as 'owners' of pulp's gems
* THEN, pulp login turns on MFA
* AI: ggainey to setup login, MFA, ownership and explore API access
# March 19, 2024
* For Satellite, Bugzilla is being phased out in ~2 months, do we have any existing Jira integrations which we can adapt?
* Otherwise: we need to create one
* https://github.com/pulp/pulp-ci/actions/runs/8343502322
* we need someone to look into replication feature request [4637](https://github.com/pulp/pulpcore/issues/4637)
* re-rooting content-app discussion
* https://github.com/pulp/pulp-oci-images/issues/605
* https://github.com/pulp/pulpcore/pull/5011 fails w/out a fix for 605
* get 5100 backported/released for 3.49
* discussion RE [PR 4761](https://github.com/pulp/pulpcore/pull/4761) - [Stable task-resource identifiers](https://github.com/pulp/pulpcore/issues/4315)
* will be a 3.55 breaking change
* AI: mdellweg will review this week
* discussion RE handling old-tasks and filtering
* need to be able to convert between HREF to PRN
* old-filters are still used in MANY PLACES
* does this change the plugin API? -no, we're good
* this either blocks the 3.55 release, *or* we carry the deprecated code until the breaking-chg-after-3.55 - fun!
# March 12, 2024
* [lmjachky] migrating large amounts of data in pulp-container
* artifacts store JSON data, we want to get rid of the artifacts and have the data stored in the Model instead
* migration vs django-command (cost–benefit analysis)
* considering downtime (pulp/Katello/Satellite)
* transaction timeout?; migration can run once, if it fails, it fails
* storage far-away can/will increase time
* what if artifacts missing?
* pulp_gem process
* new-model
* migration added new-model
* mgt-command to populate new-model
* old-model would continue being available until all-new-models available
* what if:
* migration adds field
* code knows both old/new way
* django-admin then migrates the data
* "agreed solution":
* 1 migration to add the field, raise warning to run the management command
* add codepaths to accept both versions
* management command to migrate the data and report on missing artifacts (can be rerun)
* Later release remove extra codepaths and management command (force that the new field is not None in the migration or migrate the rest) and add the migration that forces the "migration"
* Document zero downtime upgrade procedure
* [dkliban] Replication feature request
* https://github.com/pulp/pulpcore/issues/4637
* 4637 will be treated as a bug (because it's eminently backportable), dkliban to open an issue/RFE "handle making direct modifications to a Replicant, and then re-replicating"
# March 5, 2024
* django-lifecycle update breaks us
* [this](https://github.com/rsinger86/django-lifecycle/pull/151/files#diff-ccd0462c3332b1460bdeefa901260186d8b9de888e6acd16c6d63a0fbbbe2c27R85) change doesn't work if hashmap included
* AI: mdellweg - teach dependabot to ignore 1.2+ changes (DONE)
* AI: ggainey to open issue w/ django-lifecycle project
* https://github.com/rsinger86/django-lifecycle/issues/155
* AI: all - if there are breaking-changes desired, we have 4 weeks to get them in
* 3.55 is Coming!!
* nice to haves RE release-process:
* changes to requirements.txt being noted as "releaseable"
* AI: [ggainey] to investigate updating check_release to look for these
* what about test-infra?
* don't need changelog entries (or at best .misc)
* "I need a release of a fixture that my plugin needs to use" is the reason for a z-release with just-test-update
* teach towncrier/release-script to auto-create a changelog entry for all req.txt changes since last Z
* maybe keep this in the bnack of our heads as "something to automate better" when we have some free cycles
# February 27, 2024
- chunked uploads of big file are slow because of default nginx client_body_max_size is 1mb
- task unblocked_at is ready for reviews
# February 20, 2024
* pulp_last_updated field
* https://github.com/pulp/pulpcore/issues/5033
* https://github.com/pulp/pulpcore/pull/5036
* ipanova will summarize the outcome - expose everywhere just document
* task created_by - there may be a timing window w/ task dispatch?
* mdellweg to open an issue w/ discussion therein
# February 13, 2024
* Github PulpOrganization/Core membership
* help!
* what about pypi/rubygems.org?
* more coverage needed
* we need to figure out how to handle 2FA for these sites
* more volunteers needed
* bitwarden locker?
* need to fix the immediate need (not enough coverage) *now*
* long-term, maybe discuss Better Ways
* dalley, mdellweg, ggainey, dkliban volunteers for pypi access-keys
* mdellweg, ggainey, dalley, bmbouter volunteers for RubyGems.org
* ggainey wants to be added to the pulp org in github
* we should audit permissions "regularly" (once/yr)
* memory spike fix discussion https://github.com/pulp/pulpcore/pull/5049
* affects large/mature Pulp installations, sometimes quite badly
* large change - more eyes please, once it's out of draft
* "supported branches" and "lower bounds tests"
* pulp_deb had, as a lower-bounds, a not-in-supported-branches pulpcore
* examples: pytest<8 and black<24 and pulp-smash-removal issues
* all LBs "should" match a supported-branch
* Probably not solvable in a generic way. We'll fix this when it comes up.
# February, 6, 2024
* Python 3.9 and CentOS 9
* katello wants py3.11 "now"
* configurable py-vers and updated base-image - how do we make sure they don't conflict?
* we already know how to tell branches to use a specific-image-tag 9eg, we have older branches that need py3.6)
* centos9 doesn't "have" py3.8
* do we want to bump main-compat to 3.9+ ?
* yes please
* 3.8 is EOL "soon" (upstream)
* downstream(s) are on 3.9 already
* to do this:
* images to centos9 (ie py3.9)
* *then* configurable-py-version
* older-supported-branches?
* new image gets anew name
* current branches continue to use existing name
* plugin template needs to enable specifying image-by-name (it may already)
* AFTER this all works, review supported branches and decide which ones need to "move up" py-vers-images
* need images for diff py-vers (oci-images already discussing making this happen, and making it selectable)
* https://github.com/pulp/pulp-oci-images/pull/575 is the in-progress work
* currently stalled (s6 deprecated functionality)
* AI: gerrod to take over PR, gerrod/dalley to sit down w/ mikedep to resolve current issue
* dkliban is a resource for finding the right s6 folks to talk to
* Repository deletion memory spike https://github.com/pulp/pulp_rpm/issues/2280#issuecomment-1928769513
* problem affects both up- and downstream
* publishedartifact "seems to be" the current culprit
* see possible approaches in links mentioned in 2280
* this prob needs to be addressed at pulpcore level
* let's handle this at a generic/consistent level (see Hap's blog post)
* poke Hap and ask if he wants author-credit if we expand on his examples
* dalley to experiment in pulp_rpm, and move to pulpcore once we have something working
# January 30, 2024
* pytest<8
* core, deb, rpm, certguard are addressed
* core needs backports
* AI: ggainey to sheperd those backports
* every plugin needs to update their test-requirements
* do we want to install into base-image?
* pytest shouldn't be in production image
* if installed in the image, we might not "notice" problems until *much* later
* plugins have their own test-requirements
* shows us (again) upperbounds-required protects us
* should we have something in plugin_template to address this as part of ci-update-next?
* AI: mdellweg to prepare such a thing
* do we really need to have an upperbound on Everything?
* lint/test reqs are safer for products to not-require-UB?
* dependabot would yell at us when updates come up
* does it? - yes
* would allow us to *plan* accepting updates
* yes please?
* AI: [all] plugin leads need to open an issue and update their test-requirements to "reasonably pin" upperbounds
* AI: [ggainey] add to discourse-discussion with an explanation for this
* note on "why we don't use pip-compile"
* Dependencies on release branches.
* is there some way to evaluate dependencies for release-branches?
* https://github.com/pyupio/pyup?
* https://safetycli.com/
* https://pypi.org/project/safety/
* changing deps to allow "newer" *can* introduce issues
* new deps *can* be incompatible with other entangled deps
* if just relax UB, shouldn't be an issue
* discussion around pip-compile and "pin exact versions always"
* prob not a Good Idea for us
* if we were using Pulp to curate our own content, we would maybe have not been affected by this?
* better to break our CI than our upstream
* "our" scale is significantly different than "pulp users" scales
* Pulpcore certguard docs still not able to publish.
* https://github.com/pulp/pulpcore/actions/runs/7641605467/job/21019289431
* still an ssh-key/permission problem
* waiting for a run
* AI: [dkliban] to try and fix manually
* core/3.22.X to be released (jinja update)
* backport releases are often done by not-the-release-sheperd
* core docs conversion update
* Pedro/Dennis have a draft PR for core-migration!
* https://staging-docs.pulpproject.org/ for progress!
# January 23, 2024
* orphan_for filter ready for review: https://github.com/pulp/pulpcore/pull/4668
* LTS branches
* what is The Process?
* can't support more than 5 +/- 3 branches at a time
* OTOH - product-lifecycle suggests "support for 3 years"
* can we add a "list of supported versions" to the spreadsheet/matrix? Can we make that happen with Spreadsheet Magic?
* downstream/Pulp communication is a fertile ground for missed communications
* stakeholder/pulp teams need to be Very Explicit about this
* what if we choose "breaking + 2" as "always a supported release"?
* any new feature request/migration issues would mitigate against this
* what *can* we do/control?
* no drawing to an inside straight, for stakeholders :)
* we can be more explicit about "these are the branches we currently allow backports to"
* lead-to-stakeholder communication
* "look at template.cfg", and/or support matrix
* each core-team-mtg, review currently-supported branches and decide if something has gone EOL
* problem: stakeholder moving to a new branch wants no-regressions
* if you backport to "A" supported branch, you need to backport to all supported branches in between
* if stakeholder moves to "not latest but newer than current-lastest-supported", then they might be missing backports
* AI: stakeholders need to stay in close comms w/ stakeholder leads RE supported versions
* AI: stakeholders cannot move to "random" branches
* AI: backports have to happen "in supported branch order" (No Regressions)
* AI: support-matrix is Controlling - be aware of it!
* AI: let's think about how we actually *retire* old branches?
* always a challenge
* AI: [mdellweg] open issue in plugin-template to separate "latest release" and "stakeholder supported" branch-lists for us
* mdellweg to do next release
* certguard merge blocking 3.45 - let's get it removed
# January 9, 2024
* Today's release may have some Issues due to pypi API access changes
* mdellweg continues as release-nanny for now
* Do we want to bump minimum Python version to 3.9?
* oci-images (PR draft?), plugin-template prob need changes
* PR bumping oci-images to EL9 and Python 3.9 https://github.com/pulp/pulp-oci-images/pull/554
* what does 3.9 get us?
* still needs monkeypatch to enable TLS-proxy support
* need 3.11 to not-do-that
* bumping in oci-images means we no longer test on 3.8
* can/should we get signoff from stakeholder leads?
* RHUI/Satellite on same rpms (3.9 for current-support)
* what if oci-images had multiple python-version images, and branches used "oldest supported"?
* what's the proposed "long term" python-version to be supported?
* maybe whatever is in F40?
* 3.12 on F39
* maybe pick 3.11?
* conclusion: we're not ready to do this yet
* bumping aiohttp to 3.9.0+ and python-cryptography to 41.0.6+
* stakeholders want bugfixes
* need to think about which branches need them
* need to make sure branch-upper-bound *allows* fixed version(s) to be installed (main branch already ok)
* mdellweg to pick this up
* Orphan cleanup: https://github.com/pulp/pulpcore/pull/4841
* Can't find a way to be compatible with orphan_for filter: https://github.com/pulp/pulpcore/pull/4668
* maybe close 4841 in pref for 4668, and then change tests in https://github.com/pulp/pulp_rpm/pull/3313 to take advantage
* conclusion: yes please
* Note: if pulp stopped allowing content outside of repositories, the need for this goes away
* implications on uploads (mostly)
* impacts "what is the change-diff" (can address in other ways)
* see also container's "pending blobs" solution
* last-touched and sync implications
* PyPI credentials update
___
# Archive
* [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`