Add this week’s updates here.
- Drafted, revised, and posted Writing Integration Tests for Charmed Operators
- Posted an Integration Testing Cookbook, with just a few examples to start. Contributions welcome!
- Presented a post-mortem on lib Rolling Ops to the Operator Framework team.
- Revised the above in prep for the Product Sprint.
- Followed-up on a discussion ,and verified that peer relations have their own application data bag.
- Reviewed, discussed, approved and merged “Proposal for harness add_layer merge support”. (Thx for the contribution, @alesstimec!)
- Wrote and posted Story: a new charm author tries to run charm tests for the first time.
- Grumped about some gotchas in handling relation data early in a charm’s lifecycle.
- Prepped for Product Sprint.
- Participated in MongoDB knowledge sharing session.
- more polish on the harness storage PR. It should be ready for some wider review.
- Started working on blank remote app bug.
- Fought with and discovered juju<–>lxd and juju<–>microk8s issues - came up with workarounds.
- Wrote and posted some improved storage sdk doc content (added the last couple sections on the page).
- Discussed and/or brainstormed about:
- Pietro’s hook/charm branching ideas. Maybe we focus on addressing is_leader and can_connect bifurcation for now?
- Harness event tracking spec
- Roadmap ideas for the next several months.
- integration testing and pytest-operator. Should pytest-operator (or something like it) ever become part of the framework?
- type checking (e.g. mypy, pydantic) for ops framework
- Prototyped a relation data interface for library code (and charms?), started working on a spec to discuss it with the team.
- Merged the traefik-route endpoint pr for traefik-k8s
- Got contributorship of traefik-k8s and published two version bumps for ingress-per-unit
- Finished up integration testing PR for traefik-k8s, now in review.
- Spent some time designing a further simplification of the ingress-per-unit interface, involving a simplification from the ready/broken/available statuses to an event-based model (provide/revoke/wipe), still debating with myself if we really need