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

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

* 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
* ggainey: "How do you use RBAC?" discourse post
* https://discourse.pulpproject.org/t/gathering-information-how-do-you-use-pulps-rbac/1974

## Upcoming
* May 6th - Discuss RBAC - Bring notes from customers/stakeholders

## 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`