# 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: dkliban - Sept, Oct
* jitka dalley mdellweg ggainey decko gerrod

* Meeting lead (2 months)
* CURRENT: dalley - Sept, Oct
* dalley dkliban jitka ggainey gerrod mdellweg decko

* Security Alerts:
- https://github.com/pulp/pulpcore/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

## Upcoming

# September 2nd, 2025
* dalley note: unavailable due to travel for a funeral, someone else host

# August 26, 2025
* can we add an API call that takes a "naked" PRN and returns the object?
* HREFs know the route, which knows the type - a naked-prn API would only know "I return a serialized entity"
* we show PRNs to users of the API, but there's no way to "use" it unless you know the HREF to hand it to
* discussion ensues
* would we have to reimplement the DRF routing?
* turn PRN into HREF and then find viewset and return what it points to
* /v3/ vs /v4/?
* maybe not worry about it till someone (other than ggainey :) ) asks for it
* Pulp4 still has HREFs, but you don't use them as params - maybe Pulp5 could switch to only PRNs?
* on the pulp-cli front, there is a path forward
* register a PulpContext's PRN-model at startup time
* when a PRN is used, CLI looks up the context by app.model and then has enough info to build the associated HREF
* gerrod's brainstorm:

            an idea of prn's as hrefs:
            /pulp/api/v5/prn:file.filerepository:list/
            /pulp/api/v5/prn:file.filerepository:create/
            /pulp/api/v5/prn:file.filerepository:{pk}/ (show)

* where are we w/ CI and release-branches?
* core/file/certguard are fine
* gem is done(?)
* ansible/container are done
* npm/maven/ostree need to be reviewed
* deb?
* jitka as release-nanny - Sep/Oct doesn't work

# August 19, 2025
* need: only have API calls that need to generate tasks generate tasks
* see https://issues.redhat.com/browse/PULP-734
* 3 specific changes proposed currently
* ggainey: big pros, almost zero cons
* dkliban: create issues in the upstream
* Tasks getting stuck in waiting in 3.84+
* https://github.com/pulp/pulpcore/issues/6873#issuecomment-3200674922

## Aug 12
* [3.85 milestone](https://github.com/pulp/pulpcore/milestone/14)
* all the work is done
* pgres16/core issue to be closed pointing to work in oci-images
* let's push the button!
* so what next post-3.85?
* all plugins need to update UB to core<3.100
* all plugins need to evaluate whether to do a Y-release or just update current-Y
* **IF** doing a Y-release - update python-min-supported to be 3.11
* plugin_template needs an update to not-allow-old-django-storage
* set `test_storages_compat_layer: False`

## Aug 5
* [3.85 milestone](https://github.com/pulp/pulpcore/milestone/14)
* [discourse post](https://discourse.pulpproject.org/t/attention-pulpcore-3-85-soon-coming-to-a-release-near-you/2080/3)
* [postgres update](https://github.com/pulp/pulp-oci-images/pull/746)
* [py3.11](https://github.com/pulp/pulp-oci-images/pull/741)
* discussion around timing/releasing
* maybe avoid releasing immediately-after a merge of one/several of these - get these in *now*, please :)

## July 29
- Check in on 3.85 blockers
- https://github.com/pulp/pulpcore/milestone/14
- django 5 prep
- remove legacy storages
- The actual django 5 upgrade should be deferred
- until when? 3.100?
- proposal: aim for 3.100 being django 5
- implies "start investigation implications *as soon as* 3.85 is released"
- upgrade Python to 3.11
- upgrade postgres to 16
- update openapi to 3.1.x
- purge migrations
- AI: ggainey to post reminder to discourse
- 3.100 is next-breaking-change

## July 22
* What is our position about AI generated code? - Part 2 discussion. Need to bring this point to the upper level mgmt
* https://www.linuxfoundation.org/legal/generative-ai
* https://source.redhat.com/departments/legal/legal_compliance_ethics/compliance_folder/appendix_1_to_policy_on_the_use_of_ai_technologypdf
* https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators
* do we want/need to coordinate w/ theforeman/katello (since we all build together?)
* Snyk integration for oci-images
* currently enabled!
* access to reports requires formal/budget-related process
* doesn't "feel right" for upstream?
* there's a free version that offers limited number of reports/month (200?)
* would need to create an upstream-org, in Snyk, as an open-source project, for Pulp (ie not 'Red Hat')
* this would make everything a lot more public/accessible
* thoughts?
* consensus: sounds like a *fine* idea to the team
* let's make this happen
* will tie to a mailing-list address
* watch the ticket ([748](https://github.com/pulp/pulp-oci-images/issues/748)) for progress

# 2025 July 15
* Revisit constraints files to make containers vulnerability aware. (Came from Snyk report discussion.)
* First step: enable Snyk scanning https://github.com/pulp/pulp-oci-images/issues/748
* So pulp images will be scanned for vulnerability issues
* User Contribution: Avoid Concurrent Downloading:
* https://github.com/philfry/pulpcore/tree/concurrent_downloads
* https://github.com/pulp/pulpcore/issues/6584
* https://github.com/pulp/pulpcore/commit/34d6eeb8c2bab2a2dde27a1df6f7203211ec24c1
* A user brough a demand about downloading a piece of content just one time.
* User is doing all the heavy lifting. We should guide him.

* Data model memoization results and next-step
* Pretty good results so far:
* broke repos with 66k rpms in them: https://github.com/pulp/pulpcore/issues/6772
* pre-upgrade publish task taking 5-6 minutes now takes seconds
* no longer showing on the RDS top queries page, previously was our top query there

* Question: Should we do away with Orphans, and all content must be associated with a repo
* Motivation: the top SQL query from Pulp is the artifact_touch timestamp
* Motivation: touch() has repeatedly been the source of deadlocks on high-load systems
* dalley: would simplify any RBAC scheme also.. do we need some kind of "holding area" repository without validity checks?

# 2025 July 8
* Package signing in Pulp
* New plugin? - https://hackmd.io/oKF7H8iQTAOorBkoMwXtKg
* Use existing functionality but fill in gaps:
* Make signing idempotent - https://github.com/pulp/pulp_rpm/issues/4044
* Check package signatures before signing - https://github.com/pulp/pulp_rpm/issues/4045
* Multi-repo uploads - https://github.com/pulp/pulpcore/issues/6766
* https://github.com/pulp/pulp_rpm/blob/67e07a66e74597a7e09b1c8d91ed209a23e5dfe6/pulp_rpm/app/tasks/signing.py#L24
* Multiple signature support on RPM - https://github.com/rpm-software-management/rpm/issues/189

# 2025 July 1
* Package signing in Pulp - https://hackmd.io/oKF7H8iQTAOorBkoMwXtKg
* David Davis will come to the next pulpcore meeting to discuss this.
* What is our position about AI generated code?
* WE are an open source project. We need to track
* Start a technical discussion on project level.
* What is possible and what's not?
* We attach people's name to their contributions.
* Could there be any copyright issue with the contribution?
* Technical is part of the discussion. Legal and Public relations is also important topics.
* What is our intention and what we want to use?
* Maybe get a feedback from the community?
* Revisit the contribution guidelines
* Check resposibilities
* Maybe annotate the AI usage/involvment in the code?
* Check the company policy first and then revisit the contrib. guidelines.
* Bring this point again in the next meeting

# 2025 June 24
* Snyk vulnerabilities reported
* Proliferation of *API_ROOT variables and whether they can be consolidated
* https://github.com/pulp/pulpcore/blob/44924a522af08b6a9eb63661b6c05e5eecf5f27d/pulpcore/app/settings.py#L647-L654
* https://github.com/pulp/pulpcore/blob/44924a522af08b6a9eb63661b6c05e5eecf5f27d/pulpcore/app/urls.py#L31-L38
* https://github.com/pulp/pulpcore/blob/44924a522af08b6a9eb63661b6c05e5eecf5f27d/pulpcore/app/util.py#L34
* [https://github.com/pulp/pulpcore/blob/44924a522af08b6a9eb63661b6c05e5eecf5f27d/pulpcore/openapi/__init__.py#L37-L45](https://github.com/pulp/pulpcore/blob/44924a522af08b6a9eb63661b6c05e5eecf5f27d/pulpcore/openapi/__init__.py#L37-L45)
* Use of settings and how they "count" (or not) as part of the plugin API
* https://github.com/pulp/pulp_ansible/blob/main/pulp_ansible/app/urls.py#L252-L259
* see also: pulp_rpm, pulp_deb
* https://github.com/pulp/pulp_rpm/blob/main/pulp_rpm/app/urls.py#L11
* https://github.com/pulp/pulp_deb/blob/main/pulp_deb/app/urls.py#L12

# 2025 June 17
* Tasking / RBAC updates
* Task consumption test - Tested some scenarios with workers consuming tasks. Last step is to analyze task data, like, waiting time, and system metrics.
* The first two tests (worker scalability and task insertion) are already feeding some insights and pulpcore tickets.
* RBAC Working Group Update
* will be in discourse soon
* links to recording/minutes will be posted
* SAML integration is biggest missing piece
* there are projects out there to do this in django already
* need to learn more about these
* this is going to take A While (lots of work to do, resource constraints are a Thing)
* Vulnerability Reporting
* prototyped in services-repo
* osv.dev report
* plan-of-record : contribute the POC code to pulpcore
* want to do that by 3.85
* services-team would handle the handover
* some quick-and-dirty code needs to be adjusted to fit more cleanly into the plugin architecture
* core holds models
* plugins would own adding a viewset (post-3.85)
* anyone want to volunteer to be Primary Reviewer for this contribution, let Services know!
* Tasking scale/uploads
* see discussion in Matrix RE COPR
* Hosted Install is *primarily* upload (as opposed to Satellite/RHUI that are primarily interested in sync)
* current tasking system currently can't keep up with likely load (even from just one stakeholder like COPR)
* experiment: upload happens synchronously "inside" the API call
* tests are promising, but need more "real world" experience (eg, on-actual-S3)
* would be cool to extend dalley's testing-infra into the API call itself
* ttereshc: talked to COPR at devconf
* we need to address this before COPR can fully-migrate
* bmbouters: COPR wants to do a full pypi rebuild, and we need them to wait until we have some success here
* ggainey: let's plan for Massive Success in the future, rather than "today's workload"
* ttereshc: COPR is asking for 5x more than today's upload-load

# 2025 June 3

* Moar RBAC - https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974/9
* New feedback from enterprise existing users causing us to explore another direction
* An existing example: Jenkins
* How Pulp could do it this way too
* Immediate tasks new insight.
* Assumption that content-app shouldnt run tasks because no one waits for them

# 2025 May 27
* RBAC update: see [public post](https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974/8)
* next step: build out the example with use cases, tuple data, and "test relationships"
* discussion around defaulting to py3.11
* need to make sure stakeholders know
* note that we have stakeholders that will not be updating for "a while" - so backporting fixes may run into "this works on 3.11 but not on 3.9"
* should we have a specific stakeholders-email-alias for sending notifications to?
* discussion around deploying as ASGI instead of WSGI
* doesn't DRF have trouble with this?
* investigate ADRF perhaps?
* may be computational-overhead in the API layer if we do this
* to use websockets we need ASGI
* should this be planned as a post-Django-5 Thing?
* let's disrupt one thing at a time - so, yes
* FWIW I've suggested DRF alternatives in the past https://github.com/pulp/pulpcore/issues/3793
* discussion around v4 investigation
* [dralley's experiments PR](https://github.com/pulp/pulpcore/pull/6574)
* routing is still problematic
* some views/viewsets didn't have names defined *at all* in v3
* need to investigate if fixing that requires bindings-updates
* 'Copy' viewset, for example - which is *already broken(ish)* in v3

# 2025 May 20
* ~~AI:~~ [Done] dkliban to open epic/issues and discourse post RE "switching to using django url-building" and implications thereof
* https://discourse.pulpproject.org/t/using-djangos-url-building-machinery-instead-of-content-origin/1990
* ~~AI:~~ [Done] ggainey to add note to existing RBAC discourse RE "we hear you, welcome more info, and we're investigating - will come back and report as we go"
* https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974/7?u=ggainey

## May 13, 2025
* Clarify requirement vs nice-to-have of "release lead"
* requirement: push the release-me button for pulpcore every Tues
* reasoning: so this mtg doesn't have to spend brain-time deciding whether that needs to happen
* nice-to-have: push release-buttons for plugins
* plugin-teams can/should be in control of their own release decisions
* if a plugin is ready for a release - the release-machinery is turnkey enough, it's nice to push more buttons on Tues :)
* consensus:
* "release lead" is concerned with pulpcore
* plugins will be released by their miniteams/owners
* are all the plugins covered (we believe so, yes)
* cli-plugins should also be managed by the main plugin owner
* what about cross-cutting repos? (openapi, plugin. oci-images)
* oci - owned by deployers
* plugin, openapi - don't do releases
* [ownership doc](https://docs.google.com/spreadsheets/d/1FvoiVcFG8SnSG4AIiOIaJgx9TbHomgeWa0YeN_qC4fs/edit?hl=en&gid=0#gid=0)
* what about the auto-open PRs (not related to release-role) - same as any PR - review when you see PRs needing to be reviewed/merged
* RBAC - next steps
* The "real" issue is, how do we make it possible to integrate Pulp with larger/more-enterprise authorization systems?
* conversations happening w/ Alec Henninger RE consoledot RBAC useage
* maybe bring updates/questions to this mtg from those working on this?
* decision: report + inform @ pulpcore meeting, design convo should not happen here
* AI: ggainey to add note to existing RBAC discourse RE "we hear you, welcome more info, and we're investigating - will come back and report as we go"
* https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974/7?u=ggainey

## May 06, 2025
* Dialling OTEL back to an optional dependency.
* ipv6/otel don't like each other
* are we sure otel really doesn't like ipv6?
* or is there something we can/should do to fix the reported problem
* still under investigation
* how hard is it to make it optional?
* mechanics requires chaging how one starts Pulp up to use/not-use? (esp in our-container-env)
* would need to feature-flag all the import/use in the code, for sure
* May 6th - Discuss RBAC - Bring notes from customers/stakeholders
* https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974

## Apr 29, 2025
* Improving x-forwarded usage discussion, [see this PR](https://github.com/pulp/pulpcore/pull/6513)

## Apr 22, 2025
* 4.0 Discussion
* (PulpCON slides)[https://hackmd.io/@ggainey/pulp4_proposal]
* move to OpenAPI 3.1
* is this a pulp4 Thing?
* no - can/should happen earlier/independently
* But actually, if we generate the api spec for both apis separately we could align it to that.
* does have some corner-case issues for bindings
* do it in core/3.85?
* (Pulp4 Jira Outcome)[https://issues.redhat.com/browse/PULP-330]
* plan around having a /v4/ API
* make it exist
* goal: existing bindings have to **still work** - may require openapi-spec-tweaks
* Q: do we end up with one openapi spec for the installation? or do we have a /v3/ and a /v4/ api spec?
* pulp_href removal
* discussion around "Should Pulp have RBAC?"
* gather data from actual users
* discourse discussion?
* AI: ggainey
* anecdote: in the 2to3 timeframe, external Pulp2 users *were* waiting on RPM RBAC to move
* reconvene in 2 weeks
* Need to think about "Pulp4 Release Details" specifics
* next-step-consensus: let's get a /v4/ API up and available **with no other changes** from /v3/ (see [501](https://issues.redhat.com/browse/PULP-501))

## Apr 15, 2025
* Postgres upgrade
* Satellite
* Happy w/ pgres13 due to having RHEL support
* OK with it being our call on when/how to update CI
* don't want to have to deal with modularized Postgres in RHEL
* Ansible
* on pgres-15, no plans to update
* Quay
* also on pgres-13 but willing to adapt to "whatever Pulp is on"
* discussion
* other parts of Satellite use *the same postgres* as we do
* Ansible needs some work before being able to use pgres16
* maybe just core/3.85 includes "update to newer postgres"?
* will only "break" things downstream if we use features from that newer version
* pgres15 - EOL in 2027
* packaging - supported by RHEL is really important
* so heads us to 15?
* downside is missing new features
* what's the downside to downstreams
* EL10 has pgres16
* EL9 has 15 and 16, in modules
* consensus(ish)
* let's target 16
* let's target core/3.85 release for the transition
* let's give stakeholders a rough "when"
* between 10-15 weeks before core/3.85
* discourse post
* have to get off of 13
* want some new features from 16
* 16 is widely available el9/centos10
* AI: [ggainey] get a discourse post up
* https://discourse.pulpproject.org/t/pulp-and-postgres-13/1922/3?u=ggainey
* General thoughts on https://github.com/pulp/pulpcore/issues/2007
* discussion ensues
* we're prob not going to do anything w/ this unless/until there's a pressing need
* we calculate A LOT of hashes - we should think about dropping unused ones
* https://github.com/pulp/pulpcore/issues/4726
* COPR and Cloudfront
* discussion
* open a Q3 investigation to improve content-access-latency for Services

## Apr 8, 2025
* pulp-container ready for review: https://github.com/pulp/pulp_container/pull/1965
* pulp_deb and domains: ATIX has been poked
* can/should we disable pulp_deb in single-container?
* this does need to happen "at some point" - pulp_deb has a large upstream user-base
* let's try and make other Pulp4 progress while allowing time for pulp_deb to get domain-ized
* pulp_ansible needs to be domain-ized as well
* prioritized for Q3
* discussion RE Pulp4 /v4/
* main issue dalley found
* endpoint-slugs are NOT namespaced
* sooo, the endpoints collide
* let's get an issue filed that describes this problem
* AI: [dalley] to get a pulpcore issue filed with this info
* https://github.com/pulp/pulpcore/issues/6462
* [Pulp4 doc from PulpCon](https://hackmd.io/@ggainey/pulp4_proposal)

## Apr 1, 2025
* As an organization we have [81 open, non-draft PRs](https://github.com/pulls?page=1&q=is%3Apr+org%3Apulp+draft%3Afalse+is%3Aopen)
* we prob want to address this
* Intermittent test failures (mostly on "azure") in ~1/2 of the runs.
* AI: open an issue for repeatedly-failing tests (e.g. task-purge-timing test)
* General note: when writing tests, DO NOT assume you "own" the system-under-test - anything might be happening/have happened
* Finishing domain support in all plugins: https://issues.redhat.com/browse/PULP-331
* pulp-container ready for review: https://github.com/pulp/pulp_container/pull/1965
* pulp-ansible & pulp-deb left
* ggainey discussing pulp-deb and domains w/ ATIX after this mtg
* [tanya] Which stakeholders or known large users use our RBAC? (AAP?)
* not Satellite (or RHUI)
* might be *even less* going forward, w/ IsAdmin permission class
* AAP uses our facilities w/ their own access policies
* Services has its own RBAC class
* Domain impacts - to maintain data-separation, need at least minimal RBAC
* why are we asking?
* [tanya] A reminder to prep for the sprint planning tomorrow
* Python-rhsm check in
* rhui won't own it, client-system won't own it
* we are *not* going to require all of subman for pulp just to get this functionality
* ggainey to do some (casual) investigation into "what's the minimal amount of pulp-rhsm we really need"
* would be nice to have docs
* do we care about v1 certs?
* AI: ggainey to ask pino
* AI: ggainey/mdellweg to find/create a hackmd to coordinate
* ggainey to release core/3.75 today

## Mar 25, 2025
* https://github.com/pulp/pulp_ostree/issues/435
* [fails to build](https://github.com/pulp/pulp_ostree/actions/runs/13971330526/job/39113820737?pr=437#step:12:392)
* add cairo back into oci-images? or is there a Better Answer?
* If you have a Brilliant Idea - add to issue
* AI: ggainey to complete this (one way or another) this sprint
* touch base w/ hyagi for review
* python-rhsm update
* pinotree leaving sub-client team (was the person we were working with)
* another client-tools person moved to a diff team 2 wks ago
* so - we prob will need to move this forward ourselves
* or - do we push back to client-tools management
* Next quarter priorities

## Mar 11, 2025
* What role should automatically get core.manage_content_labels?
* https://github.com/pulp/pulpcore/pull/6338
* dkliban: repo-creator should be allowed to label content
* dkliban: domains are the answer to "but users can see other people assigning labels to duplicated content"
* dkliban: should be at the domain-level - "you have domain-access and can therefore modify labels on de-duplicated content"
* pbrochado: similar to shared-remote-artifact problem (ie, "use domains if shared access is a problem")
* mdellweg: move/create filecontent_labeller to common-content-viewset in core
* what *existing* role should have labeller?
* mdellweg: repo-creator seems correct
* gerrod: upload discussion - should uploader require content-label access?
* is uploaded-content "yours"?
* lots of dicussion ensues
* there exists a check on upload for "do you own this repo (if provided)" - do the same for setting pulp_labels on content-upload
* add a new access-condition "are labels specified and do I have permission"
* consensus:
* move locked-role to core.content
* *nobody* gets the manage_labels perm "by default"
* teach upload to deny an upload if labels-specified and user doesn't have manage_labels
* docs?
* add section to https://pulpproject.org/pulpcore/docs/user/guides/manage-labels/?h=label

## Mar 4, 2025
* Update meeting lead/release lead for March/April
* Add https://github.com/oras-project/setup-oras to allowed github actions list
* adding label-metadata to our oci-images
* currently, check for "do we need to rebuild container" is ugly and brittle
* with oras available, would be Much Easier to do this
* already in-use by dkliban
* CI policy of plugin release branch lowerbounds need to be on supported pulpcore version is restrictive
* current problem: no "supported version" past core/3.63
* gerrod: should rule be less restrictive on main?
* LB requiring x.y.z is a different issue than "auto-updating LB"
* stakeholder issue?
* short-term AI: ggainey to add core/3.73 to "supported versions" of pulpcore as part of today's release
* the LB setting is partially the result of pip-dependency-hell, and partially due to the core-and-plugin architecture of pulp
* discussion around "how to tell someone did not run migrations correctly" in RE a customer issue

## Feb 25, 2025
* ggainey revisited postgres plans w/ katello
* added to agenda for 19-FEB Katello Integration mtg
* iballou to come back w/ a response "real soon now"
* ansible will need to make changes before being able to accept pgres-16+
* what should we do as an upstream project?
* as of November, we *almost certainly* need to update in November to Something Not EOL
* picking up new-version-features "by accident" would be Bad
* as in, "makes Pulp developer's lives much more complicated"
* discussion around build-realities ensues
* pgsql 16 is in centos10 https://www.centos.org/centos10/
* consensus: discuss project-needs on discourse, managers to go bother downstreams
* Discussion around oci-env and podman-compose-1.3
* sadness ensues
* for now: versionlock on podman-compose-1.2
* checkin on single-container/3.70+
* AI: bmbouter to start thread in Matrix
* we need to figure out what needs to be done to get a valid oci-image built w/ core/3.70+ and friends
* AI: dkliban to release pulp-Maven to pypi
* AI: mdellweg purge pypi of old-pulp_maven-versions
* pulp_npm *almost* "first class" plugin
* needs to get docs working
* yay for gerrod!
* wants to be added to oci-image
* discussion around remaining Q1 work

## Feb 18, 2025

* Enhance Replicate delete policy
* https://github.com/pulp/pulpcore/pull/6247
* PR allows user to customize what/how objects get deleted on replication
* protect "unlabeled" entities in case of a naming conflict?
* def need some explanation in docs about "expected behavior"
* prob for "how replicate makes decisions"
* rename to just "policy" - since it covers more than just "delete"
* Fun With AWS
* AWS client-update 15-JAN appears to have broken us
* see https://discourse.pulpproject.org/t/squeezer0-1-0-a-header-you-provided-implies-functionality-that-is-not-implemented-transfer-encoding/1900/5
* What do we need to do to move away from Postgres-13?
* downstream has current-versions that use it
* RHEL9 base
* pgres-13 is EOL in November
* we stay on 13 to make sure we don't start relying on newer-version-features for bugfixes we want to backport
* to change, need to write code in the images to handle the postgres-migration needed to move from 13 to "whatever we decide to move to"
* do we support both?
* please no
* what are downstream's plans to move to newer versions?
* Satellite
* Automation Hub
* RHUI
* AI: ggainey to revisit plans w/ katello
* new plugin from Evgeni
* experimenting w/ foreman-mod-proxy protocol plugin
* https://github.com/evgeni/pulp_smart_proxy/
* ttereshc needs some help on where to file some high-level Jira requests for pulpcore
* AI: ggainey to work w/ Tanya

## Feb 11, 2025
* Discussion: With Pulp4 remove CONTENT_ORIGIN (maybe?)
* https://github.com/pulp/pulpcore/issues/6239
* there are standards for "building URLs" - we should prob follow/use them
* CONTENT_ORIGIN is designed to be the *content* URL, as separate from the **API** URL
* removal would prevent split-fqdn deployments
* AI: [mdellweg] add some discussion to issue on this
* can we take advantage of at least some of this in Pulp3?
* discussion ensues
* all of django lives on request/response - some of Pulp, does not

* CloudFront Support
* https://github.com/pulp/pulpcore/issues/6258
* there is a formal request for this support
* geo-located support would be Really Nice for non-US-East deployments
* dalley: COPR already takes advantage of this
* Pulp-origin, backed by S3 (or something), and CloudFront cache "in front of" Pulp
* cache updates from Pulp
* clients "talk to" cache-layer
* botocore's [CloudFrontSigner](https://github.com/boto/botocore/blob/19140a929b3342fa033d4a88f5054e8c8edc96a3/botocore/signers.py#L363)
* Services needs/wants to be able to set up storage/redirect/cloudfront info *per domain*
* "timebombed" URLs need to work correctly in this instance as well
* [django-storage support](https://stackoverflow.com/questions/57956626/django-storges-support-for-cloudfront-signed-url) already exists maybe?
* https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html#cloudfront-signed-urls
* [serializer](https://github.com/pulp/pulpcore/blob/main/pulpcore/app/serializers/domain.py#L174-L175) needs to be updated to "understand" these new fields when present
* medium-level urgency
* testing: How?
* do we need cloudfront actually involved?
* credentials etc?
* unit-test the serializer - we shouldn't be in the business of testing django-storages
* AI: [mdellweg] let's get this discussion into the issue
* Services willing to take on building this, **given the unit-test-only testing decision**
* Consideration: how hard is it to add Cloudfront support to an existing S3?
* under discussion
* AI: bmbouter wants to discuss COPR setup w/ Somebody On COPR, will report back

* where are we on stabilizing plugins for core/3.70?
* upgraded the bindings generator for 3.70, which added pydantic to the models
* [compatibility doc](https://hackmd.io/@pbrochad/H19BM1btkx)
* gem, python, maven, ostree done/released
* ansible needs work
* AI: [ggainey] will take a stab at this this week
* deb needs work
* There's a [PR](https://github.com/pulp/pulp_deb/pull/1232) to bump version, but no other work
* AI: [ggainey] to coord w/ ATIX on this work
* [rpm work](https://github.com/pulp/pulp_rpm/pull/3876) still in-progress (Pedro et al)
* [container](https://github.com/pulp/pulp_container/pulls?q=is%3Apr+is%3Aopen+remove+pulp-smash) in progress (Gerrod)
* why getting rid of pulp-smash?
* it breaks the client bindings
* npm in-progress
* plugin is out-of-date and needs work to get to supportable state
* documentation for our community **needs to be prioritized**
* see https://github.com/pulp/pulpcore/issues/6263
* would be good to have doc on how to build bindings "the old way"
* what were the effects on the Ruby bindings of this update?
* mdellweg talked to iballou/evgeni about self-gen bindings
* downstream has/will-have some of the same issues w/ bindings we do, over the course of maintenance
* we prob should de-prioritize "pushing the bindings" for talking to Pulp3
* use pulp-glue (python only)
* talk requests() directly
* something "like" glue for your own language
* Pulp4 timelines
* stakeholders are Very Interested
* "not before Q3" is our current messaging
* maybe align w/ 3.85? (unlikely)
* milestone-based approach
* all plugins to domains
* deb, container, npm, maven need to be done
* domain-enabled oci-images
* Pulp4 Milestone in GH w/ required activities
* don't forget that /v4/ APIs can/will/must show up in Pulp3!

## Feb 4, 2025
* Core 3.70 is out!
* All blockers (e.g. multiple FQDN support / CONTENT_ORIGIN) closed
* Plugin compatibility?
* None yet, ansible and RPM need to merge fixes, other plugins just need to bump the minimum bound (AFAWK)
* Services: update on investigation into [Task retry on worker exist RFE](https://github.com/pulp/pulpcore/issues/6222)
* Patched worker shutdown to be really long (hour) - that resolves our needs
* Issue closed

## January 28 2025
* Can we upgrade the Postgres version for Pulp 4? (Also the Python version?)
* gerrod: upstream comment on Postgres13 (single container, compose)
* dalley: pgres17 is most recent
* bmbouter: drivers
* broad compat (esp for downstream support)
* newer pgres can have significant new features
* ship vs test-against? (min vs single-container)
* dalley: downstream ships/uses pgres13
* let's ask downstream about upgrade plans?
* bmbouter: let's separate this from Pulp4
* bmbouter: can we build pgres13/pgres17 images? and test both?
* gerrod: more images is Not Great, given our constraints
* dalley: services?
* AWS pgres16 + extensions
* bmbouter: prob should stay w/ what downstream tests/ships against
* AI: ggainey to check w/ Sat on upgrade plans and bring back to this mtg
* from ehelms: "RHEL 9 currently has PG 13 as it's full-lifecycle version of postgres, the other versions require modularity which we are trying to avoid. We would like to handle any PG updates once we get to a containerized version to avoid modularity."
* gerrod: Next: Python version
* we test against 3.9, which is EOL "soon"
* which causes our third-party-libs to raise their LBs
* downstreams are on 3.11 (we think)
* when can we do this? how "breaking" is this?
* plugins need to line up "acceptable" versions
* install-from-source requires you to upgrade your python
* what if we plan for core/3.85?
* do we want to hold 3.70?
* ggainey: late in the cycle, katello would like to branch "soon"
* bmbouter: core/3.85 milestone including an "upgrade python to 3.11" blocker
* consensus: we want both of these, "soon"(ish) - but not blocking on 3.70, can be done before Pulp4
* [Task retry on worker exist RFE](https://github.com/pulp/pulpcore/issues/6222)
* services running into some issues
* discussion in the issue, please
* services to experiment, will come back to us later
* Discuss a plan for [capsule sync connection issue](https://github.com/pulp/pulpcore/issues/5439)
* Downstream really wants some answer here
* dalley: "somewhere in aiohttp" Things Go Awry
* *very* difficult to reproduce
* requires a very specific kind-of network failure
* needs more eyes/rubber-ducks on this
* consensus: downstream-team should get together on this
* ttereshc: ask for support/QE help on reproducing?
* [labels for domains RFE](https://github.com/pulp/pulpcore/issues/6236)
* would help a services use-case
* there is a current workaround
* would follow the model set by Repository/Remote/Distribution labelling
* ggainey: prob straightforward?
* CONTENT_ORIGIN discussion
* discussion and results in the PR
* HTTP_X_FORWARDED_HOST doesn't have what we expect/need (alas)
* HTTP_X_RH_EDGE_HOST *does*? (but is nonstandard)
* add new setting to tell pulp which header to look for?
* pulp_rpm - can we get access to global-request-object from content_handler()?
* even if we take this route - the header that we would like to use, is NOT standard, and we'll have to adapt to it not existing regardless
* we really need to make a decision here (one way or another)
* "most" users will not be affected
* for those who are - some degraded/missing functionality per plugin?
* OR, we can re-enable w/ some new settings (as noted above) - but still possibly unreliable
* NOTE : not all plugins are adversely affected
* pulp_rpm/config.repo is affected
* pulp_ansible/preauth-URLs is affected
* is there a workaround possible?
* consensus: this kind of sucks, but for 3.70, pursue "CONTENT_ORIGIN is null", possible solutions rely on non-standard headers
* AI: ggainey - let's get this on the PR
## January 21 2025
* go/nogo for everything on [3.70 blocker list](https://github.com/pulp/pulpcore/milestone/13)
* purge migrations - accept or no?
* are plugins ready?
* are we willing to Just Break Everything?
* consensus: let's remove from blocker list - it's not Required
* content-origin - even if it merges today, do we want to release immediately?
* Propose a new policy for adding dependencies:
* We can only pick up a dependency if it's packaged (and not deprecated) in fedora.
* outsource the decision about good and bad dependencies.
* outsource the work to "find the better alternative"
* relieve the pressure on the build team (assuming they never need to repackage those dependencies)
* discussion ensues
* reducing build-team-work is a Good Idea
* requiring only-fedora can be limiting
* Being Intentional about dependencies is a Really Good Idea
* transitive dependencies are Painful
* can/should we review current dependencies? do we need them all?
* discussion about orphaned-content-process
* a strict policy may not be a realistic expectation
* consensus: "be reluctant to add dependencies, but if you do, something already-packaged makes that call easier"
* discussion: optional dependencies
* we don't have mechanism in place to warn users about missing "optional" dependencies
* however - still a good idea to make things optional *when that makes sense* (e.g., otel deps)
* see kafka-decision-process
* would require docs-work/startup-checks to explain, to the user, what they need to do to get access to an "optional" feature
* Instead collaborating on one feature branch should be handled by special permissions on the (personal) fork (limited to that branch if possible) not the main repository.
* services has its own set of timing/requirements, and handles PRs differently as a result
* Do we want/need a generally-accepted "team norm" for not-services?
* How often does this come up?
* transferring work from one person to another is one thing, multiple people working together is a *different* workflow
* consensus:
* services' workflow *works*, and we're not touching it
* outside of services - this comes up infrequently enough that we'll deal with it if/when it happens
* Overarching Goal: Keep all the work/discussion for a given bug/feature **in one PR** if at all possible
* if not - start new PR w/ summary and pointer to previous/original
* content-origin discussion
* COPR needs it from us (among other things)
* consensus : def "needs to be in 3.70"
* how do we deal with plugins that need the full URL, not the relative path?
* ansible: redirect to content-app
* https://pulpproject.org/pulp_ansible/docs/admin/reference/settings/
* redirects get [signed](https://github.com/pulp/pulpcore/blob/main/pulpcore/app/models/publication.py#L429)
* would relative-path-redirects work?
* rpm: config.repo baseurl requires full URLs
* discussion
* are API/Content on the same host?
* are there multiple gateways by which one can access?
* if "deployed seperately" AND "multiple gateways" - then Things Will Break
* do we wait until we know that plugins aren't Hopelessly Broken by this?
* it "probably" have been a Better Idea to do everything using relative-URLs in the first place
* discussion around pulp-rpm's config.repo:baseurl problem
* discussion around gateways/cert-auth/VPN-only-access
* some gateways need certs, some need tokens
* discussion: should we return null for dist-base-url if content-origin not set
* don't set it to an empty string
* redirect-call is involved in [get_artifact](https://github.com/pulp/pulpcore/blob/main/pulpcore/app/util.py#L499)
* decision
* each plugin needs to do "whatever the plugin decides is Good"
* replication: added a new field
* rpm: can't have CO-null *and* as to auto-gen config.repo
* python: don't rely on the default if CO-null
* ansible: ummmmmm....
* let's get this PR accepted and merged and 3.70 released
* plugins will adapt as they need
* plugins can fail-immediately if they decide "I can't work in this environment"
* [NOT DISCUSSED YET] https://github.com/pulp/pulpcore/blob/main/pulpcore/app/util.py#L499 this function should probably add a `relative_path_ok=False` parameter to catch all the unknown assumtions in plugins using it.

## January 14 2025
* Random weekly cleanup question:
* Can we delete pulp-smash from [pypi](https://pypi.org/project/pulp-smash/)?
* was needed out there for "a while", but we do versionless/source-install now
* archive all the versions? or delete?
* we still use pulp-smash in "a few" places
* pulp_rpm, pulp_ansible
* delete or archive?
* consensus: delete
* upload empty package into the namespace after?
* AI: ggainey to delete
* AI: issues in pulp_rpm/pulp_ansible to finish the pulp-smash removal
* dkliban takes pulp_rpm
* https://github.com/pulp/pulp_rpm/issues/3855
* ggainey to investigate/file against others
* Should this be archived?
* https://github.com/pulp/pulpproject.org
* discussion ensues
* pmbrochado: had/has plans to use it for common docs
* pulp-docs was/is intended to be "just a tool", not the content
* AI: archive, it can always be undone if we want to
* introductions :)
* go/nogo for everything on [3.70 blocker list](https://github.com/pulp/pulpcore/milestone/13)
* still waiting on 2
* consensus: wait on these to release 3.70
* Propose a new policy for adding dependencies:
* We can only pick up a dependency if it's packaged (and not deprecated) in fedora.
* outsource the decision about good and bad dependencies.
* outsource the work to "find the better alternative"
* relieve the pressure on the build team (assuming they never need to repackage those dependencies)
* Think about format for this mtg/release-mtg-lead rotations for next time
* If you have Strong Opinions - bring to mtg!
* dkliban: finds this mtg/format Very Useful
* dalley: this is the only (mostly) team-wide technical mtg we have
* dkliban: this is The Place to do teamwide brainstorming
* consensus: this is def a well-spent hour!
* mtg-lead/release-lead changes?
* consensus: no changes needed
* ~~adding hyagi to [core team](https://github.com/orgs/pulp/teams/core)~~
* NOTE: done, but insufficient - also made him an "Owner" of the org (last person who wasn't that)
* we had to close PR unecessarily because hyagi coudn't push to dkliban's PR
* ggainey volunteers
* how about...everybody?
* this is actually separate from the "taking over someone else's branch"
* This is the wrong reason to do the right thing.
* Instead collaborating on one feature branch should be handled by special permissions on the (personal) fork (limited to that branch if possible) not the main repository.
* services has its own set of timing/requirements, and handles PRs differently as a result
* ggainey AI: archive 2024 notes

## January 7 2025
* new RFE for services https://github.com/pulp/pulpcore/issues/6154
* we did it in services [here](https://github.com/pulp/pulp-service/pull/371/files)
* already tested/deployed and in use
* how should we proceed with an upstream contribution?
* Is there consensus on "just do it"
* ggainey/'mdellweg' will be assigned to review
* How will this work on domain-disabled systems?
* Does this endpoint even *exist* on domain-disabled?
* Let's have dev-discussion on the PR when opened, not here
* multi-gateway PR is ready [see this PR](https://github.com/pulp/pulpcore/pull/6175)
* audit usage of the `CONTENT_ORIGIN` [like this](https://github.com/search?q=org%3Apulp+CONTENT_ORIGIN&type=code)
* REMINDER: this is a 3.70 plugin-breaking change
* plugins that "assume" CONTENT_ORIGIN is *always set*, will fail if it's not-set
* ansible, container, maven, python are prob affected, may be others - LOOK CAREFULLY
* plugins will need a "CONTENT_ORIGIN is not set" test added
* mdellweg to add "can we have a "it's not set" test added, to the PR
* work w/ hyagi on details
* plugin teams are/will be respoinsible for addressing this change - NOT the services team - in the plugins

* core/3.70 - are we at go/no-go?
* django deprecation status (pbrochad):
* https://github.com/pulp/pulpcore/pull/6058
* Problem: users can't update their deployment settings before the removal release
* Approach: hack to allow settings update between $[3.70,3.85)$ and schedule removal to 3.85.
* AI: apply fixes for hack side-effects on plugins
* ready to be reviewed
* discussion:
* plugins would like to be able to "cross the boundary" - ie be able to run on <3.70 (so know old-way) *and* on 3.70+ 9and therefore know the new-way as well
* plugins MUST adapt to the change to be 3.70-compatible
* can pedro organize
* hyagi: what about oci_env and pulp-operator impacts?
* hyagi volunteers for operator
* oci-env needs eyes *before* 3.85 releases
* sooner is better
* we need to socialize the potential work that plugins need to do
* CONTENT_ORIGIN
* django STORAGES change
* ruby bindings bump is almost there: https://github.com/pulp/pulp-openapi-generator/pull/108
* not being tested in CI because we don't use nightly
* being tested locally
* comes back to "we would really like to not publish bindings"
* python bindings updated by LOTS of changes
* it is *likely* that plugin-tests *are going to break*
* see [6138](https://github.com/pulp/pulpcore/pull/6138)
* [blocker milestone](https://github.com/pulp/pulpcore/milestone/13)
* clearly no release today
* backport migration (field add) and patch alternative (pbrochad)
* backporting migrations is...a problem
* fixing the "missing remote artifact problem" PR
* adding hyagi to [core team](https://github.com/orgs/pulp/teams/core)
* we had to close PR unecessarily because hyagi coudn't push to dkliban's PR
* ggainey volunteers
* how about...everybody?
* this is actually separate from the "taking over someone else's branch"
* Think about format for this mtg/release-mtg-lead rotations for next time
* If you have Strong Opinions - bring to mtg!

___

# Archives
* [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`