Server WG Meeting Agenda (2014-01-14)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Only one thing on the agenda this week: finalizing the PRD. Current
draft is at
https://fedoraproject.org/w/index.php?title=Server/Product_Requirements_D...
There is one outstanding FIXME and a couple points that we need to
negotiate with the Cloud and Environments stacks. I'm inviting their
liasons to the meeting (CCed) to hopefully sort those last bits out.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLUVBQACgkQeiVVYja6o6NCXwCgqEjiIg9OXCN/GVv8sldGQS99
eW0Amwd+I4Um+fkcAUwlcq249kG4wVtq
=XxqS
-----END PGP SIGNATURE-----
9 years, 2 months
Introduction
by Joerg Stephan
Hi there,
i was informed that there is something going on :-)
my name is Jörg Stephan and i am mainly a system administrator/security guy.
I was a long time away from fedora and now i am back again and would like to contribute again. For more Informations there is an old info page
https://fedoraproject.org/wiki/User:Johe
last time i was around i made a list
https://fedoraproject.org/wiki/SIGs/Server/ServersOverview_alpha
so how can i help?
Cheers
--
Joerg Stephan
9 years, 2 months
PRD Hackfest on 8 January 2014
by Joe Brockmeier
The following is a new meeting request:
Subject: PRD Hackfest on 8 January 2014
Organizer: "Joe Brockmeier" <jzb(a)redhat.com>
Time: Monday, January 6, 2014, 2:00:00 PM - 6:00:00 PM GMT/UTC Coordinated Universal Time
Invitees: server(a)lists.fedoraproject.org; cloud(a)lists.fedoraproject.org
*~*~*~*~*~*~*~*~*~*
Per previous discussion, posting a calendar invite for anyone that wants to join in the "hackfest" on Wednesday, from 14:00 UTC to 18:00 UTC.
Best,
jzb
9 years, 2 months
Server WG Meeting Minutes (2014-01-07)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-01-07)
===================================================================
Meeting started by sgallagh at 16:01:05 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-01-07/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 16:01:18)
* Server Role Requirements (sgallagh, 16:05:38)
* LINK: https://www.piratepad.ca/p/serverwg-roles-proposal (mizmo,
16:10:13)
* LINK: https://pad.riseup.net/p/serverwg-roles-proposal
(davidstrauss, 16:10:47)
Meeting ended at 17:37:40 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (146)
* simo (91)
* mizmo (66)
* mitr (55)
* rdoty (34)
* davidstrauss (27)
* nirik (26)
* zodbot (9)
* adamw (5)
* tuanta (5)
* jwb (4)
* Evolution (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLMO9sACgkQeiVVYja6o6MfSwCfdfthKvaVcQ/IzsOt+oUdJnL/
upwAnRm6QQFZFBeipEGIgfgYErD4GdDG
=Lz4r
-----END PGP SIGNATURE-----
9 years, 2 months
Fedora Server Use Cases Prioritization
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Today at the overflow meeting, we came up with nine use cases that we
believe we want to focus on with the Fedora Server product. We agreed
that we want to list these in priority order, but I want to open this
up to the wider server community so we can order these properly.
Please keep in mind that these use-cases are high-level and should not
be construed to be exhaustive or exclusive. There are several items in
this list that we need to coordinate with other working groups as well.
Please respond with your recommendations for the ordering of this list
(assuming that all entries remain as they are) so we can get a sense
of the relative importance of these items.
1) The user must be able to easily deploy and configure any supported
Fedora Server role. (Examples may include: FreeIPA Domain Controller,
BIND DNS, DHCP, Database server, iSCSI target, File/Storage server.)
2) The user must be able to query, monitor, configure and manage a
Fedora Server remotely using stable and consistent public interfaces.
3) The user must be able to simply enroll the Fedora Server into a
FreeIPA or Active Directory domain.
4) Users must be able to control and contain the resources consumed by
services running on the system.
5) Users must be able to rapidly re-deploy services in accordance with
their DevOps practices using Fedora Server.
6) ASK SOFTWARE COLLECTIONS WG The user must be able to easily deploy
and configure applications to supported high-value frameworks.
(Example frameworks: JBoss, Ruby on Rails, Django, Turbogears,
Node.js, PHP.)
7) ASK CLOUD WG Provide a platform for acting as a node in an
OpenStack rack.
8) ASK CLOUD WG Users must be able to create, manipulate and terminate
large numbers of containers using a stable and consistent interface.
9) Users must be able to use Fedora Server in fully headless
operation. We commit to supporting only those GUI applications that
can work with forwarded X (or the equivalent on other windowing systems)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKzKPwACgkQeiVVYja6o6NC7ACfafYeZ3kLNem47KvknhIfVUGf
rx4AnRcPyegQoZvfhDKWkE1/tN7nCiHC
=7GD1
-----END PGP SIGNATURE-----
9 years, 2 months
Requirements to promote to featured Server Role
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In order to seed the conversation for tomorrow's Server WG meeting,
I'm putting together a first draft of a document outlining the
requirements that must be met in order to promote an
application/server technology into a featured role of the Fedora
Server. Note: this must not preclude the ability for services not
considered "Featured" to deploy on Fedora Server.
I will tie these goals to the agreed-upon use-cases where appropriate
(see
https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=365234
for the numbering reference).
Mandatory requirements are exactly as they sound: if any one of these
requirements is not met, the server role is ineligible for elevation
to "featured" status. Optional requirements are different. This is
*not* a list of things you should ignore. Rather, this is a list of
things that if you implement them, you are committing that they must
continue to behave that way in the future. (The list below should make
this more clear).
This is a first draft, please add or criticize as necessary.
== Mandatory Requirements ==
1. The Server Role *must* be packaged in such a way that it is
possible to install the complete set as a unit. AKA "One-click
Install". [Use Case 1]
2. The Server Role *must* provide an API or similar stable external
interface for configuring the role post-installation. Exceptions to
this rule may be granted if and only if Optional Requirement 2 (below)
is met and it can be demonstrated that the default method of operation
is the only reasonable method of operation. [Use Case 1]
3. The Server Role *must* provide an API to interrogate the
configurable settings of the role as identified by Mandatory
Requirement 2. [Use Case 2]
4. The Server Role *must* add to the functionality of the Fedora
Server. In other words, a Server Role cannot be considered "Featured"
if its purpose is to further reduce the minimal system.
5. A Server Role *must* have an identified point of contact that
agrees to maintain the Server Role in Fedora. If this person or group
becomes unresponsive, the Server Role will necessarily be demoted from
Featured status.
6. A Server Role *must* be installable without a local graphical
utility. [Use Case 9]
== Optional Requirements ==
1. The Server Role *may* be packaged in such a way that it can be
uninstalled as a complete unit. The mechanism to accomplish this
removal *must* remain consistent. [Use Case 1]
2. The Server Role *may* provide a sane, usable default. If it does
so, it *must* remain capable of accepting input through its
configuration API to change this default. [Use Case 1]
3. The Server Role *may* provide an API to interrogate additional
useful information about the running service(s) provided by the Server
Role. The content here is up to the Server Role to define, but should
be treated as stable (e.g an update should never remove the ability to
monitor something). [Use Case 2]
4. The Server Role *may* provide a specification of its needed
resources to the Fedora Server in a standard format. (e.g. Memory
requirements, etc.) If this is provided, the Fedora Server *may* use
this information to create isolated services such as VMs or containers
in which to run the Server Role. [Use Case 4]
5. The Server Role *may* request operation in an isolated environment
(with or without implementing Optional Requirement 4). If it does so,
the Server Role must indicate (using a standard Fedora Server API)
what form(s) of isolation it supports. Fedora Server *must* honor
this. [Use Case 4]
6. A Server Role *may* provide a remote graphical (which includes
web-based) configuration tool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLLJDQACgkQeiVVYja6o6PdqQCdENVjc7wNkzxhivXHlDKZ1av/
yFkAmgKKDHDX7UVFoheBbPeJRi5In+aY
=6cgw
-----END PGP SIGNATURE-----
9 years, 2 months
Requirements to promote to featured Server Role
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In order to seed the conversation for tomorrow's Server WG meeting,
I'm putting together a first draft of a document outlining the
requirements that must be met in order to promote an
application/server technology into a featured role of the Fedora
Server. Note: this must not preclude the ability for services not
considered "Featured" to deploy on Fedora Server.
I will tie these goals to the agreed-upon use-cases where appropriate
(see
https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=365234
for the numbering reference).
Mandatory requirements are exactly as they sound: if any one of these
requirements is not met, the server role is ineligible for elevation
to "featured" status. Optional requirements are different. This is
*not* a list of things you should ignore. Rather, this is a list of
things that if you implement them, you are committing that they must
continue to behave that way in the future. (The list below should make
this more clear).
This is a first draft, please add or criticize as necessary.
== Mandatory Requirements ==
1. The Server Role *must* be packaged in such a way that it is
possible to install the complete set as a unit. AKA "One-click
Install". [Use Case 1]
2. The Server Role *must* provide an API or similar stable external
interface for configuring the role post-installation. Exceptions to
this rule may be granted if and only if Optional Requirement 2 (below)
is met and it can be demonstrated that the default method of operation
is the only reasonable method of operation. [Use Case 1]
3. The Server Role *must* provide an API to interrogate the
configurable settings of the role as identified by Mandatory
Requirement 2. [Use Case 2]
4. The Server Role *must* add to the functionality of the Fedora
Server. In other words, a Server Role cannot be considered "Featured"
if its purpose is to further reduce the minimal system.
5. A Server Role *must* have an identified point of contact that
agrees to maintain the Server Role in Fedora. If this person or group
becomes unresponsive, the Server Role will necessarily be demoted from
Featured status.
6. A Server Role *must* be installable without a local graphical
utility. [Use Case 9]
== Optional Requirements ==
1. The Server Role *may* be packaged in such a way that it can be
uninstalled as a complete unit. The mechanism to accomplish this
removal *must* remain consistent. [Use Case 1]
2. The Server Role *may* provide a sane, usable default. If it does
so, it *must* remain capable of accepting input through its
configuration API to change this default. [Use Case 1]
3. The Server Role *may* provide an API to interrogate additional
useful information about the running service(s) provided by the Server
Role. The content here is up to the Server Role to define, but should
be treated as stable (e.g an update should never remove the ability to
monitor something). [Use Case 2]
4. The Server Role *may* provide a specification of its needed
resources to the Fedora Server in a standard format. (e.g. Memory
requirements, etc.) If this is provided, the Fedora Server *may* use
this information to create isolated services such as VMs or containers
in which to run the Server Role. [Use Case 4]
5. The Server Role *may* request operation in an isolated environment
(with or without implementing Optional Requirement 4). If it does so,
the Server Role must indicate (using a standard Fedora Server API)
what form(s) of isolation it supports. Fedora Server *must* honor
this. [Use Case 4]
6. A Server Role *may* provide a remote graphical (which includes
web-based) configuration tool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLLJDQACgkQeiVVYja6o6PdqQCfc7OeUdf+EcGFnW175KHTh/zb
01MAoKpNqQc/v44bMXD2OTLl0UMZ6DmE
=zQun
-----END PGP SIGNATURE-----
9 years, 2 months
PRD Hackfest on 8 January 2014
by Joe Brockmeier
The following meeting has been modified:
Subject: PRD Hackfest on 8 January 2014
Organizer: "Joe Brockmeier" <jzb(a)redhat.com>
Time: Wednesday, January 8, 2014, 8:00:00 AM - 12:00:00 PM GMT -06:00 US/Canada Central [MODIFIED]
Invitees: server(a)lists.fedoraproject.org; cloud(a)lists.fedoraproject.org
*~*~*~*~*~*~*~*~*~*
Argh. Resending with appropriate date. Sorry folks!
Per previous discussion, posting a calendar invite for anyone that wants to join in the "hackfest" on Wednesday, from 14:00 UTC to 18:00 UTC.
Best,
jzb
9 years, 2 months