1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
[[!meta title="Iteration planning: October"]]
[[!meta date="Mon, 03 Oct 2022 16:23:42 +0300"]]
[[!tag meeting]]
[[!toc levels=1]]
# Assessment of the iteration that has ended
[previous iteration]: /blog/2022/06/12
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).
The following issues were chosen for this iteration:
* [[!issue 206]] -- _Lacks a release with recent changes_
- done
* [[!issue 207]] -- _What threats would a server API authentication
defend against?_
- done
* [[!issue 208]] -- _Needs internal interface for using chunk storage_
- not done
- Lars ran into a problem he couldn't solve
- Alexander suggested a solution
- Lars was busy with work and life and dropped the ball on Obnam and
hasn't really done anything in recent months
# Discussion
## Restarting Obnam development
Lars wants to pick up the ball on Obnam again, and feels that the best
way to do that is to start actually using it and relying on it. For
this, Lars needs:
* reasonable performance: a full backup of his main computer overnight
- about 250 GiB
- about 3 million files
* sufficient security that he dares run a server on the public
Internet
- server API needs to be authenticated
Given realities of life, Lars doesn't expect to be spending large
amounts of time on Obnam. However, he hopes to spend at least few
hours a month. To reflect this, he expects to do Obnam planning
meetings monthly rather than biweekly, and pick at most eight hours of
work for each iteration.
# 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](https://gitlab.com/obnam/container-images)
* Open issues: 1
* Merge requests: 0
* Additional branches: 0
* CI: OK, ran today
## [obnam.org](https://gitlab.com/obnam/obnam.org)
* Open issues: 0
* Merge requests: 0
* Additional branches: 0
* CI: not defined
## [obnam-benchmark](https://gitlab.com/obnam/obnam-benchmark)
* Open issues: 11
* Merge requests: 0
* Additional branches: 0
* CI: not defined
## [cachedir](https://gitlab.com/obnam/cachedir)
* Open issues: 0
* Merge requests: 0
* Additional branches: 0
* CI: not defined
## [summain](https://gitlab.com/obnam/summain)
* Open issues: 0
* Merge requests: 0
* Additional branches: 0
* CI: not defined
## [obnam](https://gitlab.com/obnam/obnam)
* Open issues: 51
* Merge requests: 1
* Additional branches: 2
- one for the MR
- one for chunk store internal interface
* CI: failed, because of Rust version problems with MR
# 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 restart Obnam development.
# Commitments for this iteration
Lars intends to work on the following issues:
* [[!issue 208]] -- _Needs internal interface for using chunk storage_
- Lars to add an internal interface and implement it for a remote
chunk store
- most of the work is hopefully done, but Lars need to solve the
issue he ran into based on Alexander's suggestion, or some other
way, or else determine that it can't be solved with reasonable
effort
- estimate: 4h
* [[!issue 209]] -- _Uses structopt instead of clap v3 for command
line parsing_
- work on this has started, but ran into a problem where the
container used by CI has such an old version of Rust that it can't
handle `clap` v4
- Lars hopes to target either latest stable Rust (which moves every
six weeks), or whatever is in Debian testing (currently 1.60), and
to change the container to provide one of those
- estimate: 4h
# Meeting participants
* Lars Wirzenius
|
