9:42 a.m.
Am 02.08.2022 um 22:16 schrieb Adam Williamson
<adamwill(a)fedoraproject.org>:
….
* Maximum image sizes are canonically defined in the "release blocking"
page - https://docs.fedoraproject.org/en-US/releases/f36/blocking/ .
Our sizes are already there. They shouldn't be duplicated in the tech
spec. I know the current tech spec lists one, but that was a different
situation at the time.
Agreed, we agreed to omit the sizes, but I missed to adjust the text.
* "Package selection will be supplementary. There will be no option in
the installer to install less than the Fedora Server Edition standard
installation." This text from the original hasn't aged well; it's no
longer actually true and has not been for a while. We should probably
revise it.
That sentence was one of the questions I had. It it is not essential for reasons that go
back years and that no one knows about us "newbies" we should leave it out.
* "Special Case CoreOS VM
Fedora CoreOS KVM VM image must be installable in a KVM virtual
machine." - I'm unclear on this. What does it mean? What image? Why is
it in the Server tech spec?
One idea is to emphasize that we don't have 3 completely different server editions
that all • coincidentally happen to have Fedora in the name, but we are Fedora and in
combination with each other we offer additional benefits.
De facto, this results in the requirement to test.
"...installable and usable right out of the box"
requirements: these
three (podman, systemd-nspawn and libvirt lxc) don't really seem in
line with the rest of the spec. They're not *phrased* like things in a
tech spec - a tech spec is meant to say "the product will use system X
to provide capability Y". These are written more like vague release
criteria. The *capability* provided by each of these things isn't
explained, nor are there any details on quite what is meant by "usable
right out of the box".
Yes, we agreed last meeting to leave it that way in this version, as a realisation of the
requirement in PRD to offer choice options between different technologies. We will
elaborate on it in the next version, such as conceptual differences, different workflow,
different ways of operating, etc.
This is also a question of available resources and time restrictions.
The entire Server Roles section seems awkward as it's a bit hard
to
write a faux-'tech spec' for something we haven't designed or developed
yet. We did sort of do this with the original too, but at that time the
plans for the original 'role' implementation were quite detailed and,
if you look at the original tech spec, the specifications were quite
precise and 'useful'. This new version doesn't really provide much
precise, usable meat. If we want to revise the tech spec before we
really have any concrete idea what Roles 2.0 is really going to look
like, I would suggest just leaving the section out entirely for now.
We can’t leave it completely out. At least we have to specify the services Fedora Server
will support. At the moment it is just Postgresql and IPA. That's really a bit poor.
So, at least we need a section 4 „Supported Services“ that enumerates the current 4.3.1 -
4.3.6
And maybe a section 5 that specifies the planning for server roles.
On the other hand it clearly specifies a future plan and the requirements and tools. And
given the long time we have already been discussing, I do not think such major changes are
opportune now. Even as the text is worded now, it is an improvement over the 2014 version
and better describes what Fedora Server Edition currently is.
Instead, we should schedule another discussion for the end of the year / beginning of next
year for improvement. We currently have 20 open tickets and any number of urgent tasks
that we need to address now.
For this, we need a technical specification that describes the framework, even if not yet
in all desirable details. For example, before we discuss systematizing our tests, we need
to agree on what to test. The same applies to the development of Ansible scripts. We need
to agree beforehand what we want to develop them for and what they should do. And if we
want to evaluate our installation media, we need to agree on the intended functionality
beforehand.
We have a gap that has lasted for years, and it cannot be filled optimally in one go.