The following proposal comes out of the discussion at this weeks Server SIG
meeting[1]
Fedora Server will have:
* / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
* SWAP will continue to be calculated automatically based on available RAM on
the system
* All unused space will be assigned to a volume group and available to be
assigned to new partitions or extend existing partitions.
* Anaconda will continue to handle the appropriate EFI and /boot settings
We also discussed during the meeting whether we should have a separate /var
partition by default, but the general sense was that we might be better served
by developing a mechanism to allow partitions to be split from existing mount
points, which would be more flexible going forward.
As we did not have quorum in the meeting by the point we got to this proposal,
I'm taking it to the list for discussion and votes.
For the record, the current behavior of the partitioning scheme is for / to be
given up to 50 GiB of space and then any remaining space after that is assigned
to a separate /home partition.
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2016-03-15/serversig.201…
Hey all,
As some of you may know, one of the upstream projects I work with is
the Snappy/Snapcraft system.
Recently, the Snappy system gained full support for having alternative
base/runtimes used for the basis of snaps[1]. Given the design of the
Snappy system, it makes it very easy for us to provide a model in
which people can build applications and services using Fedora in a
manner where it's available in a cross-distribution fashion. One of
the key advantages here is that we do not need to rebuild RPMs to
retrofit them for the snap model, they can be directly sourced and
installed as components to build a snap.
However, to be able to do this, Fedora needs to provide what is known
as a "base snap". The base snap provides the foundation for
applications and devices to be built using Fedora software with snaps.
Historically, the only "base" supported for general application use
has been the Ubuntu one shipped by Canonical, but snapd recently
learned how to use different "base" runtimes for different snaps.
I believe we have an opportunity to be a great enabler for offering
the latest and greatest technologies for developers to consume for
their software if they want to distribute it as a snap. While the
Fedora Workstation WG has been primarily focused on Flatpaks for GUI
applications, snaps are useful for more than desktop applications.
Indeed, some of the most interesting uses are involved with server and
embedded systems software.
I've worked closely with the upstream developers (of which Zygmunt
Krynicki is the main point of contact for Fedora with the Snappy team
and is CC'd to this email) to ensure that this functionality is
available to us in a way that allows us to leverage our software as
effectively as possible. In addition, I've built a relatively trivial
application[2] to build proof of concept core base snaps with Fedora,
Mageia, and openSUSE packages.
At least initially, some of these first application snaps will be
produced in a rather simple manner as we would work with upstream on
figuring out how to adapt Snapcraft to handle alternative bases. My
eventual goal is to be able to produce a Modular Fedora variant that
works off snaps, using our software packaged as RPMs as inputs, as a
variation of the modularity work going on in Fedora as a whole. This
work would be more or less similar to the efforts for producing the
Cloud Base images that are used in cloud providers and for container
systems to use (e.g. Docker/OpenShift/Kubernetes).
I discussed this with Stephen Gallagher, and he seemed amenable to the
idea of the Server WG producing the base snap as a deliverable and
publishing it to the snap store so that it can be used to build
applications. He suggested that I bring this to broader WG mailing
list to solicit some feedback on this.
So what do you all think?
Best regards,
Neal
[1]: https://forum.snapcraft.io/t/introducing-base-snaps/381
[2]: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
--
真実はいつも一つ!/ Always, there's only one truth!
# F28 Blocker Review meeting
# Date: 2018-04-23
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 2 proposed blockers, 5 proposed freeze exception
issues and 4 accepted blockers for Final to review, so let's have a
review meeting on Monday.
If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F28 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good weekend and see you on Monday!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
I will be out of town tomorrow during the meeting and won't be able to
attend. Can someone else volunteer to chair the meeting? Mostly I just want
us to level-set on where we are as we enter Final Freeze.
# F28 Blocker Review meeting
# Date: 2018-04-16
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 6 proposed blockers and 5 proposed freeze exception
issues for Final to review, so let's have a review meeting on Monday.
If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F28 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good weekend and see you on Monday!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
Preamble: I know we're planning to throw rolekit out entirely, but I
believe we're planning to continue to consider the actual functions
behind the roles (FreeIPA and postgres) as blocking, so I'd like to get
this done so we remember to include it in that change.
Postamble: Back in F27 cycle, specifically in the 2017-10-23 blocker
review meeting, we agreed to cover the release-blocking Server roles in
the upgrade criteria. That is noted here:
https://bugzilla.redhat.com/show_bug.cgi?id=1503321#c7
However, we never actually made the change. So, here I am proposing it!
We should change the Beta criterion 'Upgrade requirements' as follows.
Main text should go from:
"For each one of the release-blocking package sets, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
set installed."
to:
"For each one of the release-blocking package sets, and the package
sets for each of the release-blocking Server roles, it must be possible
to successfully complete a direct upgrade from fully updated
installations of the last two stable Fedora releases with that package
set installed."
I think that's actually all the change necessary, as the bullet point
"The upgraded system must meet all release criteria" then requires that
the upgraded roles actually work.
Thoughts? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
I have a conflict today and won't be available to run the meeting. I think
it would still be good to have some more live brainstorming, so if someone
else could volunteer to start the meeting record and guide the
conversation, I'd appreciate it.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2018-04-03)
================================================================
Meeting started by sgallagh at 20:00:17 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-03/serversig.2…
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 20:00:18)
* Agenda (sgallagh, 20:06:40)
* Agenda Item: Brainstorming (sgallagh, 20:06:46)
* Brainstorming (sgallagh, 20:07:36)
* Feedback: Fedora Server has too short a lifecycle (sgallagh,
20:08:35)
* Feedback: Fedora Server should be more minimalistic (sgallagh,
20:08:35)
* Feedback: SELinux needs better usability (sgallagh, 20:08:35)
* Feedback: Support OpenCL (sgallagh, 20:08:36)
* Feedback: Easy "home media server" would be nice (sgallagh,
20:08:36)
* Feedback: Cockpit should be able to control more of the system
(sgallagh, 20:08:36)
* Feedback: Focus on simplifying common task execution (sgallagh,
20:08:36)
* Feedback: Support enterprise HBAs (sgallagh, 20:08:37)
* We will go through the list individually (sgallagh, 20:11:46)
* Fedora Server has too short a lifecycle (sgallagh, 20:12:01)
* The core problem that people want to solve generally is "I don't
want my applications to break, because I rely on them" (sgallagh,
20:14:16)
* Rephrased: Core problem is "I want to be able to keep my system
up-to-date wrt bug and security fixes without my applications
breaking" (sgallagh, 20:16:35)
* Users automatically assume that the classic solution to this problem
is the only one: longer compatibility lifecycle for the whole OS.
(sgallagh, 20:17:34)
* Fedora Server attempts to solve the core problem with Modules and
reliable OS release upgrades. (sgallagh, 20:18:25)
* Enhancement proposal: automatically upgrade when release is EOL
(sgallagh, 20:22:03)
* Enhancement proposal supplement: Cockpit UI for scheduling the
automatic update after EOL (sgallagh, 20:23:11)
* Fedora Server should be more minimalistic (sgallagh, 20:27:38)
* This topic is really easy to get rat-holed on. Will revisit later.
(sgallagh, 20:40:44)
* SELinux needs better usability (sgallagh, 20:40:52)
* Cockpit SELinux Troubleshooter improvements would be ideal for this
(sgallagh, 20:43:59)
* Support OpenCL (sgallagh, 20:46:42)
* This task would require specialized expertise that isn't readily
available (sgallagh, 20:48:40)
* Easy "home media server" (sgallagh, 20:48:56)
* Server Focus (sgallagh, 20:55:07)
* Q: Is there a customer story similar to our previous OLPC effort
that we could get behind? (sgallagh, 20:55:41)
* LINK: https://freedombox.org/ ? (nirik, 20:56:01)
* ACTION: Homework assignment: Think of an OLPC-style initiative that
Server could back and present it next week. (sgallagh, 21:00:24)
Meeting ended at 21:04:33 UTC.
Action Items
- ------------
* Homework assignment: Think of an OLPC-style initiative that Server
could back and present it next week.
Action Items, by person
- -----------------------
* **UNASSIGNED**
* Homework assignment: Think of an OLPC-style initiative that Server
could back and present it next week.
People Present (lines said)
- ---------------------------
* sgallagh (129)
* dperpeet (46)
* nirik (39)
* smooge (13)
* bowlofeggs (11)
* orc_fedo_ (8)
* zodbot (7)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.2.0
Comment: https://www.mailvelope.com
wkYEAREIABAFAlrD7H0JEHolVWI2uqOjAABNHQCfcqkENOdc+3GL6IDtztb/
7uDD4GYAniSTQYmDy5RGNkZqFZU/lWWzOxjq
=uiPJ
-----END PGP SIGNATURE-----
# F28 Blocker Review meeting
# Date: 2018-04-09
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
Hi folks! We have 6 proposed blockers and 2 proposed freeze exception
issues for Final to review, so let's have a review meeting on Monday.
If you have time today, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F28 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good weekend and see you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net