Thoughts on Fedora Server lifecycle
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Related to my earlier mail "Server Admins: Why not Fedora?", I wanted
to specifically discuss some lifecycle ideas. Every few months, people
start shouting again for a "Fedora LTS" and people generally respond
with "we couldn't support that with volunteers" or "go use
RHEL/CentOS/SL".
Suppose for a moment that we did things a little differently in the
Fedora Server. We don't want to get out of sync with the release cycle
set by the Base Design WG, certainly. But at the same time, I think we
can come up with a fairly simple way to maintain the Fedora Server for
a longer time period.
I'm going to propose a lifecycle of eighteen months (with slight
extensions for slippage) as follows.
Let's start talking about Fedora Server 1.0 (rather than Fedora Server
21).
In my view of the world, we would build the Base Design as Fedora 21,
Fedora 22 and Fedora 23 following mechanisms not terribly dissimilar
to the present-day model. We would then create the Fedora Server atop
this, delayed by a small amount < 1 month).
We would use the latest Fedora Base bits as the platform and sync our
pieces atop it at regular intervals, aiming for a finalized release
every eighteen months.
I spent the last hour trying to draw up a decent timeline graphic, but
I am terrible at this and so I will instead attempt to explain it in
text. Please bear with me.
Let's start the discussion from Fedora 21. We would follow the Fedora
21 process closely until the base design is declared final (much as
current Fedora is now). Ideally at the same time (but possibly delayed
by up to a month), we would release "Fedora Server 1.0 Preview 1".
This would be a complete, installable server operating system, but
make it clear that it's a preview release that may not represent the
final product.
At Fedora 22, we release "Fedora Server 1.0 Preview 2", with the same
caveats. However, at Fedora 23, we release "Fedora Server 1.0". At
this time, we agree to freeze the interfaces and make clear demands on
backwards-compatibility. For the remaining life of Fedora Server 1.x,
it will be a stable platform (and understood to be extremely
conservative with its updates).
At Fedora 24, we now release two things: "Fedora Server 1.1", which
will just be an updated installer with the latest versions of any
package updates that have occurred in the standard install since
Fedora Server 1.0". We will also release "Fedora Server 2.0 Preview
1", following the same guidelines as above.
Fedora 25 would offer the "Fedora Server 1.2" updates roll-up and
"Fedora Server 2.0 Preview 2", and finally Fedora 26 would offer only
"Fedora Server 2.0" as install media. At this time, Fedora Server 1.0
would become "security-fixes only" for the six months until Fedora
Server 2.1 (to allow overlap to upgrade). As of Fedora Server N.1 of
any release, the N-1 series is abandoned.
So yes, that sounds ambitious, but what do you think of the idea?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJz804ACgkQeiVVYja6o6P6KACgmbiOeJ9yE9WLQ5Phb9G9lvcV
deQAoKAfmY9pp805MUQef26QObv71/FT
=H7Dc
-----END PGP SIGNATURE-----
10 years, 4 months
updates and testing instead of lifecycle
by Kevin Fenzi
So, instead of trying to tweak the life cycle, how about another
alternate approach:
Short term/f21:
- For those 'featured stacks' that we are going to integrate and test,
and all there deps, we setup some new group for Bodhi
("server-critical-path").
- We setup new rules/critera/test plans for when updates are allowed to
go stable that are in this group. (open to ideas on what this would
be exactly, I suspect we would want to rope in maintainers of those
components) This would allow folks to know that if they install the
release version and apply updates everything will continue to work.
- Look at default partitioning/setup that will let us use lvm thinp and yum
pre/post transaction snapshots for extra paranoia. This may require
us to decide that say /srv is where most user data is by default.
- Work to improve fedup support for server use cases (remote machine,
etc) and make sure Fn->Fn+1 for server case is heavily tested and
rollbacks are supported. (This may well need additional developer
time)
- Create comps groups for each 'featured stack' of things, so they can
be selected at install time or installed later. Ideally we would test
all of these, but since any combo of them could be installed at once,
we may have to pick and choose. Possibly "each feature by itself" and
"all features at once" would be easy cases to start with.
Longer term:
- Add some logic to bodhi (or wherever) that would note updates that
require a 'restart' in addition to a 'reboot'. Or setup some way to
notify admins things that need restart. (email to root from
needs-restarting?)
- Perhaps make a server specific 'initial setup' that sets some server
specific things instead of making a local user. (root email alias,
logs retention, etc.
- Improve server docs a lot. Possibly include a best practices doc.
Especially note new features like cgroups, journald, etc.
- Grow out more featured applications.
- Decide on and work on integration of our applications with base
stuff like auth backend, database, CM, monitoring, backup solution,
log monitoring, intrusion detection, and probibly a bunch of other
things.
- Look at all the container solutions (possibly this is with other
working groups) and see if any of them should be 'featured' and made
well integrated. Possibly someday the containers take over for the
normally installed versions of applications.
Thoughts?
kevin
10 years, 4 months
Server Admins: Why not Fedora?
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One of the oft-repeated statements about Fedora is that it's "not good
for running a server". Clearly, as we embark upon a mission to change
that fundamental belief, we need to start addressing the problems that
make Fedora unsuitable to so many people.
I propose that a good place to start here is to carefully enumerate
the reasons people elect not to use Fedora in their server
environments. Let's start by gathering the surface problems (in some
cases, the cargo-cult explanations) and look into what is the real
underlying problem and how we can fix it with the Fedora Server offering.
To get us started:
* Fedora moves too quickly!
Historically, Fedora's policy has always been to be among thefirst
to ship new technology (whether or not it's ready, but that's another
discussion). The problem with tracking rapidly-moving upstreams is
that they are not all created equally. Some upstreams (e.g. glibc)
obsessively avoid backwards-compatible changes between versions.
These are the upstreams that Fedora's current approach works well
for. These tend to be the low-level features of the operating system
that understand that compatibility == relevance. No one will build
atop these systems if they don't have a guarantee that it will
continue to work. Other upstreams (e.g. much of the Ruby and Java
community) tend to focus more on constant innovation without
consideration of backporting. This allows them to make bigger changes
much faster, but at the cost of constant churn and difficulty to
distribution packaging. These are the systems that normally expect
consuming applications to just bundle the exact version of the
library known to work. This is where we get into the "Fedora moves
too quickly" area of things. Whatever we're shipping in the standard
location on-disk tends to be preferred by the applications, and if it
isn't the same version that upstream wanted to bundle, all bets are
off.
* Fedora moves too slowly!
This seems like the inverse of the above, but this is what happens
when certain packages are intentionally kept on an older version in
order to maintain compatibilitity with some high-value application in
Fedora. A classic example of this is 'v8'. The v8 version in Fedora
is maintained to match what Node.js upstream supports, even though it
is rather old and lacking many of the new features. Unfortuntately,
if Fedora pulled in the newer version, it would break hundreds of
other packages. This causes issues with people who are trying to
build software (such as Chromium) that depends on the latest version.
* Fedora has too short of a lifecycle!
This is a very common one. The idea here is that administrators who
are deploying a server to provide functionality to their
infrastructure or critical apps to their users don't like to change
the underlying operating system very often. With Fedora, they need to
upgrade every thirteen months (and more often if they want to avoid
issues that may crop up while going from version N to N+1 and then
N+2 all at once). In many environments, the amount of compatibility
and functional testing that would be needed to move their
infrastructure exceeds what they could hope to accomplish on such a
frequent upgrade cycle.
I'm sure there are other reasons and I'd like to hear them. Also, for
those of you who *do* use Fedora in production, I'd like to hear the
reasons why you chose to do so. What did Fedora gain you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJz26kACgkQeiVVYja6o6PjoACfehQ4A/1OnKMpSTpCgAESPirO
HOYAn2umcZLfQlY4MY+832noJIF28Hv6
=zfYV
-----END PGP SIGNATURE-----
10 years, 4 months
Server Working Group Blog
by Máirín Duffy
Hi folks,
I set up a blog for the Server Working Group. It is located here:
http://fedoraserver-wgblog.rhcloud.com/
I set up OpenID auth, so if you'd like to create an account on it,
anyone is welcome. Just fill in your Fedora open id (e.g., I put in
duffy.id.fedoraproject.org and I can auth that way):
http://fedoraserver-wgblog.rhcloud.com/wp-admin
Once you log in using your Fedora openid for the first time, it'll give
you a user on the system, and then I can go in and make you an editor or
an admin or whatever. Let me know. I would definitely appreciate some
help in terms of volunteers to be admins in case I get eaten by a raptor
or what not.
I also set up the blog to be aggregated on Planet Fedora and transferred
the two existing blog posts over to it, back dated appropriately.
Thanks,
~m
10 years, 4 months
introduction
by Renich Bon Ciric
Hey guys,
Glad to see a Server SIG for Fedora... finally!
I have several servers on Fedora and have upgraded/reinstalled since 5
years ago probably.
I am definitely interested in headless and kickstarts and cli tools.
--
It's hard to be free... but I love to struggle. Love isn't asked for;
it's just given. Respect isn't asked for; it's earned!
Renich Bon Ciric
http://www.woralelandia.com/
http://www.introbella.com/
10 years, 4 months
Updated & WG-Approved Governance Charter
by Máirín Duffy
Hi folks,
I've updated the governance charter with the changes and language we
agreed upon during today's meeting, and I fixed a few
spelling/grammatical typos as well:
https://fedoraproject.org/wiki/Server/Governance_Charter
I've updated the admon note at the top stating that we've approved the
document but it is not yet approved by FESCo.
Stephen, would you mind passing this over to FESCo since you are the
FESCo liaison?
Thanks,
~m
10 years, 4 months
Re: Draft Product Description for Fedora Workstation
by Paul W. Frields
On Fri, Nov 01, 2013 at 10:24:20AM -0400, Christian Fredrik Kalager Schaller wrote:
> Hi everyone,
> Attached is the draft PRD for the Workstation working group. The
> proposal tries to be relatively high level and focus on goals and
> principles, but I have included some concrete examples at times to try
> to provide some clarity on how the goals and principles could play out
> in practice.
>
> I hope the community at large will take the time to read through it and
> provide feedback so that when the working group meet next we can use
> that feedback to start tuning in on the final form of the PRD.
Here's a statement we may need to better clarify on p. 3:
"The working group will also specify policies in terms of branding,
themeing and desktop graphics."
I think we should be clear that any branding efforts need to fit into
the overall branding framework of Fedora. We should be careful to
avoid having branding diverge between the products to an extent that
makes it harder for us to identify them as part of a family of Fedora
products.
In my time as an FPL, I worked extensively with Fedora folks on
trademark and brand guidelines. I suspect Robyn has done quite the
same wherever possible. It would be a step backward to make it harder
for people to readily identify any of the Fedora products with
Fedora.
This is really a suggestion for all the working groups, so I'm cc'ing
server@ and cloud@ lists too.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com
10 years, 4 months
Meeting Summary / November 5, 2013
by Máirín Duffy
Hi folks!
Below find a summary of yesterday's meeting. You can also read it in
blog format at
http://blog.linuxgrrl.com/2013/11/05/fedora-server-working-group-nov-5-me...
. Below the summary, you'll find the meetbot links if you'd like to read
the raw logs.
Meeting Minutes
===============
Here’s a run-down of today’s Server Working Group meeting:
Agenda
======
* Finalizing the Governance Charter
* Is Fedora Server One Product?
Finalizing the Governance Charter
=================================
We had a discussion about two pending issues with the governance charter
and another issue regarding the use of the word 'quorum' in the document
before ultimately approving it.
Group Membership
----------------
Should the voting members of the server working group should be required
to be members of other Fedora teams as specified by their seat/slot?
We came to agreement after this discussion that it made sense to drop
the group mappings for now, but to also be sure that we added a note to
the membership section that we encourage involvement from all parts of
Fedora.
Term Length for Voting Members
------------------------------
Should membership as a voting member on the server working group be
unlimited / at will or should there be terms and elections/votes inbetween?
We agreed on a proposal that Nirik put forward that we would have
indefinite terms with periodic (every 6 months) confirmations and that
we would also revisit that decision in 6 months' time since we don't yet
know "a) how long we exist, b) how many non voting active people there
are in 6 months, c) if we need more fresh voting members or if as
Viking-Ice notes the active people in the community would be enough for
that.”
Quorum
------
mitr pointed out that the charter said we must have a quorum of 5 people
to vote, which means the majority of 5 people (which is 3) positive
votes would be required to agree to something in a vote.
The intention behind the statement was to require 5 positive votes,
regardless of how many people were present at the meeting, so the
verbiage was updated to reflect that and all agreed to it.
Governance Charter is Finalized by Server WG
--------------------------------------------
sgallagh will bring it to FESCo for review and approval.
Is Fedora Server One Product?
=============================
We didn't finish this discussion, so it will probably have to be brought
back up next week. This was a very active and interwoven discussion, so
here is my best attempt at summarizing it; I hope it's a fair summary:
Terminology Trouble
-------------------
We seem to have a lot of confusion about the term 'product' vs the term
'role' - if you eliminate both those terms and replace them with
'thingy' then we seem to agree on a lot more things than it appears on
the surface. I don't think we came up with viable terminology that made
sense to everybody, though.
Shared Components
-----------------
We all agree - whether the term 'product' or the term 'role' was used -
that they will share kernel, booting, basic libraries, and choice of
configuration/management/etc.
Preferred/Featured Technology Choices
-------------------------------------
It was proposed that we would make technology cohices about what is the
single supported way to do something (e.g., postfix for mailservers) but
users will not be precluding from installing alternatives (e.g., qmail
for mailservers), they will just get less support for it.
There was concern about the usage of the term 'support' and the term
'featured' was suggested, and I didn't see any other discussion about this.
Multiple Roles Per Single Server
--------------------------------
There was some disagreement about whether or not multiple roles/products
could be installed on the same server and whether or not something like
this was possible. I don't see much resolution to the conflict though, I
think the discussion died off for lack of time to resolve it.
Getting A PRD Started
---------------------
There was a disagreement about whether or not we needed one PRD with all
of the various roles/products in it, or whether we needed one PRD per
role/product.
Both sgallagh and nirik proposed that we put together a PRD with
separate chapters with the option to split it up into different
documents later if necessary.
There was some discussion about what parts of a role/product PRD would
be in the upstream's scope and what would be in our scope (modification
and integration to meet our goals would be in our scope.)
Then there was discussion over what a PRD is for. I think the conclusion
there was that it was to describe 'a common base platform with feature
application stacks built on top of it' to FESCo in order to get their
approval.
Meetbot Minutes
---------------
Here is the official meetbot meeting minutes with links to the full raw log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
Full set of meetbot links:
Meeting ended Tue Nov 5 18:03:12 2013 UTC.
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
Minutes (text):
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
Log:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
10 years, 4 months
Call for Agenda for 2013-11-05 Working Group meeting
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm very sorry for the late notice on this, but we only just finally
settled on the time for this meeting[1]. Please submit agenda requests
as replies to this email.
Also, I have a one-time conflict with this meeting, so I would like to
politely ask that Máirín please run the meeting[2] and record the
discussion as she did so well last week. I will try to lurk and
respond occasionally during my other meeting.
[1]
https://lists.fedoraproject.org/pipermail/server/2013-November/000424.html
(Tuesdays at 1600 UTC)
[2] http://fedoraproject.org/wiki/Zodbot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJ4MkgACgkQeiVVYja6o6NkQwCgnRJHb3G2EfesiLjELtat9A73
+FMAoJYAUvbq2rPJ/+cwrqptmAomyA/c
=pYMj
-----END PGP SIGNATURE-----
10 years, 4 months
Server WG meeting minutes 11-05-2013
by Truong Anh Tuan
Hi everyone,
I think it's worth to send the meeting minutes to the list, especially for
people who missed it.
Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
======================================================
#fedora-meeting-1: Server Working Group Weekly Meeting
======================================================
Meeting started by mizmo at 16:02:30 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeti...
.
Meeting summary
---------------
* roll call (mizmo, 16:02:39)
* agenda (mizmo, 16:05:11)
* LINK:
https://lists.fedoraproject.org/pipermail/server/2013-November/000425.html
(mizmo, 16:05:38)
* Finalizing the Governance Charter (mizmo, 16:06:58)
* LINK: https://fedoraproject.org/wiki/Server/Governance_Charter
(mizmo, 16:07:13)
* AGREED: In the governance charter, we will drop group mappings, with
a note saying we'd love involvement from any parts of the project.
(mizmo, 16:23:41)
* Finalizing the Governance Charter: Term Limits (mizmo, 16:23:58)
* AGREED: We'll add a section to the governance charter setting
6-month membership confirmation periods, but we will also revisit
that decision in 6 months time based on the community activity, how
long we intend to exist, etc. (mizmo, 16:51:49)
* AGREED: 'Quorum' for our purposes is at least 5 '+1' votes, and is
not proportional to the number of members attending the meeting
where the vote takes place. (mizmo, 16:56:31)
* AGREED: (revision) The number of votes required to pass a vote is at
least 5 '+1' votes, and is not proportional to the number of
members attending the meeting where the vote takes place. (mizmo,
16:58:10)
* ACTION: mizmo to take agreed points and edit the governance charter
(mizmo, 17:00:08)
* AGREED: We'll stay and work through more items on the agenda
(mizmo, 17:02:39)
* Is Fedora Server One Product? (mizmo, 17:03:04)
* LINK:
https://fedoraproject.org/wiki/Server/Product_Requirements_Document
(mizmo, 17:09:18)
* ACTION: mizmo to set up short term / long term goals document on
wiki (mizmo, 17:45:40)
* AGREED: Fedora Sevrer is a common base platform with 'featured
application stacks' built on top of it. We commit to produce, test
and distribute these application stacks. (mizmo, 17:45:51)
* AGREED: Our primary deliverable for January should be the definition
of how we're going to prepare the platform and the requirements for
an application stack to be promoted to first-tier inclusion.
(mizmo, 18:00:40)
* AGREED: (revised) Our primary deliverable for January should be the
definition of how we're going to prepare the platform and the
requirements for an application stack to be promoted to featured
status. (mizmo, 18:02:02)
Meeting ended at 18:03:12 UTC.
Action Items
------------
* mizmo to take agreed points and edit the governance charter
* mizmo to set up short term / long term goals document on wiki
Action Items, by person
-----------------------
* mizmo
* mizmo to take agreed points and edit the governance charter
* mizmo to set up short term / long term goals document on wiki
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mizmo (190)
* Viking-Ice (156)
* nirik (112)
* sgallagh (63)
* mitr (59)
* tuanta (23)
* Evolution (7)
* zodbot (6)
* kde_tony (4)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Kind regards,
Tuan
10 years, 4 months