[missed posting some minutes, catching up here]
May 2nd
- Weekly release check-in
- pulpcore
- [X] 3.24
- [X] 3.23
- [ ] 3.22
- [ ] 3.21
- [ ] 3.18
- [ ] 3.16
- pulp_file
- core/3.24
- Let’s nail down what cadence we will use as “number of Y-releases without breaking changes”
- see previous notes Pulpcore team meeting - HackMD
- suggestion: core/3.40 (15 versions post-3.25)
- “probably” six-months-ish
- see how well this works/revisit at that point
- With the new release policy, is it still useful to have tests for new pulpcore features living in pulp_file only?
- In the long run, it does not matter if the tests are in pulpcore or pulp_file.
- “Test should come with the feature” suggests adding them to pulpcore if it’s a pulpcore only change.
- What was the original reason to move tests using pulp_file to the plugin?
- mdellweg’s memory: We had compatibility issues with all the branches moving around. But we fixed that and can now depend on stable pulp_file releases.
- if there is any code-change in pulp_file for a Thing, then its test needs to live in pulp_file
- if there is no pulp_file code-change (e.g., core is adding a Thing that pulp_file gets “for free” due to inheritance), then the test for it “can” live in pulpcore
- this own’t solve the problem - pulp_file changes that require core-changes still collide oddly/badly
- what about fixtures? can you use pulp_file fixtures from inside pulpcore?
- yes if pulp_file is a pytest plugin
- discussion: should core and file be the same project?
May 9
- pulpcore
- [X] 3.25 (NEW)
- [ ] 3.24
- [X] 3.23
- [ ] 3.22
- [ ] 3.21
- [ ] 3.18
- [ ] 3.16
- pulp_file
- [ ] 1.15 (NEW)
- [ ] 1.14
- [ ] 1.13
- [ ] 1.12
- [ ] 1.11
- [ ] 1.10
- Issue discussion
- https://github.com/pulp/pulp_rpm/issues/3134
- add a repo-versions__in
- how can we make this performant?
- filters could use perf-analysis/fixes
- needs a POC to understand implications
- materialized views? (django? or postgres?)
- A proposal from telemetry workgroup
- current state
- Dependencies declared in the pulp-ci-centos build
- Code missing in the pulpcore’s
main branch. We can’t merge the code if we don’t add the opentelemetry basic stack as a direct dependency on pulpcore's requirements.
- A new PR for OpenTelemetry aiohttp-server instrumentation project.
- needed for pulp-content instrumentation
- pulp-api is in a great spot
- aiohttp is pretty good, but we really want it released upstream to consume
- nothing for tasking yet - phase-2 perhaps?
- Got a oci-env profile for development purposes.
- Still not merged given some instabilities with CI’s docker tests.
- The new proposal
- Given the new
pulpcore release process
- “We can undo it later if needed”
- Phase 1
- We want to add a trimmed opentelemetry stack list of dependencies directly into pulpcore.
- opentelemetry-distro[otlp]>=0.38b0,<=0.38b0
- opentelemetry-exporter-otlp-proto-http>=1.17.0,<=1.17.0
- opentelemetry-instrumentation-django>=0.38b0,<=0.38b0
- opentelemetry-instrumentation-wsgi>=0.38b0,<=0.38b0
- We have a PR open for instrumenting pulp-api
- We are about to open a PR for opentelemetry-instrumentation-aiohttp-server
- Will have a PR for instrumenting pulp-content after getting the otel PR merged
- We can release a package with the instrumentator if the PR got stalled for some reason(ex: got no reviewers)
- Or we can add it directly into pulpcore code base(vendor it?)
- Phase 2
- instrument the workers?
- Any specific pulp related code?
- discussion
- we need to get initial work out for larger use #soon
- what’s the cost to add dependencies?
- “more dependencies”
- performance-overhead even if not using?
- decision:
- merge reqs/PR to pulpcore
- merge otel-work in oci_env
- release as soon as it’s merged (3.25? .26?)
- difficulty in getting core-PRs reviewed
- think about this for next week’s mtg
- 3.25 Today?
- Can we make a bot or something to tell us when there are un-released commits on our branches
- this would be great!
- maybe a cmd to be run on a local copy of the repo?
- a tues-workflow to check branches and auto-release?
- let’s gather some info and anyone who’s Very Excited about this can start pulling something together
- discussion around drop-trailing-slash PR
- gerrod’s refactoring would make this easier to implement
- do we hold up 3.25 for this, or not
- if we’re going to change this to opt-in, it can happen “whenever”
- decision: remove from blocker-list, release core/3.25
