-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/12/2013 11:32 AM, "Jóhann B. Guðmundsson" wrote:
Few notes about FedoraOS Server Platform ( FOSSP )
Which touches serveral topics we have been discussing.
JBG
1.
https://fedoraproject.org/wiki/User:Johannbg/FOSSP
I had a long discussion today with Jóhann and I think I took away from
it a somewhat better understanding of what it is that he is proposing.
We both agreed that his intentions were less than clear due to
communication issues (as opposed to necessarily differing opinions).
I'm going to attempt to rephrase and summarize that discussion in the
hope that we can continue this conversation with everyone on the same
page (Jóhann, please correct me if I misrepresent anything). I'm
responding to the original email here because I'm not aiming to reply
to any particular part of the thread other than to re-summarize the
initial proposal. Also, this will touch on a couple topics from the
other threads, but I don't want to split this discussion too much.
I'll add a few of my own thoughts at the bottom.
== Role Assignments ==
So, after discussing this, I think the general idea is that we agree
that assigning roles should be handled by some sort of API whose exact
implementation is defined later. It must be consumable by a remote
interface and the installer.
The major disconnect here was that it appeared that Jóhann was arguing
against supporting multiple roles on the same system. That was not
strictly the case; he is arguing that the roles should not be
installed without isolation on a single system. After some
conversation on the point, I believe that he and I agreed that it was
probably sufficient at this stage of planning to define an API that
must be capable of installing more than one role on a system. In the
short term, we can stick with our previously-agreed plan of only
vetting and promising one role at a time, while not strictly
preventing multiple roles. We agreed that as isolation technologies
such as containers mature, we should plan for this role assignment to
act as an abstraction layer so that we can just flip the switch when
the day comes that the containers are ready for true service
isolation. This should be essentially transparent to administrators.
== Personas ==
There was some confusion as to the value of defining "personas" in the
discussion. This was primarily due to, I think, a few insufficient
examples that were used in the meetings. Jóhann was under the
impression that we were trying to define "Junior Admin" and "Senior
Admin" (nebulous terms) as personas. I explained that a better example
of a "Junior Admin" persona would instead be "A person who wants to
administer a PostgreSQL database using a graphical or web-based UI
tool". With that more concrete example, it became a little more clear
what a "persona" really is.
The second disconnect there was that he felt that personas were
therefore more applicable to the roles themselves as opposed to the
greater Fedora Server effort. I conceded that the examples we had been
throwing about would generally make sense there, but also pointed out
that we had not yet clearly and explicitly described some of the
general personas as well. I cited "A developer or experienced
administrator who wants to promote a service to the level of featured
role in the Fedora Server" as such a persona that should apply to the
Fedora Server effort. I believe we concluded this portion of the
discussion agreeing that it made sense to try to define such personas
first and then categorize them as applicable to Fedora Server vs. Role.
== FOS, FOSSP and Roles ==
One place where we very clearly had some confusing terminology is in
terms of the three layers that Jóhann is proposing in this thread.
Part of the confusion comes from the classic ambiguity between "core"
and "base" that we have in Fedora today. For the non-native English
speakers reading this, these two words are basically synonyms, but in
the context of Fedora, "core" has generally meant the "minimal"
install of Fedora and "base" something like the standard headless install.
Jóhann then added new terms, FOS (Fedora OS) and FOSSP (Fedora OS
Server Platform) and proceeded to use the terms interchangably with
"core" and "base", respectively. It had been unclear to me prior to
our conversation today that FOSSP == "base for the Fedora Server".
So to first clarify those three layers as Jóhann defines them:
FOS: Analagous to "core" from traditional Fedora. Should essentially
contain the absolute minimal set of functionality necessary to install
the bits, get a shell and install software on a running machine. This
is what he expects as output from the Base WG.
FOSSP: Analagous to "base" from traditional Fedora. This should be the
platform delivered by the Fedora Server. It should provide all of the
foundational pieces necessary to support the deployment of the
supported roles.
FOSSP Roles: Individual services installable by API as described
above, ideally isolated on the target system.
== Release Cycles ==
Jóhann also posits some changes to release cycle for the FOS and FOSSP
layers. They would not deliver on precisely the same cycle but would
do so on a common cadence.
Specifically, the idea would be for FOS to tie its releases to the
Linux Kernel upstream release schedule, wherein it would make a stable
release approximately four times a year.[1]
We would then tie the preview/development release of FOSSP to the
upstream kernel release schedule as well. We could continue to have
Preview releases as with my lifecycle proposal on a regular basis and
then tie the stable, LTM Fedora Server N.0 to the LTS kernel releases,
approximately every two years. This is an interesting idea and would
serve to address some of the classic Fedora Kernel issues
necessitating rebases in stable Fedoras[2]. This idea isn't without
merit, but as I mentioned, I'm not certain about the fast cycle on the
FOS. We might be able to get away with half as many FOS and FOSSP
preview releases by only tying ourselves to alternating kernel
releases or something like that. This is worth discussing further, I'd
say.
It's important to note that, like my lifecycle proposal in the other
thread, this release schedule plan involves having one "rolling" or
"preview" branch and exactly one stable/maintained branch of the
Fedora server at any time (with some limited overlap for migration).
This would generally serve to actually reduce the amount of ongoing
maintenance (as compared to right now where I'm doing security
releases for F18, F19, F20 and Rawhide all at once).
As long as the mechanism for deploying and configuring roles is
standardized on the FOSSP, it may be that individual roles do not need
to be tied to the FOSSP release cycle at all. I am not certain that I
agree with this yet; I think there is value from a marketing and
testing perspective to have the set of roles established at each
release of the stable branch of FOSSP at least.
== Installer ==
Jóhann is also concerned about the level of control in the installer
and the potential overlap between Anaconda, gnome-initial-setup (in
the Workstation case) and whatever we're calling firstboot these days.
He also feels uncertain that Anaconda is sufficiently modular to
remove things that aren't necessary for a particular project. The
example he gave was iSCSI support for Workstation, but I assume he
also feels there are features not needed for the Server. I think we
both agree that the modular spokes at least allow us room to grow our
own new requirements.[3]
Jóhann also raised concerns that Anaconda is the source of the
majority of release-verification failures in current Fedora and that
he hopes that the Base WG and Anaconda team can work out a mechanism
to avoid breakage (or automate detection of it) so his proposal of
more frequent releases could be realized.
== Role Process ==
Jóhann does not like the term PRD and feels that the term as
defined[4] doesn't really make sense for a community project.
Moreover, he feels it doesn't make sense when applied to the role
projects. He envisions that each role we harden and tie into our
deployment API should be developed as a project of its own, following
a different (non-PRD-driven) process. He suggested that Stage-Gate[5]
might be a useful approach for this.
We discussed that in terms of the January deliverable, it is probably
okay for us to set a roadmap for what we want to accomplish, rather
than attempting to set down all future processes for sub-tasks at this
time. That will not stop Jóhann from preparing early.
== Final Thoughts ==
Yikes, this email is much longer than I expected it to be. If you're
still reading at this point, I commend you.
[1] This is the first point that I think would need serious
evaluation. Jóhann claims that this would not introduce more work for
QA, particularly if we kept the FOS surface extremely small. I'm not
convinced that this would be achievable for the Anaconda people
(although it would encourage more of a release early, release often
environment). I'd also like to hear an assertion from the general
Fedora QA community whether they feel this is achievable. Jóhann,
would you mind raising this discussion at the next Fedora QA meeting?
[2]
http://fedoraproject.org/wiki/KernelRebases
[3] Jóhann, this is the section I'm not as certain we came to an
agreement on, so I may not be recording this accurately.
[4]
http://en.wikipedia.org/wiki/Product_requirements_document
[5]
http://www.prod-dev.com/stage-gate.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlKKvREACgkQeiVVYja6o6NiZQCffwTN5bimtxmuS6/k112nhvLZ
P/MAniLDZ2AIwf3E3eMjxSQRerPQ2RSF
=AtYq
-----END PGP SIGNATURE-----