Draft separation of Server Role requirements from criteria
by Adam Williamson
Hi, folks!
For F21 we stuffed the functional requirements for the sole Role
(domain controller) into the release criteria. But we all agreed this
was kinda sucky and wouldn't scale, and they should be split out
somehow.
Here's my proposal for 'somehow'.
At first I was thinking of a sort of general 'role definition' wiki
page, but when I sat down to draft one I couldn't really think of much
that would go on one *besides* the functional requirements, so I
figured I'd keep it simple and just draft a template for requirements.
So, my draft consists of a template:
https://fedoraproject.org/wiki/User:Adamwill/Draft_role_requirements_temp...
an example implementation:
https://fedoraproject.org/wiki/User:Adamwill/Draft_domain_controller_role...
a category page:
https://fedoraproject.org/wiki/Category:Server_role_requirements
which also acts as a short overall explanation of the 'requirements'
system, and a proposal for the release criteria. We'd drop all the
domain controller stuff, and add the following criteria:
Alpha
-----
* The [[:Category:Server_role_requirements|core requirements]] for all
Featured Server Roles must be met, but it is acceptable if moderate
workarounds are necessary to achieve this
footnote #1: Featured roles - [[FIXME|this page]] contains the list of
Featured server roles
footnote #2: Moderate workarounds? - For instance, if a service needs
to be manually enabled or a configuration file minimally tweaked, this
is acceptable.
Beta
----
* The [[:Category:Server_role_requirements|core requirements]] for all
Featured Server Roles must be met, without any workarounds being
necessary
* The [[:Category:Server_role_requirements|other requirements]] for
all Featured Server Roles must be met, but it is acceptable if
moderate workarounds are necessary to achieve this
footnote #1: Workarounds - This means the role must meet its core
requirements, i.e. be broadly usable for its intended purpose, after
correct deployment and configuration via the role mechanism, but
moderate workarounds as described in the [[BLAH|Alpha criterion]] are
acceptable if necessary to fulfill the full set of requirements.
Final
-----
* All [[:Category:Server_role_requirements|requirements]] for all
Featured Server Roles must be met, without any workarounds being
necessary
The FIXME indicates we also need some kind of place where we define
which server roles are 'Featured', which AFAIK we don't at present.
In case anyone's wondering why I didn't simply have Alpha, Beta and
Final requirements for each role, I considered that, but it seemed a
bit too tightly couple to a particular release process, when we've
discussed changing the Server release process in future. I quite like
the way this proposal puts the things together; all the concepts make
sense separately, for me. It makes sense just thinking about a Server
product, whatever its release process, that Roles would have the two
levels of requirements specified in the proposal ("Core" and regular).
And then as a separate matter it makes sense (to me) to enforce them
at the Alpha, Beta and Final points of our *current* release process
in the way proposed above.
What do folks think of this general proposal? Thanks! We can also
discuss it at the meeting next week if folks want to.
Note, the actual requirements listed on the domain controller page are
copy/pasted straight out of the F21 criteria; we can certainly tweak
and extend those, but please if you want to discuss that make it a
separate thread, the intent here is for us to discuss this *framework*
for role requirements and hooking them into the release criteria.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 7 months
Server SIG Weekly Meeting Minutes (2014-01-27)
by Stephen Gallagher
=========================================================
#fedora-meeting-1: Server SIG Weekly Meeting (2014-01-27)
=========================================================
Meeting started by sgallagh at 16:01:45 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-27/fedora-meeti...
.
Meeting summary
---------------
* roll call (sgallagh, 16:01:51)
* Fedora 22 progress (sgallagh, 16:09:41)
* The anaconda team has added new hooks in Fedora 22, so we can
simplify the branding needs as well as altering the defaults for
things like partitioning. This is going to make it easier to
generate the product-specific install media. (sgallagh, 16:11:33)
* I've got a proof-of-concept of the Database Server Role in progress
on my github clone of the rolekit repo. It's about 50% complete at
this point. (sgallagh, 16:14:44)
* I've worked with the Cockpit upstream designer and we have a visual
design ready for the Domain Controller support. However, I have
nonexistent JavaScript skills and am looking for a volunteer to help
with implementation. (sgallagh, 16:16:45)
* Anyone with some JavaScript skills and an interest in Fedora Server
is invited to help with adding the Domain Controller Role to
Cockpit. (sgallagh, 16:19:57)
* Open Floor (sgallagh, 16:26:52)
* ACTION: Corey84 volunteers for testing Server features. (sgallagh,
16:31:12)
Meeting ended at 16:35:14 UTC.
Action Items
------------
* Corey84 volunteers for testing Server features.
Action Items, by person
-----------------------
* Corey84
* Corey84 volunteers for testing Server features.
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* sgallagh (38)
* Corey84 (13)
* danofsatx (8)
* simo (6)
* zodbot (5)
* nirik (3)
* corey84-- (3)
* jsmith (2)
* adamw (0)
* mitr (0)
* stefw (0)
* tuanta (0)
* mizmo (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 8 months
Server support of ARM
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
While anaconda works very well on ARM to install Fedora and should be
the recommended way to install Fedora, particularly for Server. Many
people are used to using disk images and some hardware (most relevant
is teh beaglebone black[1]) are not capable of really running the
anaconda due to limited memory. I would like to propose that the Server
WG adds a ARM disk image that would be a pre-canned Server install that
can be put onto a sdcard or put internally onto a system to allow
someone to run Fedora Server.
There is a Minimal disk image today that will still exist and would
serve a different purpose. The way the images work is that on first
boot you get initial-setup run to set language, timezone, set root
password and optionally create a user.
I have installed cockpit on an arm box and hit one bug[2] possibly the
docker support should be disabled as docker is only supported on
x86_64 the same would be true of 32 bit x86 installs as well as other
arches. otherwise things seemed to work okay.
I feel there is value for users, especially home users in running
Fedora Server even on low end hardware, a beaglebone black for instance
would make a great dns, dhcp, server. I would like to run freeipa on a
arm box. hardware like the cubietruck[3] are good potential candidates
for running Fedora Server on also. they are a couple of readily
available options. less readily available is server hardware like we
use as the builders in Fedora. Which are all running Fedora 21.
In order to make a Fedora Server ARM disk image we would need a
kickstart. I am happy to get it started and in spin-kickstarts but
would appreciate someone from teh WG taking ownership of it. one thing
that me need some thought and discussion would be the disk partitioning
of the image.
Regards
Dennis
[1] http://beagleboard.org/black
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1186019
[3] http://docs.cubieboard.org/products/start#a20-cubietruck
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJUx+bEAAoJEH7ltONmPFDRbasP/3zZLQREqBXqN0NkC++IPyrj
QSOt7eQ3rJYCTkCQVUnVrZEboCQkpMGcc8iJBoTnw/148JJknY5187tbWB+ayxGQ
Y5v4ksp82UZsOuE6fWi5jR257ko9uQKiwgLNPcUy/wE1ZNgHCqBrNWwIcBNSzmtd
wHOkEh+MFurGbwHoLY6VH5F6yP6+y2VuX/eV0NNLhTjUvXFEoaRmKBIQLHMts3l3
Gxzbzt89k2+IKXQvbmPtwMbpCsEuow1AuwgN8PNYZ+yvQFOQjYGkuGGIRA3sxD46
8lcxLqkw9IuNtH9c779PdBH5i74LS74nm5B8T9rt7Q538fhCj5OTrS+2X5ANmNlA
h8g6cqH3/3ubxM+0vGsieG0Ol7p6aZhlzpR5Ul8NFm1Uegc89yMCmoIbhoCJEcnb
jAAJ7fwh04c0ae9vm1wpGl26M/G4hmDW0Iw5/jrHklUlWGNCIYcva0y6jyUJWxFb
SuRI+RP57Kzxfi91TwMQoMfRcx1b9DmvFbgwYSRdNTCkYw2uXlBL8tmbMLH79mx5
X6R0qBOQaT45FjG5RIDPfDumJ5pl8oobzVwEfI8+Ych4fnr+8ClKu4uz98yXPoGV
kbM2+wT5k0GFMzLejI+WO3DnCKNP7Ekfkq+QZUGzOU6YIjZrCtiknZzSJisdfKmw
P97qzAZTG12F14pDlCKF
=rj60
-----END PGP SIGNATURE-----
8 years, 8 months
Anyone running Ceph?
by Patrick McGarry
Hey all,
As the Ceph team dives deeper and deeper into the multi-headed distro
world I'm looking to gather anecdotal evidence of what the Ceph user
experience is like on various distros. If anyone here is running (or
has run) Ceph on some flavor of Fedora, I'd love to hear about it.
My hope is that we can work with the Fedora community to polish off
any difficulties or awkwardness that may still exist. Thanks!
Best Regards,
Patrick McGarry
Director Ceph Community || Red Hat
http://ceph.com || http://community.redhat.com
@scuttlemonkey || @ceph
8 years, 8 months
Plan of Record for Fedora 22 Network Install Media
by Stephen Gallagher
(Cross-posted to the WG mailing lists; please reply only to devel@)
== Overview ==
Today in #anaconda, we had a discussion of the plans for network install
media for Fedora 22. We acknowledged that the network install (and more
generally, unattended installation) story in Fedora 21 was somewhat
lacking. In particular, there was user confusion around how to deploy
Fedora Workstation in an unattended manner.
Some of the problems we faced in Fedora 21 were a result of not having
necessary plumbing in Anaconda (largely because we didn't even realize
this until well into Beta phase, at which point we just started breaking
out the duct tape and chewing gum). In particular, we needed a way for
individual Fedora editions to provide a mechanism for specifying
different defaults (such as automatic partitioning rules or the default
environment group that would be displayed in an attended install).
Without these things, while we could produce media with separate
graphical branding, we couldn't truly produce separate network installs
for Cloud, Server and Workstation. So we settled on producing only the
Server network install media.
== Output ==
In Fedora 22, we will be producing four network install ISOs:
* Fedora Server
- Server branding
- Default environment group: Fedora Server
- Auto-partitioning defaults: LVM on XFS (except /boot)
- Responsible WG: Server WG
* Fedora Workstation
- Workstation branding
- Default environment group: Fedora Workstation
- Auto-partitioning defaults: LVM on EXT4
- Responsible WG: Workstation WG
* Fedora Cloud
- Cloud branding
- Default environment group: Fedora Cloud
- Auto-partitioning defaults: TBD
- Responsible WG: Cloud WG
* Fedora "Generic" (name TBD)
- Generic Fedora branding
- Default environment group: minimal
- Auto-partitioning defaults: TBD
- Responsible WG: Base WG
In addition, there is ongoing discussion around media for bare-metal
Fedora Atomic installations. This has not been finalized, but will
likely result in an additional output.
While each of these network installs will be *capable* of also
installing any of the other products (though possibly not with the
expected auto-paritioning), we have agreed that QA testing will only be
performed on the intended environment group target for the branded
media. We will not advertise or make any special effort to support other
targets.
== Remaining work that needs to be done ==
Release engineering will need to modify their compose tools to produce
each of these install trees, as well as handling the necessary mirroring
functions.
The working groups responsible for each of these install media will be
responsible for performing the following tasks before the Alpha Freeze
(ideally well before, so we can run test composes and fix issues without
slipping):
* Modify the appropriate fedora-productimg-$PRODUCT package to include
an anaconda extension model that will extend the InstallClass and set
the default environment group and optionally modify the
auto-partitioning functionality.
* Review the contents of comps-f22.xml.in and the related kickstart
files in spin-kickstarts to ensure that the install media contains the
appropriate content.
For simplicity in understanding who to contact, it would be beneficial
if each of the responsible working groups would nominate an individual
to be the point of contact on these changes. I volunteer myself to
represent the Server WG in this capacity.
Given that we branch on February 10th enter Alpha Freeze on February
24th, I'd like to propose a soft deadline (a check-in) on February 9th
with a hard deadline on February 16th in order to have time to run at
least one test compose prior to Alpha Freeze.
== Acknowledgements ==
The cast of characters involved in this discussion were:
* Stephen Gallagher (Server WG)
* Dennis Gilmore (Release Engineering)
* Brian C. Lane (Anaconda)
* Ian McLeod (Project Atomic)
* David Shea (Anaconda)
* Adam Williamson (QA)
8 years, 8 months
Server SIG Weekly Meeting Minutes (2015-01-13)
by Stephen Gallagher
=========================================================
#fedora-meeting-1: Server SIG Weekly Meeting (2015-01-13)
=========================================================
Meeting started by nirik at 16:00:23 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeti...
.
Meeting summary
---------------
* roll call (nirik, 16:00:24)
* Agenda (nirik, 16:03:36)
* Discuss pending F22 changes related to server (nirik, 16:05:41)
* Discuss pending F22 changes related to server (nirik, 16:07:57)
* AGREED: The server SIG feels that the ssh config proposal provides
very minimal security improvement, and is not worth any reduction in
usability; accepting this change would make sense only if all
relevant UIs/tools were adapted to fully support system usage after
this change. [Excluding the case that "changing anything is an
unfixable reduction in usability"] (+6, +1, 0) (nirik, 16:53:41)
* Database role for f22 (nirik, 16:53:45)
* help wanted to code-review and test database role soon. (nirik,
17:02:14)
* AGREED: will not block on a management interface. Will look at
working with pgadmin3 on workstation (+6,0,0) (nirik, 17:05:34)
* Open Floor (nirik, 17:06:09)
Meeting ended at 17:07:08 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* simo (95)
* nirik (70)
* sgallagh (69)
* mitr (36)
* junland_2 (24)
* danofsatx|w (20)
* adamw (19)
* zodbot (8)
* tuanta_ (5)
* junland (2)
* stefw (0)
* danofsatx (0)
* tuanta (0)
* mizmo (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
8 years, 8 months
Re: Agenda for Env-and-Stacks WG meeting (2015-01-14)
by Honza Horak
Env & Stacks WG is going to define (hopefully) some more concrete Rings
plans on tomorrow's meeting. Expecting to be an interesting discussion,
important enough for wider audience, let me crosspost the invitation
also to other working groups.
(we're aware of not very friendly time for US folks, but it doesn't seem
worth changing the time-slot before the elections, since we're gonna do
it after the elections anyway; feel free to use the mailing list
env-and-stacks(a)fp.o instead)
Honza
On 01/12/2015 04:46 PM, Honza Horak wrote:
> WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston,
> 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode.
>
> = Topics =
> * Fedora Rings
> * revisit the plan around rings
> * interpret rings with users' use cases and requirements
> * sync on where SCLs, copr, languages repositories etc. fit into
> rings ideas
> * Chairman for next meeting
> * Open Floor
>
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
8 years, 8 months
