Proposed Server release criteria for F21 Beta and Final
by Adam Williamson
Hi, folks. So, I drew up a rough draft of the Server release criteria
for Beta and Final as I suggest they might be. We could kick it around
at tomorrow's meeting if desired. Here we go:
BETA
=== Remote logging ===
It must be possible to forward system logs to a remote system using
Server packages.
=== Firewall configuration ===
Release-blocking roles must be able to report their status in regard to
the system firewall as described in the
[[Server/Technical_Specification#Firewall|technical specification]].
=== Roles ===
Release-blocking roles and the supported role configuration interfaces
must meet the core functional
[[Server/Technical_Specification#Role_Definition_Requirements|Role
Definition Requirements]] to the extent that supported roles can be
successfully started, stopped, and queried.
=== Cockpit ===
??????
FINAL
=== Roles ===
Release-blocking roles and the supported role configuration interfaces
must fully meet the
[[Server/Technical_Specification#Role_Definition_Requirements|Role
Definition Requirements]].
=== Cockpit ===
??????
You will note first of all the big ?????? for Cockpit. Cockpit's role
really isn't terribly well defined in the tech spec or PRD, so it is
hard to draft requirements. Is it primarily supposed to be an interface
for controlling roles? If so, can we treat it that way in the criteria,
and require things from it as regards its job in configuring roles?
I think the Role criteria described above would be okay, and at least
unambitious enough not to cause huge problems, for F21, but I'm really
not that happy with them for the long term.
It's obviously not practical to start hardcoding specific requirements
for specific roles into the criteria. What I would like instead is to
have a little more process on the Product side for Roles. I'd suggest
that Roles themselves should have definitions of their expected
functionality baked in at the point of creation / approval.
These could be split into sections to be required at Alpha, Beta and
Final. You could, for instance, expect roles to basically start up and
not explode at Alpha, expect them to be broadly 'feature complete' and
testable at Beta, and expect them to fully meet their listed functional
requirements at Final, just as a quick cut. Here's a very rough mock-up
for the "Domain Controller" role as a guide:
Alpha
-----
The Role must start and stop successfully. When the role is running, a
client system must be able to enrol into the FreeIPA domain.
Beta
----
When the Role is running, it must be able to enrol and unenrol multiple
clients. Client systems must be able to authenticate user accounts via
Kerberos. The FreeIPA configuration web UI must be available and allow
at least basic configuration of user accounts and permissions.
Final
-----
Oh, I don't know, I'm running out of ideas, I don't do that much more
with my FreeIPA system than is described in Beta. You know better than
me! That's why you should be writing this! :)
Well, I sort of ran out of steam at the end there, but you kinda get the
idea, right?
We can set things up appropriately so the release criteria can sensibly
call out to them. I'd expect the criteria would just say something like
'Release-blocking roles must meet the functional requirements listed in
their definition pages for the Beta milestone' or whatever, with a link
to a sensible target from which you could easily find the Role
definition pages.
I'd be very grateful for feedback on both the proposed criteria for F21,
and the idea above. We do need to get the Beta criteria in place ASAP,
Beta TC1 is due tomorrow (yes, I know, no rest for the wicked :/) I'll
start drafting up test cases ASAP.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 12 months
Server WG Meeting Minutes (2014-09-30)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-09-30)
===================================================================
Meeting started by sgallagh at 14:59:45 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-30/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 14:59:46)
* Agenda (sgallagh, 15:03:09)
* Agenda Item: Fedora 21 Release Criteria (sgallagh, 15:03:09)
* Fedora 21 Release Criteria (sgallagh, 15:04:36)
* ACTION: stefw to discuss with the Cockpit upstream what Beta
Criteria they should have (sgallagh, 15:26:08)
* adamw's proposed criteria were largely accepted, with some pending
additions to Cockpit and the Domain Controller role forthcoming.
(sgallagh, 15:31:39)
* Open Floor (sgallagh, 15:31:50)
Meeting ended at 15:34:21 UTC.
Action Items
- ------------
* stefw to discuss with the Cockpit upstream what Beta Criteria they
should have
Action Items, by person
- -----------------------
* stefw
* stefw to discuss with the Cockpit upstream what Beta Criteria they
should have
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (51)
* adamw (29)
* stefw (8)
* nirik (5)
* zodbot (3)
* mitr (2)
* tuanta (1)
* simo (1)
* davidstrauss (0)
* mizmo (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQqzmIACgkQeiVVYja6o6PWDACfXlu5EaRZV3SYthtj9Nh2BIw9
jVgAoIST+ojOWMk2Z8KHKzba8AsP1khX
=LCF2
-----END PGP SIGNATURE-----
8 years, 12 months
"Package sets" release criterion: what to do with it?
by Adam Williamson
Hi, folks. I'm checking the release criteria again for Fedora.next
compatibility, and there's an Alpha criterion with obvious issues:
"Package sets
When doing a graphical install using the dedicated installer images, the
installer must be able to install each of the release blocking desktops,
as well as the minimal package set. "
This was obviously written to the world where we had generic installer
images - the DVD, and intentionally-generic netinsts. We do not have
those things any more.
Do we want to dump this criterion entirely, or is there any of it we
would like to keep? For instance, would we consider it 'release
blocking' functionality for you to be able to do some/any of the above
from the Server and/or Workstation network install images *after
configuring the repos manually*? Particularly, the minimal installation?
I'm not sure F21 as currently conceived would offer an avenue for doing
an interactive minimal installation.
Basically, it comes down to: do we want to have a blessed method for
doing a network install of KDE and/or minimal? If so, do we want to
block releases on it?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 12 months
Server Roles
by John Unland
>Hi John!
>As Fedora Server is a community project driven by whoever is
>interested in doing the work, certainly we'd like your help on things.
>I want to clarify first that I think you have the wrong idea about
>what a "Server Role" is. The idea is for a server role to be a
>singular task for the server to perform. A machine may be assigned
>multiple roles, but they should be managed individually.
>I don't see us having a "Small Business" role, in part because that
>implies many different things to many different people. Instead, we'd
>be talking more about roles like "Domain Controller", "ownCloud
>Services" or "OpenStack Node".
>We *do* need to start talking about whether we want a graphical option
>for Fedora Server 22. We expressly deferred that decision because our
>initial target was focusing on headless systems.
>John, would you mind running down the use-cases you have for having a
>local graphical login on your servers (as opposed to remote services
>like SSH or web-based configuration tools like Ajenti or Cockpit)?
Okay, I understand. Well I think you do have a point there. It would
kinda break the flow of the list in the installation process (Now
thinking about it). However I am just now looking at the chat log of
you all talking about having multiple roles in one single physical
server (If my context clues are right).
I know for the beta and I think the full release you want just the
base + essential server roles, and then later down the road your going
to define more. How about you leave the essential roles for now that
way you will have somewhat have a base to go off of other servers
(ownCloud, Round Cube, HPC roles, etc.), BUT create a template so that
members of the community can create there own roles and add it to a
repo list. Kinda like having the Play Store on Android but for
servers. I know you are still in Alpha phase but this is just
something to consider, but I digress.
As for use-cases, I see it like this:
Case 1: Migration of servers.
Ex: Server A is a old model so were going to migrate the configuration
to the new Server A. (You really have to be there physically there to
mess with hardware / networking)
Case 2: Install / Remove Hardware.
Ex: Faulty RAM / CPU / Hard drive (That is not hotswapable) you want a
quick way to identify the server and turn it off from a KVM inside the
rack. (Not all company's will have a dedicated machine to SSH or go
into a web-browser to configure these things. They may still have
KVM's inside there cabinets.)
Case 3: Installation of server software (Open Source AND Proprietary).
Ex: Bitnami + your appliance, a appliance software stack where you can
install it in a VM or locally inside a desktop. However you need to
have a GUI to configure / start/stop / view logs to install locally.
(They still have there own web interface in a browser but you still
need a GUI to install it.)
Sidenote: Case 3 ~ When you install Bitnami + your appliance locally
it uses the Container feature like Docker so it does not interfere
with other configurations in the same server.
When I was doing my research at my University, I opted to give the
user to use either the Ajenti, because it was a quick overview of your
server / services that you were running. AND I wanted to have a
configuration / overview control panel locally (That I was going to
build in-house) so that you could have more advanced outlook on your
server as well as local documentation, Hardware Install / Uninstall
Wizard, and some other helpful stuff for the person. Because I figured
that a small business didn't have a IT staff so it had to depend on
ques from the software logs / messages and the documentation. But you
could pretty much run the server from either both or one of them just
fine...
So those are my cases, hope this was some of help to you. :)
John
9 years
Server Roles
by John Unland
Greetings,
I'll cut to the chase. I am doing research on opensource small business
server adaptation for my University. I am using Ubuntu as of now with
software stack to have a SB infrastructure. However I recently heard that
Fedora was releasing there Alpha for Fedora Server. I have already tested
it out for myself. Is there anyway that I can somehow work with you all to
maybe have a server role for Small Businesses? Below is what I'm using for
the server.
Lightweight DE: LXDE or Xfce
Bitnami applications (DB, ownCloud, openERP, Round Cube, DNS etc.)
CUPS for print server
Ajenti for a control panel.(Was using this but since F21 is going to use
Cockpit then I maybe will switch to that)
1 or 2 concept software control panels that are in the works right now.
(TBD)
I have already read into your Persona's or "Target Market"(and other
documents on the Wiki) and it seems to target people with experience in
Linux / Networking stuff like that. So I know my request a little bit out
of your scope, but I figured I'd ask to see if I could get this server role
into the Alpha, Beta, or Full release.
Sorry about the long post.
John
9 years
Download
by Omar José Tercero Moreira
Hello,
I would like to know where can i download fedora for server?.
and is it free too?
Thanks for help,
9 years
2014-09-24 @ 16:00 UTC ** F21 Blocker Review
by Mike Ruckman
# F21 Blocker Review meeting
# Date: 2014-09-24
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net
Well now that we've finally kicked Alpha out the door, it's time to do some
Beta blocker review. You might think, "Oh, hey - that'll be easy, we just
started!" However, you'd be wrong. We've been tracking beta and final blockers
as well this whole time :) With that said, we have a total of 25 proposed
blockers to go through. So be prepared to get comfortable for the meeting.
If you want to take a look at the accepted blockers, the full list can be found
here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist
We'll be evaluating these bugs to see if they violate the Beta
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F21 can be found on the
wiki [0]. Product specific plans are still being solidified, but that
should be sorted quickly.
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
See you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
// Mike
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
9 years
Server Working Group Weekly Meeting Minutes (2014-08-19)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-08-19)
===================================================================
Meeting started by sgallagh at 15:01:08 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-23/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 15:01:08)
* Agenda (sgallagh, 15:05:40)
* Agenda Item: Fedora 21 Beta Planning (sgallagh, 15:05:40)
* Agenda Item: Cockpit PolicyKit Rules (sgallagh, 15:05:41)
* Cockpit PolicyKit Rules (sgallagh, 15:08:51)
* Cockpit would like to ship its own policykit rules (sgallagh,
15:10:02)
* Cockpit wants to be able to define permission roles besides
membership in the "wheel" group (sgallagh, 15:10:30)
* ACTION: stefw to start a conversation on role definition in Cockpit
on the mailing list (sgallagh, 15:33:42)
* ACTION: sgallagh will create a tracking bug for BZs of interest to
the Server WG (sgallagh, 15:33:57)
* Future WG meetings will involve a review and status update on any
bugs connected to that tracker (sgallagh, 15:34:19)
* Fedora 21 Beta Planning (sgallagh, 15:34:38)
* First topic: Beta release criteria (sgallagh, 15:34:52)
* Open Floor (sgallagh, 15:57:37)
Meeting ended at 16:00:53 UTC.
Action Items
- ------------
* stefw to start a conversation on role definition in Cockpit on the
mailing list
* sgallagh will create a tracking bug for BZs of interest to the Server
WG
Action Items, by person
- -----------------------
* sgallagh
* sgallagh will create a tracking bug for BZs of interest to the
Server WG
* stefw
* stefw to start a conversation on role definition in Cockpit on the
mailing list
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (75)
* stefw (47)
* adamw (44)
* simo (35)
* mitr (20)
* zodbot (5)
* tuanta (3)
* danofsatx-work (2)
* davidstrauss (2)
* davidstrauss_ (1)
* nirik (0)
* mizmo (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlQhmS4ACgkQeiVVYja6o6MoswCgnzpMhPwfaju7UaYUCXFp94i4
HdcAn1jTv3Wjz16XG7Qn+CWIQ0S4a8Oa
=WbvH
-----END PGP SIGNATURE-----
9 years
