Obnam → blog → 2022 → 06 → Iteration planning: June 12 – 26
  1. Assessment of the iteration that has ended
  2. Discussion
    1. Current development theme
  3. Repository review
    1. Container Images
    2. obnam.org
    3. obnam-benchmark
    4. cachedir
    5. summain
    6. obnam
  4. Goals
    1. Goal for 1.0 (not changed this iteration)
    2. Goal for the next few iterations (not changed for this iteration)
    3. Goal for this iteration (new for this iteration)
  5. Commitments for this iteration
  6. Meeting participants

Assessment of the iteration that has ended

The goal of the previous iteration was:

The goal of this iteration is to prepare for future changes: document threats against the chunk server API (so that authentication can be added in the future), and making an client-internal abstraction for using the chunk store (so that it can later be local as well as remote).

This hasn't been achieved. Due to life and work events, Lars has been unable to allocate enough time for Obnam. The tasks from the previous meeting are carried over. The main purpose of this meeting is to have meeting and update anyone who cares of what has (or hasn't) been happening.

Discussion

Current development theme

The current theme of development for Obnam is convenience. The choices are performance, security, convenience, and tidy-up, at least currently.

Repository review

Lars reviewed all the open issues, merge requests, and CI pipelines for all the projects in the Obnam group on gitlab.com.

Container Images

  • Open issues: 0
  • Merge requests: 0
  • Additional branches: 0
  • CI: OK, ran on Monday, June 6

obnam.org

  • Open issues: 0
  • Merge requests: 0
  • Additional branches: 0
  • CI: not defined

obnam-benchmark

  • Open issues: 11
  • Merge requests: 0
  • Additional branches: 0
  • CI: not defined

cachedir

  • Open issues: 0
  • Merge requests: 0
  • Additional branches: 0
  • CI: not defined

summain

  • Open issues: 0
  • Merge requests: 0
  • Additional branches: 0
  • CI: not defined

obnam

  • Open issues: 53
  • Merge requests: 0
  • Additional branches: 0
  • CI: OK

Goals

Goal for 1.0 (not changed this iteration)

The goal for version 1.0 is for Obnam to be an utterly boring backup solution for Linux command line users. It should just work, be performant, secure, and well-documented.

It is not a goal for version 1.0 to have been ported to other operating systems, but if there are volunteers to do that, and to commit to supporting their port, ports will be welcome.

Other user interfaces is likely to happen only after 1.0.

The server component will support multiple clients in a way that doesn’t let them see each other’s data. It is not a goal for clients to be able to share data, even if the clients trust each other.

Goal for the next few iterations (not changed for this iteration)

The goal for next few iterations is to have Obnam be easier and safer to change, both for developers and end users. This means that developers need to be able to make breaking changes without users having to suffer. User shall be able to migrate their data, when they feel it worthwhile, not just because there is a new version.

Goal for this iteration (new for this iteration)

The goal of this iteration is to prepare for future changes: document threats against the chunk server API (so that authentication can be added in the future), and making an client-internal abstraction for using the chunk store (so that it can later be local as well as remote).

Commitments for this iteration

Lars intends to work on the following issues:

  • obnam#206 -- Lacks a release with recent changes
    • Lars will make a release and run benchmarks.
    • This can happen now, or after obnam#208 is resolved.
    • 1h
  • obnam#207 -- What threats would a server API authentication defend against?
    • Lars to add an initial threat model for server API. This needs to be done before it's sensible to discuss how authentication would be implemented.
    • 1h
  • obnam#208 -- Needs internal interface for using chunk storage
    • Lars to add an internal interface and implement it for a remote chunk store.
    • 4h

Meeting participants

  • Lars Wirzenius